nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)

[maz1987in]

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes
• Are you sure you're not using someone else's docker image?
  • Yes
• Have you searched for similar issues (both open and closed)?
  • Yes

Describe the bug

when I upgrade to the latest "2.10.0" I got

nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)

Nginx Proxy Manager Version

To Reproduce Run docker with option "network_mode: host"

Expected behavior

Screenshots

Operating System QNAP NAS

Additional context

[pmoon00]

Can confirm I'm seeing the exact same issue with the same configuration. Have rolled back to 2.9.22 to temporarily resolve the issue.

[kilrah]

Same on Unraid with Host network.

[hdavid0510]

Can confirm, exact same issue. I also reverted back to 2.9.22.

(edit) Changed host network to bridge, to bypass the issue. No other configuration changed. Since NPM config I'm using does not serve high load, I'm going to stick with bridge network for now.

[jsuelwald]

I've got the same problem since the update

[psychogun]

Same. Using podman on Rocky Linux.

[kahn2k]

Same problem running docker on Synology, with portainer and watchtower.

Have been on bridge network without problems before this update.

Reverted back to 2.9.22 and problem resolved.

[functionaldude]

Same issue running docker on Synology, DSM 7.1.1-42962 The container is in a bridge network

[wzzrd]

Yup, same: running with podman on RHEL9

[azchoi]

Same here!!!!

[Synology DSM 7.1] npm docker log nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)

[steindorarnar]

Same here, reverted to 2.9.22 Synology, docker, portainer, watchtower.

nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)

[zsmbrvr]

I used

app:
  image: 'jc21/nginx-proxy-manager:2.9.22'

to revert to 2.9.22.

[stephanvierkant]

Please don't comment with just 'same here!'. I think it's clear that there is an issue with the latest release.

[CelticWebSolutions]

Same issue here running on Synology with bridge networking. Unfortunately I spent a long time attempting to debug why it coudn’t bind to the port. Stop the container and port 80 became free, start the container at the port is in use via docker-proxy but NPM fails to bind to it.

After deleting everything and attempting to start again, I found it was still the same, permission denied when binding the port. Checked and spotted there’d been a recent update,

Rolling back to 2.9.22 fixes the issue For the time being.

Just realised @stephanvierkant had already mentioned using older release as I had :)

[Candinya]

It seems that since v2.10.0 the nginx is ran by npmuser rather than default (root maybe?), whom might don't have sufficient permissions to listen on lower ports like 80 & 443. Not sure if this is the cause. 🤔 See full changelogs here: https://github.com/NginxProxyManager/nginx-proxy-manager/compare/v2.9.22...v2.10.0

[florisdipt]

Same isue here;running inside proxmox lcx container. my docker compose:

version: "3"
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
  watchtower:
    container_name: watchtower
    image: containrrr/watchtower:latest
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

[redtripleAAA]

Would be good to understand what causes the issue.

Same here with Synology DSM, running latest or 2 same issue.

But running image: 'jc21/nginx-proxy-manager:2.9.22' fixed the issue for now

[zandhaas]

I had this same issue when I tried to install the beta version of the 3.0. I did try to add the PUID and GUID of root but that did not solve the issue for version 3. But then I thought this is still development so.........

But now I have this same issue with version 2.10 I'm running nginx_pm on my Synology.

[907739769]

problem solved please let me know thanks.

[zandhaas]

Please don't comment with just 'same here!'. I think it's clear that there is an issue with the latest release.

Perhaps you or someone else can give us an update on what is going on to solve this issue instead of giving us Thumb's down's Something like: " we see there is an error and we are looking into it. We expect to have a solutions in xx days"

And by the way: I think I added some extra information by telling the communicty that I see this exact same error in the new version 3 NGINX-PM

[evanlabs]

I tried to test on CentOS 7 and Debian 10/11, this problem only happens on CentOS 7 system, not on Debian.

Maybe because of npmuser permissions, just guessing.

source: docker/rootfs/etc/s6-overlay/s6-rc.d/prepare/10-npmuser.sh

[florisdipt]

I tried to test on CentOS 7 and Debian 10/11, this problem only happens on CentOS 7 system, not on Debian.

Are you talking about running directly inside the system without docker? Because i'm running debian + docker and still encountered the issue.

