[Docker] HTTP_PORT ignored, changing it in app.ini fails the container #3885

Closed
opened 2025-11-02 05:29:32 -06:00 by GiteaMirror · 12 comments
Owner

Originally created by @DarkGhostHunter on GitHub (Sep 3, 2019).

  • Gitea version (or commit ref): gitea/gitea:1
  • Git version: ~
  • Operating system: RHEL 7.6
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:
2019/09/03 02:42:15 routers/init.go:106:GlobalInit() [I] SQLite3 Supported
2019/09/03 02:42:15 routers/init.go:37:checkRunMode() [I] Run Mode: Production
2019/09/03 02:42:15 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT "id", "repo_id", "hook_id", "uuid", "type", "url", "signature", "payload_content", "http_method", "content_type", "event_type", "is_ssl", "is_delivered", "delivered", "is_succeed", "request_content", "response_content" FROM "hook_task" WHERE (is_delivered=$1) []interface {}{false}
2019/09/03 02:42:15 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT "id", "type", "status", "conflicted_files", "issue_id", "index", "head_repo_id", "base_repo_id", "head_user_name", "head_branch", "base_branch", "merge_base", "has_merged", "merged_commit_id", "merger_id", "merged_unix" FROM "pull_request" WHERE (status = $1) []interface {}{1}
2019/09/03 02:42:15 cmd/web.go:151:runWeb() [I] Listen: http://0.0.0.0:80
2019/09/03 02:42:15 cmd/web.go:154:runWeb() [I] LFS server enabled
2019/09/03 02:42:15 cmd/web.go:210:runWeb() [F] Failed to start server: listen tcp 0.0.0.0:80: bind: permission denied
2019/09/03 02:42:15 ...dules/setting/log.go:269:newLogService() [I] Gitea Log Mode: File(File:info)
2019/09/03 02:42:15 ...les/setting/cache.go:42:newCacheService() [I] Cache Service Enabled
2019/09/03 02:42:15 ...s/setting/session.go:45:newSessionService() [I] Session Service Enabled
2019/09/03 02:42:15 routers/init.go:49:initDBEngine() [I] Beginning ORM engine initialization.
2019/09/03 02:42:15 routers/init.go:51:initDBEngine() [I] ORM engine initialization attempt #1/10...
2019/09/03 02:42:15 ...-xorm/xorm/engine.go:329:Ping() [I] PING DATABASE postgres
2019/09/03 02:42:15 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] SELECT tablename FROM pg_tables WHERE schemaname = $1 AND tablename = $2 []interface {}{"public", "version"}
2019/09/03 02:42:15 .../dialect_postgres.go:946:IsColumnExist() [I] [SQL] SELECT column_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = $1 AND table_name = $2 AND column_name = $3 [public version id]
2019/09/03 02:42:15 .../dialect_postgres.go:946:IsColumnExist() [I] [SQL] SELECT column_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = $1 AND table_name = $2 AND column_name = $3 [public version version]
2019/09/03 02:42:15 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT "id", "version" FROM "version" WHERE "id"=$1 LIMIT 1 []interface {}{1}
2019/09/03 02:42:15 .../dialect_postgres.go:1074:GetTables() [I] [SQL] SELECT tablename FROM pg_tables WHERE schemaname = $1 [public]
2019/09/03 02:42:15 .../dialect_postgres.go:978:GetColumns() [I] [SQL] SELECT column_name, column_default, is_nullable, data_type, character_maximum_length, numeric_precision, numeric_precision_radix ,
	    CASE WHEN p.contype = 'p' THEN true ELSE false END AS primarykey,
	    CASE WHEN p.contype = 'u' THEN true ELSE false END AS uniquekey
...

Description

Using Docker, Gitea fails to bind to a the 80 port.

2019/09/03 02:42:15 cmd/web.go:210:runWeb() [F] Failed to start server: listen tcp 0.0.0.0:80: bind: permission denied

When it fails, the docker container is brought down.

