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

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

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:

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

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.

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

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.

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 😃

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

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.

problem solved please let me know thanks.

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.

I used

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

to revert to 2.9.22.

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

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

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

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

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

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.

Same issue

• Synology DS918+
• DSM 7.1.1-42962 Update 4

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

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.

I’ve got the same problem since the update

Problem still exists. Tried it with latest release on RouterOS 7.10.1. I have tried the following scenarios：

• Don’t set PUID and PGID
• Set PUID and PGID to 0

- PUID=0
- PGID=0

• Set PUID and PGID to 1000

- PUID=1000
- PGID=1000

With v2.10.3, npm is now working perfectly again on my Synology. 🎉 I removed

- PUID=0
- PGID=0

from my env vars and that’s it.

I tested a fresh install and several server reboots and npm didn’t have any issues starting up anymore.

Thanks for the work on this @jc21 !

To avoid the error s6-sudoc: fatal: unable to get exit status from server: Operation timed out I added the line

-e S6_CMD_WAIT_FOR_SERVICES_MAXTIME=60000 \

to my docker run command.

With this line and without PUID and PGID it is working fine.

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.

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.

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?

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

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

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

Same. Using podman on Rocky Linux.