[evanlabs]

Sorry, did not provide complete information. I use docker to do npm testing on centos and debian.

[Jojonintendo]

The release notes mention this:

Adds support to run processes as a user/group, defined with PUID and PGID environment variables

    Detects if image is run with a user in docker command and fails if so

Users running 2.10.0 won't be able to run this container rootless apparently (as I've been doint with podman). Otherwise this message appears:

[user]$ podman logs -f nginx-test 
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service prepare: starting
--------------------------------------
ERROR: This docker container must be run as root, do not specify a user.
You can specify PUID and PGID env vars to run processes as that user and group after initialization.
--------------------------------------

And the container stops. Problem is, even when specifying PUID and PGID, the container shows the errors reported in this thread.

Maybe I don't understand well what the new configuration should be, based on the release notes. If running the container as root is now a requisite, that would be a shame for us rootless users.

Any pointers would be greatly appreciated.

[evanlabs]

I tried to test on CentOS 7 and Debian 10/11, this problem only happens on CentOS 7 system, not on Debian.

Are you talking about running directly inside the system without docker? Because i'm running debian + docker and still encountered the issue.

I tried to modify the following s6 startup script, but it still didn't solve the problem

source: docker/rootfs/etc/s6-overlay/s6-rc.d/nginx/run 'exec s6-setuidgid npmuser nginx' => 'exec nginx'

[BobWs]

Same problem running docker on Synology DSM 7.1.1 with Portainer. Reverted back to 2.9.22 and problem resolved.

[Nazgile94]

nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) same ubuntu 22.x

[gabeosx]

Same issue

• Synology DS918+
• DSM 7.1.1-42962 Update 4

[Trolann]

This seems to be expected behavior. @maz1987in @Jojonintendo @Candinya @evanlabs

Release notes for 2.9.22 state: https://github.com/NginxProxyManager/nginx-proxy-manager/releases

v2.9.22

⚠️ The next release v2.10.0 will have changes that may adversely affect you, please pin your docker tag to 2.9.22 and upgrade after you conduct a full backup.

and

v2.10.0

⚠️ This release has changes that may adversely affect you, please pin your docker tag to the previous release 2.9.22 and upgrade after you conduct a full backup.

But I can't find anything about how to prevent this 'adverse affect'.

Copied my comment above from #2761 which appears to be the duplicate

[Jojonintendo]

Same issue with the new image 2.10.1 I've tested the same as my previous comment, with PUID and PGID, and without them. The issue persists. I've also tried running the container with sudo, to no avail. So it doesn't seem to be only related to rootless containers.

[azchoi]

Same issue with the new image 2.10.1 I've tested the same as my previous comment, with PUID and PGID, and without them. The issue persists. I've also tried running the container with sudo, to no avail. So it doesn't seem to be only related to rootless containers.

Right, I also tried to install 2.10.1 to Synology 7.1.1, the result was same as before. Only 2.9.22 is the best way to me.

[jurjen74]

Same here on Synology. Latest (2.10.1) is not working. Rolled back to 2.9.22

[nemccarthy]

Having the same issue with this. I suspect the issue is related to the s6 change and this line in nginx config https://github.com/NginxProxyManager/nginx-proxy-manager/compare/v2.9.22...v2.10.0#diff-45b340b2ff6f4d041ae1aad210aaa0cd31b41139574725ef971a38fab076caa4L4

The issue is not just the NET_BIND_SERVICE capability missing from the docker run, its a simple issue with the container itself. A non-root user cannot bind to ports less than 1024. This docker file should give the new npmuser permissions to do this.

If you are seeing nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) I have found the following to work...

Temporary solution (without rollback):

1. Atach an interactive bash shell to your running nginx proxy manager container. In Synology if you go to Docker > Containers > double click the NPM container to view details > Terminal > Create > type bash > Ok
2. update apt: apt update
3. install setcap via libcap2-bin:apt install libcap2-bin
4. allow non-root users to bind to ports <1025: setcap 'cap_net_bind_service=+ep' /usr/sbin/nginx

You should now see nginx proxy manager successfully start! No need to restart the container. The issue with this fix is that if you have something like watchtower running you will lose this on next update until its fixed in the offical docker image.