This (using non-standard port for HTTP/HTTPS on a Docker Container) makes no sense at all, and trying to bind it to 80 also doesn't work. I can't think about a need of using the 3000 port, unless there is a problem on permissions (ports < 1024 are restricted to root and I assume gitea runs on the git user).

  • Using HTTP_PORT environment variable is ignored.
  • Trying to use port 80 in the app.ini gives the aforementioned log.
  • Combining with manually exposing the port (80) also gives no results.
Originally created by @DarkGhostHunter on GitHub (Sep 3, 2019). - Gitea version (or commit ref): gitea/gitea:1 - Git version: ~ - Operating system: RHEL 7.6 - Database (use `[x]`): - [X] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [X] Not relevant - Log gist: ``` 2019/09/03 02:42:15 routers/init.go:106:GlobalInit() [I] SQLite3 Supported 2019/09/03 02:42:15 routers/init.go:37:checkRunMode() [I] Run Mode: Production 2019/09/03 02:42:15 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT "id", "repo_id", "hook_id", "uuid", "type", "url", "signature", "payload_content", "http_method", "content_type", "event_type", "is_ssl", "is_delivered", "delivered", "is_succeed", "request_content", "response_content" FROM "hook_task" WHERE (is_delivered=$1) []interface {}{false} 2019/09/03 02:42:15 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT "id", "type", "status", "conflicted_files", "issue_id", "index", "head_repo_id", "base_repo_id", "head_user_name", "head_branch", "base_branch", "merge_base", "has_merged", "merged_commit_id", "merger_id", "merged_unix" FROM "pull_request" WHERE (status = $1) []interface {}{1} 2019/09/03 02:42:15 cmd/web.go:151:runWeb() [I] Listen: http://0.0.0.0:80 2019/09/03 02:42:15 cmd/web.go:154:runWeb() [I] LFS server enabled 2019/09/03 02:42:15 cmd/web.go:210:runWeb() [F] Failed to start server: listen tcp 0.0.0.0:80: bind: permission denied 2019/09/03 02:42:15 ...dules/setting/log.go:269:newLogService() [I] Gitea Log Mode: File(File:info) 2019/09/03 02:42:15 ...les/setting/cache.go:42:newCacheService() [I] Cache Service Enabled 2019/09/03 02:42:15 ...s/setting/session.go:45:newSessionService() [I] Session Service Enabled 2019/09/03 02:42:15 routers/init.go:49:initDBEngine() [I] Beginning ORM engine initialization. 2019/09/03 02:42:15 routers/init.go:51:initDBEngine() [I] ORM engine initialization attempt #1/10... 2019/09/03 02:42:15 ...-xorm/xorm/engine.go:329:Ping() [I] PING DATABASE postgres 2019/09/03 02:42:15 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] SELECT tablename FROM pg_tables WHERE schemaname = $1 AND tablename = $2 []interface {}{"public", "version"} 2019/09/03 02:42:15 .../dialect_postgres.go:946:IsColumnExist() [I] [SQL] SELECT column_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = $1 AND table_name = $2 AND column_name = $3 [public version id] 2019/09/03 02:42:15 .../dialect_postgres.go:946:IsColumnExist() [I] [SQL] SELECT column_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = $1 AND table_name = $2 AND column_name = $3 [public version version] 2019/09/03 02:42:15 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT "id", "version" FROM "version" WHERE "id"=$1 LIMIT 1 []interface {}{1} 2019/09/03 02:42:15 .../dialect_postgres.go:1074:GetTables() [I] [SQL] SELECT tablename FROM pg_tables WHERE schemaname = $1 [public] 2019/09/03 02:42:15 .../dialect_postgres.go:978:GetColumns() [I] [SQL] SELECT column_name, column_default, is_nullable, data_type, character_maximum_length, numeric_precision, numeric_precision_radix , CASE WHEN p.contype = 'p' THEN true ELSE false END AS primarykey, CASE WHEN p.contype = 'u' THEN true ELSE false END AS uniquekey ... ``` ## Description Using Docker, Gitea fails to bind to a the 80 port. 2019/09/03 02:42:15 cmd/web.go:210:runWeb() [F] Failed to start server: listen tcp 0.0.0.0:80: bind: permission denied When it fails, the docker container is brought down. This (using non-standard port for HTTP/HTTPS on a Docker Container) makes no sense at all, and trying to bind it to 80 also doesn't work. I can't think about a need of using the 3000 port, unless there is a problem on permissions (ports < 1024 are restricted to root and I assume gitea runs on the `git` user). * Using `HTTP_PORT` environment variable is ignored. * Trying to use port 80 in the `app.ini` gives the aforementioned log. * Combining with manually exposing the port (80) also gives no results.
GiteaMirror added the type/questionissue/stale labels 2025-11-02 05:29:32 -06:00
Author
Owner

