docs/install-with-docker/ fail2ban timezone issue #3100

New Issue

GiteaMirror · 2025-11-02T05:00:44-06:00

GiteaMirror commented

2025-11-02 05:00:44 -06:00

Originally created by @stavae on GitHub (Mar 24, 2019).

Gitea version (or commit ref):
Go1.12.1 (running in docker; using docker-compose)
Operating system:
Ubuntu 18.10
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant

Description

The docker installation by default (at least for me) has a different timezone than the host OS. Meaning that fail2ban won't ban anything because the 'find time' window has already expired.

Check command

date && docker exec -ti <docker_container> sh -c "date" the output should be the same

Fix

I fixed this by following this comment link

(copied comment for your convenience)

The easiest solution would be share volume in docker-compose.yml like this

volumes:
    - "/etc/localtime:/etc/localtime:ro"

ro - means container can only read from /etc/localtime of host-machine.

Suggested changes

This is not discussed in any gitea documentation (that could find at least). So I think this should be added to either: install-with-docker or fail2ban-setup.
I personally think adding it to install-with-docker would be preferable, as I can't think of a reason to NOT have the same timezone for docker containers as the host OS.

Originally created by @stavae on GitHub (Mar 24, 2019). - Gitea version (or commit ref): Go1.12.1 (running in docker; using docker-compose) - Operating system: Ubuntu 18.10 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant ## Description The docker installation by default (at least for me) has a different timezone than the host OS. Meaning that fail2ban won't ban anything because the 'find time' window has already expired. ### Check command `date && docker exec -ti <docker_container> sh -c "date" ` the output should be the same ## Fix I fixed this by following this comment [link](https://stackoverflow.com/a/52526534) (copied comment for your convenience) ``` The easiest solution would be share volume in docker-compose.yml like this volumes: - "/etc/localtime:/etc/localtime:ro" ro - means container can only read from /etc/localtime of host-machine. ``` ## Suggested changes This is not discussed in any gitea documentation (that could find at least). So I think this should be added to either: [install-with-docker](https://docs.gitea.io/en-us/install-with-docker/) or [fail2ban-setup](https://docs.gitea.io/en-us/fail2ban-setup/). I personally think adding it to `install-with-docker` would be preferable, as I can't think of a reason to NOT have the same timezone for docker containers as the host OS.

GiteaMirror added the issue/stale label 2025-11-02 05:00:44 -06:00

GiteaMirror closed this issue

2025-11-02 05:00:44 -06:00

GiteaMirror commented

2025-11-02 05:00:45 -06:00

@stavae commented on GitHub (Mar 24, 2019):

Also note that I am very new to docker. So I am not sure that adding /etc/localtime as a volume is the best (or safe) way to fix this.

@stavae commented on GitHub (Mar 24, 2019): Also note that I am very new to docker. So I am not sure that adding `/etc/localtime` as a volume is the best (or safe) way to fix this.

GiteaMirror commented

2025-11-02 05:00:45 -06:00

@stale[bot] commented on GitHub (May 23, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (May 23, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:00:45 -06:00

@stale[bot] commented on GitHub (Jun 6, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Jun 6, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:18:37 -06:00

[PR #3100] [MERGED] Fix legacy URL redirects #16766

GiteaMirror referenced this issue

2025-11-02 12:18:41 -06:00

[PR #3106] [MERGED] Fix legacy URL redirects (#3100) #16769

Sign in to join this conversation.