Good hygine would also be to add the PUID and PGID env vars to a non-root user that lives on your system.

Suggested Proper Fix:

Note that the above is NOT reccomended as a permanent fix, and shouldn't be raised as a PR in the Dockerfile (as it adds portability and security issues - e.g. PSP violations in a locked down k8s cluster).

IMHO, the proper fix will be to move all NPM binds to a different set of ports like 8080... This is probably a bigger change given the config generation. One can bind 80 on their network interfaces to 8080 in the container (i.e. docker run -p 80:8080 ...) so you get the behaviour you need... This avoids the need for elevated privileges, since non-root users can bind to ports higher than 1024 and the only way I know how to get this working...

For reference on Synology:

[florisdipt]

This seems to be expected behavior. @maz1987in @Jojonintendo @Candinya @evanlabs

Release notes for 2.9.22 state: https://github.com/NginxProxyManager/nginx-proxy-manager/releases

v2.9.22

⚠️ The next release v2.10.0 will have changes that may adversely affect you, please pin your docker tag to 2.9.22 and upgrade after you conduct a full backup.

and

v2.10.0

⚠️ This release has changes that may adversely affect you, please pin your docker tag to the previous release 2.9.22 and upgrade after you conduct a full backup.

But I can't find anything about how to prevent this 'adverse affect'.

Copied my comment above from #2761 which appears to be the duplicate

If Semantic Versioning is respected, this shouldn't be expected behaviour as this is a minor version not a major therefor it shouldn't break compatibility.

Obviously backing up al configuration before changing versions is a good idea, as one could never have enough backups only too little hard drive space ;)

On Another note I see a bugfix version for 2.10 was issued 11 hours ago. But replies so far in this issue seem to indicate that is not a fix for this issue

[TarekMSayed]

2.9.22 works for me too but I noticed the versions latest, 2, or 2.10 creates files with UID=GID=911 while 2.9.22 use root user

[Trolann]

@florisdipt completely agree, and there should be release notes clearly showing how to correct it. I gave the installation instructions a glance and couldn't see updates there but in off on vacation today so couldn't dig in.

[coalfield]

Good hygine would also be to add the PUID and PGID env vars to a non-root user that lives on your system.

thanks for your fix it works and greatly appreciated!! Do you know what permissions this use would need for synology, is it worth creating a specific user for this, and would be keen to know the minimal permissions they would need to allow them to be used with the container?

[nemccarthy]

Good hygine would also be to add the PUID and PGID env vars to a non-root user that lives on your system.

thanks for your fix it works and greatly appreciated!! Do you know what permissions this use would need for synology, is it worth creating a specific user for this, and would be keen to know the minimal permissions they would need to allow them to be used with the container?

PUID (Process User ID) and PGID (Process Group ID) so as you know they are environment variables used in Docker containers to set the user and group IDs for the container's processes. They help to manage file and folder permissions for the data shared between the host system and the container - in this case the data folder and cert folder volume mounts for NPM.

I generally create a basic user with no login via the control panel in the Synology NAS that only has access to a volume for my docker containers. I create a user for each domain set of containers say user docker-npm, I think give this user ownership permissions to a docker-npm folder in the NAS where I want to mount volumes in the container.

Once you create a new user, to get the User ID and Group ID on the NAS the easiest way is to create a Task from control panel and add the following command to the steps cat /etc/passwd you should then be able to manually run the task by hitting Run on the list of tasks and view the output (Action > View Result) which show you the user name you create along with the UID and GID.

[apriliars3]

Having the same issue with this. I suspect the issue is related to the s6 change and this line in nginx config v2.9.22...v2.10.0#diff-45b340b2ff6f4d041ae1aad210aaa0cd31b41139574725ef971a38fab076caa4L4

The issue is not just the NET_BIND_SERVICE capability missing from the docker run, its a simple issue with the container itself. A non-root user cannot bind to ports less than 1024. This docker file should give the new npmuser permissions to do this.

If you are seeing nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) I have found the following to work...

Temporary solution (without rollback):

1. Atach an interactive bash shell to your running nginx proxy manager container. In Synology if you go to Docker > Containers > double click the NPM container to view details > Terminal > Create > type bash > Ok
2. update apt: apt update
3. install setcap via libcap2-bin:apt install libcap2-bin
4. allow non-root users to bind to ports <1025: setcap 'cap_net_bind_service=+ep' /usr/sbin/nginx