@gary-kim commented on GitHub (Sep 3, 2019):

Rather than changing the port inside the container, you can use Docker's host mapping. So if you want to put Gitea on port 80, you would put -p 80:3000 in your docker run command.
Documentation: https://docs.docker.com/config/containers/container-networking/

@gary-kim commented on GitHub (Sep 3, 2019): Rather than changing the port inside the container, you can use Docker's host mapping. So if you want to put Gitea on port 80, you would put `-p 80:3000` in your `docker run` command. Documentation: <https://docs.docker.com/config/containers/container-networking/>
Author
Owner

@DarkGhostHunter commented on GitHub (Sep 3, 2019):

Rather than changing the port inside the container, you can use Docker's host mapping. So if you want to put Gitea on port 80, you would put -p 80:3000 in your docker run command.
Documentation: https://docs.docker.com/config/containers/container-networking/

Using that with other CICD containers cause them to fail because they can't reach Gitea on port 80, like when using Drone. If these change to 3000, the public request through the browser doesn't point out Gitea because is running in port 3000. This behind load balancers makes them unusable, which is probably 100% of production environments.

For example, trying to pull an automatic build from Gitea returns this:

Initialized empty Git repository in /drone/src/.git/
--
+ git fetch --depth=5 origin +refs/heads/stable:
fatal: unable to access 'http://git.development.services.cencosud.cl/servlet/ui.git/': Failed to connect to git.development.services.cencosud.cl port 80: Connection refused

The only workaround that I can think of is to let the Gitea starts as root inside the Docker container, allowing mapping a sub < 1024 port, but dropping privileges to the set user RUN_USER after the port has been bound to the container.

@DarkGhostHunter commented on GitHub (Sep 3, 2019): > Rather than changing the port inside the container, you can use Docker's host mapping. So if you want to put Gitea on port 80, you would put `-p 80:3000` in your `docker run` command. > Documentation: https://docs.docker.com/config/containers/container-networking/ Using that with other CICD containers cause them to fail because they can't reach Gitea on port 80, like when using Drone. If these change to 3000, the public request through the browser doesn't point out Gitea because is running in port 3000. This behind load balancers makes them unusable, which is probably 100% of production environments. For example, trying to pull an automatic build from Gitea returns this: ``` Initialized empty Git repository in /drone/src/.git/ -- + git fetch --depth=5 origin +refs/heads/stable: fatal: unable to access 'http://git.development.services.cencosud.cl/servlet/ui.git/': Failed to connect to git.development.services.cencosud.cl port 80: Connection refused ``` The only workaround that I can think of is to let the Gitea starts as root inside the Docker container, allowing mapping a sub < 1024 port, but dropping privileges to the set user `RUN_USER` after the port has been bound to the container.
Author
Owner

@techknowlogick commented on GitHub (Sep 3, 2019):

drone.gitea.com, and drone.gitea.io are both behind LB's and are configured in a similar way to how @gary-kim has suggested.