You should now see nginx proxy manager successfully start! No need to restart the container. The issue with this fix is that if you have something like watchtower running you will lose this on next update until its fixed in the offical docker image.

Good hygine would also be to add the PUID and PGID env vars to a non-root user that lives on your system.

Suggested Proper Fix:

Note that the above is NOT reccomended as a permanent fix, and shouldn't be raised as a PR in the Dockerfile (as it adds portability and security issues - e.g. PSP violations in a locked down k8s cluster).

IMHO, the proper fix will be to move all NPM binds to a different set of ports like 8080... This is probably a bigger change given the config generation. One can bind 80 on their network interfaces to 8080 in the container (i.e. docker run -p 80:8080 ...) so you get the behaviour you need... This avoids the need for elevated privileges, since non-root users can bind to ports higher than 1024 and the only way I know how to get this working...

For reference on Synology:

Works I have PUID and PGID with my user on docker. Why not works with this?

docker run -d --name=nginx_proxy_manager \ -p 8880:80 \ -p 81:81 \ -p 4443:443 \ -e PUID=1026 \ -e PGID=100 \ -e TZ=Europe/Madrid \ -v /volume1/docker/npm/config.json:/app/config/production.json \ -v /volume1/docker/npm/data:/data \ -v /volume1/docker/npm/letsencrypt:/etc/letsencrypt \ --restart always \ jc21/nginx-proxy-manager

[coalfield]

I generally create a basic user with no login via the control panel in the Synology NAS that only has access to a volume for my docker containers. I create a user for each domain set of containers say user docker-npm, I think give this user ownership permissions to a docker-npm folder in the NAS where I want to mount volumes in the container.

Thanks that's good advice I have taken, although its functioning OK I am getting:

[3/30/2023] [11:46:27 PM] [SSL      ] › ✖  error     Error: Command failed: certbot renew --non-interactive --quiet --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --preferred-challenges "dns,http" --disable-hook-validation  
The following error was encountered:
[Errno 13] Permission denied: '/tmp/letsencrypt-log/.certbot.lock'
Either run as root, or set --config-dir, --work-dir, and --logs-dir to writeable paths.
    at ChildProcess.exithandler (node:child_process:402:12)
    at ChildProcess.emit (node:events:513:28)
    at maybeClose (node:internal/child_process:1100:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5)

Didn't notice this error before do you know if there is a way to move the paths that cannot be accessed to within the writable docker folder for example?

[evanlabs]

This problem has been solved in the v2.10.2 version, and I tested the docker container on CentOS and Debian without any problems.

Thanks to the developer for fixing this issue quickly.

[ituri]

What do I need to change on a system that has been working fine up until this recent bug? I'm already on v2.10.2 but it's not working yet. Still getting this:

s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service prepare: starting ❯ Configuring npmuser ... id: 'npmuser': no such user ❯ Checking paths ... ❯ Setting ownership ... s6-rc: fatal: timed out /run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information. s6-sudoc: fatal: unable to get exit status from server: Operation timed out

[zandhaas]

I also have the same issue as @ituri has.

I running the nginx-pm on my Synology Returned to v 2.9.22 again

[azchoi]

I also have the same issue as @ituri has.

I running the nginx-pm on my Synology Returned to v 2.9.22 again

I've reinstall 2.10.2 to Synology 7.1.1 without PUID/PGID and issue has been solved. Are you using PUID/PGID?

Here is my Log....

---

| \ | | | \/ | | | | |) | |\/| | | |\ | _/| | | | || _|| || |_|

User ID: 0 Group ID: 0

s6-rc: info: service prepare successfully started s6-rc: info: service nginx: starting s6-rc: info: service frontend: starting s6-rc: info: service backend: starting s6-rc: info: service nginx successfully started s6-rc: info: service frontend successfully started s6-rc: info: service backend successfully started s6-rc: info: service legacy-services: starting ❯ Starting nginx ... ❯ Starting backend ... s6-rc: info: service legacy-services successfully started

[zandhaas]

I've reinstall 2.10.2 to synology 7.1.1 without PUID/PGID and issue has been solved. Are you using PUID/PGID? No I do not use the PUID and GUID.

[3/31/2023] [9:54:38 AM] [Global ] › ℹ info Using MySQL configuration ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... [3/31/2023] [9:54:41 AM] [Migrate ] › ℹ info Current database version: 20211108145214 nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [9:54:41 AM] [Setup ] › ℹ info Logrotate Timer initialized [3/31/2023] [9:54:41 AM] [Setup ] › ℹ info Logrotate completed. [3/31/2023] [9:54:41 AM] [IP Ranges] › ℹ info Fetching IP Ranges from online services... [3/31/2023] [9:54:41 AM] [IP Ranges] › ℹ info Fetching https://ip-ranges.amazonaws.com/ip-ranges.json [3/31/2023] [9:54:41 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v4 [3/31/2023] [9:54:41 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v6 [3/31/2023] [9:54:41 AM] [SSL ] › ℹ info Let's Encrypt Renewal Timer initialized [3/31/2023] [9:54:41 AM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [3/31/2023] [9:54:41 AM] [IP Ranges] › ℹ info IP Ranges Renewal Timer initialized [3/31/2023] [9:54:41 AM] [Global ] › ℹ info Backend PID 168 listening on port 3000 ... ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)

[azchoi]

te Timer initialized

Here is my script for your reference.

version: "3.8" services: app: image: 'jc21/nginx-proxy-manager:latest' restart: unless-stopped ports:

• '8080:80' # Public HTTP Port
• '8443:443' # Public HTTPS Port
• '81:81' # Admin Web Port environment: DB_MYSQL_HOST: "db_ip" DB_MYSQL_PORT: 3306 DB_MYSQL_USER: "db_user_name" DB_MYSQL_PASSWORD: "db_pw" DB_MYSQL_NAME: "db_name" TZ: Asia/Seoul # option volumes:
• '/volume1/docker/npm/data:/data'
• '/volume1/docker/npm/letsencrypt:/etc/letsencrypt'

[zandhaas]

Are you starting docker-compose as root user or as an other user?? I'm starting it as root user.

[azchoi]

Are you starting docker-compose as root user or as an other user?? I'm starting it as root user.

root.

sudo -i docker-compose up -d

[zandhaas]

That's what I do. The only difference is that I use a macvlan configuration so I using the original ports 80 and 443. I try to intall a seperate test nginx-pm the way you have.

[zandhaas]

Created a complete new nginx-pm container with corresponding DB. Below my log

s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service prepare: starting ❯ Configuring npmuser ... id: 'npmuser': no such user ❯ Checking paths ... ❯ Setting ownership ... ❯ Dynamic resolvers ... ❯ IPv6 ... Enabling IPV6 in hosts in: /etc/nginx/conf.d

• /etc/nginx/conf.d/default.conf
• /etc/nginx/conf.d/include/assets.conf
• /etc/nginx/conf.d/include/block-exploits.conf
• /etc/nginx/conf.d/include/force-ssl.conf
• /etc/nginx/conf.d/include/ip_ranges.conf
• /etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf
• /etc/nginx/conf.d/include/proxy.conf
• /etc/nginx/conf.d/include/ssl-ciphers.conf
• /etc/nginx/conf.d/include/resolvers.conf
• /etc/nginx/conf.d/production.conf Enabling IPV6 in hosts in: /data/nginx ❯ Docker secrets ...

---

---

| \ | | | \/ | | | | |) | |\/| | | |\ | _/| | | | || _|| || |_|

User UID: 911 User GID: 911