You can keep HTTP_PORT as 3000, but update ROOT_URL (for example ROOT_URL=http://git.development.services.cencosud.cl ) to be a URL that doesn't have a port have so that browser requests go through a LB.

@techknowlogick commented on GitHub (Sep 3, 2019): drone.gitea.com, and drone.gitea.io are both behind LB's and are configured in a similar way to how @gary-kim has suggested. You can keep HTTP_PORT as 3000, but update ROOT_URL (for example ROOT_URL=http://git.development.services.cencosud.cl ) to be a URL that doesn't have a port have so that browser requests go through a LB.
Author
Owner

@DarkGhostHunter commented on GitHub (Sep 3, 2019):

That's a weird setup.

Anyway, this can be fixed by allowing /app/gitea/gitea to bind a port below 1024 using setcap. Since the installation allows to bind any number to the port, the user may find a problem when it changes the port to another one when restarting the Gitea container.

To avoid this, libcap should be installed in the container (since it's Alpine) and let gitea the permissions to do so, without running it as root.

I'll make a PR later. For the time being, this can be fixed by using a Dockerfile:

###########################################################################
# Gitea configuration

FROM gitea/gitea:1

# Add libcap and let the gitea binary to bind < 1024 ports 
RUN apk --no-cache add libcap \
 && echo "setcap 'cap_net_bind_service=+ep' /app/gitea/gitea" >> /etc/s6/gitea/setup
@DarkGhostHunter commented on GitHub (Sep 3, 2019): That's a weird setup. Anyway, this can be fixed by allowing `/app/gitea/gitea` to bind a port below 1024 using `setcap`. Since the installation allows to bind any number to the port, the user may find a problem when it changes the port to another one when restarting the Gitea container. To avoid this, `libcap` should be installed in the container (since it's Alpine) and let gitea the permissions to do so, without running it as `root`. I'll make a PR later. For the time being, this can be fixed by using a Dockerfile: ``` ########################################################################### # Gitea configuration FROM gitea/gitea:1 # Add libcap and let the gitea binary to bind < 1024 ports RUN apk --no-cache add libcap \ && echo "setcap 'cap_net_bind_service=+ep' /app/gitea/gitea" >> /etc/s6/gitea/setup ```
Author
Owner

@gary-kim commented on GitHub (Sep 3, 2019):

For the Docker container, it shouldn't matter what the internal binding is. I'm not sure why Gitea needs the ability to bind to any port inside the container.

From my experience, it's a pretty standard setup for Docker images.

@gary-kim commented on GitHub (Sep 3, 2019): For the Docker container, it shouldn't matter what the internal binding is. I'm not sure why Gitea needs the ability to bind to any port inside the container. From my experience, it's a pretty standard setup for Docker images.
Author
Owner

@gary-kim commented on GitHub (Sep 3, 2019):

Using that with other CICD containers cause them to fail because they can't reach Gitea on port 80, like when using Drone

Do you have Gitea and Drone set up in a single docker-compose setup? While you could contact another container through the docker provided hostname, it generally should be the same URL used for public access, whether that be behind a reverse proxy or through the external URL. In the latter case, it doesn't matter what the internal port mapping Gitea is.

@gary-kim commented on GitHub (Sep 3, 2019): > Using that with other CICD containers cause them to fail because they can't reach Gitea on port 80, like when using Drone Do you have Gitea and Drone set up in a single docker-compose setup? While you could contact another container through the docker provided hostname, it generally should be the same URL used for public access, whether that be behind a reverse proxy or through the external URL. In the latter case, it doesn't matter what the internal port mapping Gitea is.
Author
Owner

@DarkGhostHunter commented on GitHub (Sep 3, 2019):

Using that with other CICD containers cause them to fail because they can't reach Gitea on port 80, like when using Drone

Do you have Gitea and Drone set up in a single docker-compose setup? While you could contact another container through the docker provided hostname, it generally should be the same URL used for public access.

Exactly.

The problem I'm having is that Drone, when in the same network, will only find Gitea by its name (for example, http://gitea:3000. When it reroutes the browser to OAuth, that hostname doesn't exists (but it does as http://git.development.services.cencosud.cl). If I do an alias, it does work but I have to change the port number in the browser.

The LB uses 80/443, so I can't bind ports. Because it's more easy to use mail.thing.gov than thing.gov:2000 for those who don't know what http is.

@DarkGhostHunter commented on GitHub (Sep 3, 2019): > > Using that with other CICD containers cause them to fail because they can't reach Gitea on port 80, like when using Drone > > Do you have Gitea and Drone set up in a single docker-compose setup? While you could contact another container through the docker provided hostname, it generally should be the same URL used for public access. Exactly. The problem I'm having is that Drone, when in the same network, will only find Gitea by its name (for example, `http://gitea:3000`. When it reroutes the browser to OAuth, that hostname doesn't exists (but it does as `http://git.development.services.cencosud.cl`). If I do an alias, it does work but I have to change the port number in the browser. The LB uses 80/443, so I can't bind ports. Because it's more easy to use `mail.thing.gov` than `thing.gov:2000` for those who don't know what http is.
Author
Owner

@gary-kim commented on GitHub (Sep 4, 2019):

The way I have mine setup is with Gitea running with -p 3000:3000 and using Apache as a reverse proxy from https://git.garykim.dev to port 3000 internally and Drone accesses Gitea through the same URL. Could the LB be set up in a similar way? The idea would be that Drone also accesses through your LB.

@gary-kim commented on GitHub (Sep 4, 2019): The way I have mine setup is with Gitea running with `-p 3000:3000` and using Apache as a reverse proxy from <https://git.garykim.dev> to port 3000 internally and Drone accesses Gitea through the same URL. Could the LB be set up in a similar way? The idea would be that Drone also accesses through your LB.
Author
Owner

@DarkGhostHunter commented on GitHub (Sep 4, 2019):

I Understand, but the corporate firewall doesn't allow to use any other port for the machines. I'm trying to workaround this, but the only solution I have, and that works, is to just push a setcap.

@DarkGhostHunter commented on GitHub (Sep 4, 2019): I Understand, but the corporate firewall doesn't allow to use any other port for the machines. I'm trying to workaround this, but the only solution I have, and that works, is to just push a `setcap`.
Author
Owner

@gary-kim commented on GitHub (Sep 4, 2019):

Okay, IMHO, I don't think it's worth it to add libcap to the official Docker container because this seems like a relatively rare situation.

@gary-kim commented on GitHub (Sep 4, 2019): Okay, IMHO, I don't think it's worth it to add `libcap` to the official Docker container because this seems like a relatively rare situation.
Author
Owner

@stale[bot] commented on GitHub (Nov 3, 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 (Nov 3, 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.
Author
Owner

@alexrjs commented on GitHub (Oct 31, 2020):

That's a weird setup.

Anyway, this can be fixed by allowing /app/gitea/gitea to bind a port below 1024 using setcap. Since the installation allows to bind any number to the port, the user may find a problem when it changes the port to another one when restarting the Gitea container.

To avoid this, libcap should be installed in the container (since it's Alpine) and let gitea the permissions to do so, without running it as root.

I'll make a PR later. For the time being, this can be fixed by using a Dockerfile:

###########################################################################
# Gitea configuration

FROM gitea/gitea:1

# Add libcap and let the gitea binary to bind < 1024 ports 
RUN apk --no-cache add libcap \
 && echo "setcap 'cap_net_bind_service=+ep' /app/gitea/gitea" >> /etc/s6/gitea/setup

Thanks, thats what I needed to get gitea working in docker with a macvlan to get a dhcp ip from my fritz.box router... :-)

@alexrjs commented on GitHub (Oct 31, 2020): > That's a weird setup. > > Anyway, this can be fixed by allowing `/app/gitea/gitea` to bind a port below 1024 using `setcap`. Since the installation allows to bind any number to the port, the user may find a problem when it changes the port to another one when restarting the Gitea container. > > To avoid this, `libcap` should be installed in the container (since it's Alpine) and let gitea the permissions to do so, without running it as `root`. > > I'll make a PR later. For the time being, this can be fixed by using a Dockerfile: > > ``` > ########################################################################### > # Gitea configuration > > FROM gitea/gitea:1 > > # Add libcap and let the gitea binary to bind < 1024 ports > RUN apk --no-cache add libcap \ > && echo "setcap 'cap_net_bind_service=+ep' /app/gitea/gitea" >> /etc/s6/gitea/setup > ``` Thanks, thats what I needed to get gitea working in docker with a macvlan to get a dhcp ip from my fritz.box router... :-)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#3885