s6-rc: info: service prepare successfully started s6-rc: info: service nginx: starting s6-rc: info: service frontend: starting s6-rc: info: service backend: starting s6-rc: info: service frontend successfully started ❯ Starting nginx ... s6-rc: info: service backend successfully started ❯ Starting backend ... s6-rc: info: service nginx successfully started s6-rc: info: service legacy-services: starting s6-rc: info: service legacy-services successfully started nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:27 AM] [Global ] › ℹ info Using MySQL configuration [3/31/2023] [10:15:27 AM] [Global ] › ℹ info Creating a new JWT key pair... ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:35 AM] [Global ] › ℹ info Wrote JWT key pair to config file: /data/keys.json ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:38 AM] [Migrate ] › ℹ info Current database version: 20211108145214 ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:39 AM] [Setup ] › ℹ info Logrotate Timer initialized [3/31/2023] [10:15:39 AM] [Setup ] › ℹ info Logrotate completed. [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info Fetching IP Ranges from online services... [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info Fetching https://ip-ranges.amazonaws.com/ip-ranges.json [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v4 [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v6 [3/31/2023] [10:15:39 AM] [SSL ] › ℹ info Let's Encrypt Renewal Timer initialized [3/31/2023] [10:15:39 AM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info IP Ranges Renewal Timer initialized [3/31/2023] [10:15:39 AM] [Global ] › ℹ info Backend PID 128 listening on port 3000 ... ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:41 AM] [SSL ] › ✖ error Error: Command failed: /usr/sbin/nginx -t -g "error_log off;" nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) nginx: configuration file /etc/nginx/nginx.conf test failed

at ChildProcess.exithandler (node:child_process:402:12)
at ChildProcess.emit (node:events:513:28)
at maybeClose (node:internal/child_process:1100:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5)

❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) etc etc

[azchoi]

User ID: 0 Group ID: 0

Created a complete new nginx-pm container with corresponding DB. Below my log

s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service prepare: starting ❯ Configuring npmuser ... id: 'npmuser': no such user ❯ Checking paths ... ❯ Setting ownership ... ❯ Dynamic resolvers ... ❯ IPv6 ... Enabling IPV6 in hosts in: /etc/nginx/conf.d

• /etc/nginx/conf.d/default.conf
• /etc/nginx/conf.d/include/assets.conf
• /etc/nginx/conf.d/include/block-exploits.conf
• /etc/nginx/conf.d/include/force-ssl.conf
• /etc/nginx/conf.d/include/ip_ranges.conf
• /etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf
• /etc/nginx/conf.d/include/proxy.conf
• /etc/nginx/conf.d/include/ssl-ciphers.conf
• /etc/nginx/conf.d/include/resolvers.conf
• /etc/nginx/conf.d/production.conf Enabling IPV6 in hosts in: /data/nginx ❯ Docker secrets ...

| \ | | _ | / |

| | | |_) | |/| | | |\ | _/| | | | || || || ||

User UID: 911

User GID: 911 s6-rc: info: service prepare successfully started s6-rc: info: service nginx: starting s6-rc: info: service frontend: starting s6-rc: info: service backend: starting s6-rc: info: service frontend successfully started ❯ Starting nginx ... s6-rc: info: service backend successfully started ❯ Starting backend ... s6-rc: info: service nginx successfully started s6-rc: info: service legacy-services: starting s6-rc: info: service legacy-services successfully started nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:27 AM] [Global ] › ℹ info Using MySQL configuration [3/31/2023] [10:15:27 AM] [Global ] › ℹ info Creating a new JWT key pair... ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:35 AM] [Global ] › ℹ info Wrote JWT key pair to config file: /data/keys.json ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:38 AM] [Migrate ] › ℹ info Current database version: 20211108145214 ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:39 AM] [Setup ] › ℹ info Logrotate Timer initialized [3/31/2023] [10:15:39 AM] [Setup ] › ℹ info Logrotate completed. [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info Fetching IP Ranges from online services... [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info Fetching https://ip-ranges.amazonaws.com/ip-ranges.json [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v4 [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v6 [3/31/2023] [10:15:39 AM] [SSL ] › ℹ info Let's Encrypt Renewal Timer initialized [3/31/2023] [10:15:39 AM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [3/31/2023] [10:15:39 AM] [IP Ranges] › ℹ info IP Ranges Renewal Timer initialized [3/31/2023] [10:15:39 AM] [Global ] › ℹ info Backend PID 128 listening on port 3000 ... ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) [3/31/2023] [10:15:41 AM] [SSL ] › ✖ error Error: Command failed: /usr/sbin/nginx -t -g "error_log off;" nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) nginx: configuration file /etc/nginx/nginx.conf test failed

at ChildProcess.exithandler (node:child_process:402:12)
at ChildProcess.emit (node:events:513:28)
at maybeClose (node:internal/child_process:1100:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5)

❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ❯ Starting nginx ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) etc etc

BTW, below ID is different from me.

User ID: 0 Group ID: 0