[GH-ISSUE #3174] [RouterOS] a duplicate default server for 0.0.0.0:81 in /etc/nginx/conf.d/production.conf #2149

New issue

Open

opened 2026-02-26 07:34:14 +03:00 by kerem · 14 comments

kerem commented 2026-02-26 07:34:14 +03:00

Owner

Copy link

Originally created by @nobodyspecial on GitHub (Sep 1, 2023).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/3174

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
I'm trying to run the docker on a Mikotik RB5009 running RouterOS 7.11 and the container fails to start with error:

nginx: [emerg] a duplicate default server for 0.0.0.0:81 in /etc/nginx/conf.d/production.conf:3

I can get the container running by deleting the file /etc/nginx/conf.d/dev.conf but I don't think this is the right way to get this working.

Nginx Proxy Manager Version
2.10.4 (ARM64)

To Reproduce
Steps to reproduce the behavior:

1. pull docker container in RouterOS
2. Start it with logging enabled
3. See error in log

Expected behavior
nginx starts

Operating System
RouterOS 7.11 (ARM64)

Additional context
I had this container running fine on this platform for months but a recent update changed something. I'm not sure if an NPM or RouterOS update is the cause. Also, the container runs without issue with the dev.conf file removed.

Originally created by @nobodyspecial on GitHub (Sep 1, 2023). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/3174 <!-- Are you in the right place? - If you are looking for support on how to get your upstream server forwarding, please consider asking the community on Reddit. - If you are writing code changes to contribute and need to ask about the internals of the software, Gitter is the best place to ask. - If you think you found a bug with NPM (not Nginx, or your upstream server or MySql) then you are in the *right place.* --> **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** I'm trying to run the docker on a Mikotik RB5009 running RouterOS 7.11 and the container fails to start with error: `nginx: [emerg] a duplicate default server for 0.0.0.0:81 in /etc/nginx/conf.d/production.conf:3` I can get the container running by deleting the file /etc/nginx/conf.d/dev.conf but I don't think this is the right way to get this working. **Nginx Proxy Manager Version** 2.10.4 (ARM64) **To Reproduce** Steps to reproduce the behavior: 1. pull docker container in RouterOS 2. Start it with logging enabled 3. See error in log **Expected behavior** nginx starts **Operating System** RouterOS 7.11 (ARM64) **Additional context** I had this container running fine on this platform for months but a recent update changed something. I'm not sure if an NPM or RouterOS update is the cause. Also, the container runs without issue with the dev.conf file removed.

kerem added the

bug

label 2026-02-26 07:34:14 +03:00

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@broco2002 commented on GitHub (Sep 10, 2023):

Can confirm on Mikrotik RB5009 running RouterOS 7.11.2 using jc21/nginx-proxy-manager:latest (v2.10.4)
Workaround (deleting /etc/nginx/conf.d/dev.conf) still helps.

Seems like this file from the develop branch made it into the production build.

<!-- gh-comment-id:1712934407 --> @broco2002 commented on GitHub (Sep 10, 2023): Can confirm on Mikrotik RB5009 running RouterOS 7.11.2 using `jc21/nginx-proxy-manager:latest` (v2.10.4) Workaround (deleting /etc/nginx/conf.d/dev.conf) still helps. Seems like this file from the develop branch made it into the production build.

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@nhan6310 commented on GitHub (Mar 8, 2024):

hello. Can you guide me to install it on mikrotik?

<!-- gh-comment-id:1986326210 --> @nhan6310 commented on GitHub (Mar 8, 2024): hello. Can you guide me to install it on mikrotik?

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@Piloo116 commented on GitHub (Mar 18, 2024):

Hi guys. How did you remove /etc/nginx/conf.d/dev.conf ?

<!-- gh-comment-id:2002737272 --> @Piloo116 commented on GitHub (Mar 18, 2024): Hi guys. How did you remove /etc/nginx/conf.d/dev.conf ?

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@broco2002 commented on GitHub (Mar 18, 2024):

Hi guys. How did you remove /etc/nginx/conf.d/dev.conf ?

I just used FTP and removed it that way. I use a USB stick for the files and went to
ftp://192.168.0.1/usb1-part1/docker/nginxpm/root/etc/nginx/conf.d/ and then deleted the dev.conf.

<!-- gh-comment-id:2004854194 --> @broco2002 commented on GitHub (Mar 18, 2024): > Hi guys. How did you remove /etc/nginx/conf.d/dev.conf ? I just used FTP and removed it that way. I use a USB stick for the files and went to ftp://192.168.0.1/usb1-part1/docker/nginxpm/root/etc/nginx/conf.d/ and then deleted the dev.conf.

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@itsbhanusharma commented on GitHub (Jul 1, 2024):

RB5009, This issue continues with latest release of RouterOS (7.15.2) and NPM (v2.11.3)

I remove the dev.conf file using the container shell access in winbox.

> container/shell
> number: 1 # < Use the correct container number for your NPM Container when asked
> rm /etc/nginx/conf.d/dev.conf -y
> exit

Stop and Start the container for changes to take effect and it gets online.

<!-- gh-comment-id:2200230244 --> @itsbhanusharma commented on GitHub (Jul 1, 2024): RB5009, This issue continues with latest release of RouterOS (7.15.2) and NPM (v2.11.3) I remove the dev.conf file using the container shell access in winbox. ``` > container/shell > number: 1 # < Use the correct container number for your NPM Container when asked > rm /etc/nginx/conf.d/dev.conf -y > exit ``` Stop and Start the container for changes to take effect and it gets online.

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@Zignet64 commented on GitHub (Dec 7, 2024):

RouterOS (7.16.2) and NPM (v2.12.1)
same workaround needed

thanks @broco2002

<!-- gh-comment-id:2525328121 --> @Zignet64 commented on GitHub (Dec 7, 2024): RouterOS (7.16.2) and NPM (v2.12.1) same workaround needed thanks @broco2002

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@mrdrmmn commented on GitHub (Jan 2, 2025):

FWIW, this issues persistes in NPM v2.12.2. It looks like the dev build avoids this in the Dockerfile (github.com/NginxProxyManager/nginx-proxy-manager@ec12d8f9bf/docker/dev/Dockerfile) via the following:

RUN rm -f /etc/nginx/conf.d/production.conf
&& chmod 644 /etc/logrotate.d/nginx-proxy-manager
&& /tmp/install-s6 "${TARGETPLATFORM}"
&& rm -f /tmp/install-s6
&& chmod 644 -R /root/.cache

I do find a similar bit of code that seems it should do the equivalent in the prod Dockerfile (github.com/NginxProxyManager/nginx-proxy-manager@ec12d8f9bf/docker/Dockerfile):

RUN rm -rf /etc/s6-overlay/s6-rc.d/user/contents.d/frontend /etc/nginx/conf.d/dev.conf
&& chmod 644 /etc/logrotate.d/nginx-proxy-manager

So I'm not sure how /etc/nginx/conf.d/dev.conf is still showing up in the production build on hub.docker.com.

<!-- gh-comment-id:2567366143 --> @mrdrmmn commented on GitHub (Jan 2, 2025): FWIW, this issues persistes in NPM v2.12.2. It looks like the dev build avoids this in the Dockerfile (https://github.com/NginxProxyManager/nginx-proxy-manager/blob/ec12d8f9bfeb40800078057186e6ca7781d4fd7f/docker/dev/Dockerfile) via the following: RUN rm -f /etc/nginx/conf.d/production.conf \ && chmod 644 /etc/logrotate.d/nginx-proxy-manager \ && /tmp/install-s6 "${TARGETPLATFORM}" \ && rm -f /tmp/install-s6 \ && chmod 644 -R /root/.cache I do find a similar bit of code that seems it should do the equivalent in the prod Dockerfile (https://github.com/NginxProxyManager/nginx-proxy-manager/blob/ec12d8f9bfeb40800078057186e6ca7781d4fd7f/docker/Dockerfile): RUN rm -rf /etc/s6-overlay/s6-rc.d/user/contents.d/frontend /etc/nginx/conf.d/dev.conf \ && chmod 644 /etc/logrotate.d/nginx-proxy-manager So I'm not sure how /etc/nginx/conf.d/dev.conf is still showing up in the production build on hub.docker.com.

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@Simon-CR commented on GitHub (Feb 12, 2025):

this is still happening as of feb 12th 2025.

<!-- gh-comment-id:2654229133 --> @Simon-CR commented on GitHub (Feb 12, 2025): this is still happening as of feb 12th 2025.

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@foegra commented on GitHub (Mar 9, 2025):

well, it's 1.5k open issues...

<!-- gh-comment-id:2708834725 --> @foegra commented on GitHub (Mar 9, 2025): well, it's 1.5k open issues...

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@FrankenLab commented on GitHub (Apr 15, 2025):

Same problem, workaround works, wasted a lot of time tracking this down and this issue's been open 1.5yrs....

<!-- gh-comment-id:2803864272 --> @FrankenLab commented on GitHub (Apr 15, 2025): Same problem, workaround works, wasted a lot of time tracking this down and this issue's been open 1.5yrs....

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@kcastner commented on GitHub (Aug 17, 2025):

Same issue today to me :) find out myself via logs - just deleted dev.conf because its most identical with production.conf. now it works. Next time, i should lookup the issue first :P

RouterOS: 7.19.2 Stable x86_64 CHR
NPM: v2.12.6

<!-- gh-comment-id:3194425562 --> @kcastner commented on GitHub (Aug 17, 2025): Same issue today to me :) find out myself via logs - just deleted dev.conf because its most identical with production.conf. now it works. Next time, i should lookup the issue first :P RouterOS: 7.19.2 Stable x86_64 CHR NPM: v2.12.6

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@mrdrmmn commented on GitHub (Aug 26, 2025):

So I think I can shed some light on this. I don't think this is truly an issue with nginx-proxy-manager, but rather an issue with overlayfs and the underlying filesystem. When layering images together like nginx-proxy-manager does, overlayfs relies on "whiteout" files to hide removed files. This allows multiple images to rely on shared layers even if it contains files what need to be removed in the final image.

From what I can tell, FAT32 and ZFS both have issues with overlayfs. In the case of routeros, you might avoid the problem by using ext4 as the underlying filesystem.

My workaround has been to create an empty file on the host, and then mount that over the problematic file in the container as a volume. Using the docker cli that looks something like this:

docker run -v /path/to/emptyfile:/etc/nginx/conf.d/dev.conf:ro

That all said, this problem could be addressed in the docker image creation process by flattening it. This link provides info on how that could be done:
https://stackoverflow.com/questions/22713551/how-to-flatten-a-docker-image

There are pros and cons to doing this. Specifically it would result in a smaller overall image for ngnix-proxy-manager, but if you have other images that share the same layers, your overall disk usage for docker images may go up.

In any case, just figured I would mention all of this to hopefully make someone's life a little easier... :)

<!-- gh-comment-id:3224711710 --> @mrdrmmn commented on GitHub (Aug 26, 2025): So I think I can shed some light on this. I don't think this is truly an issue with nginx-proxy-manager, but rather an issue with overlayfs and the underlying filesystem. When layering images together like nginx-proxy-manager does, overlayfs relies on "whiteout" files to hide removed files. This allows multiple images to rely on shared layers even if it contains files what need to be removed in the final image. From what I can tell, FAT32 and ZFS both have issues with overlayfs. In the case of routeros, you might avoid the problem by using ext4 as the underlying filesystem. My workaround has been to create an empty file on the host, and then mount that over the problematic file in the container as a volume. Using the docker cli that looks something like this: docker run -v /path/to/emptyfile:/etc/nginx/conf.d/dev.conf:ro That all said, this problem could be addressed in the docker image creation process by flattening it. This link provides info on how that could be done: https://stackoverflow.com/questions/22713551/how-to-flatten-a-docker-image There are pros and cons to doing this. Specifically it would result in a smaller overall image for ngnix-proxy-manager, but if you have other images that share the same layers, your overall disk usage for docker images may go up. In any case, just figured I would mention all of this to hopefully make someone's life a little easier... :)

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@kcastner commented on GitHub (Aug 27, 2025):

@mrdrmmn i already tried that as mount. Does Not Work in routeros on my side.

Already tried mounting an empty file. Just got a script to remote it after an update.

Im using routeros as chr - i dont have an option to add additional storage. Is it possible to change the filesystem at routeros side?

<!-- gh-comment-id:3228166845 --> @kcastner commented on GitHub (Aug 27, 2025): @mrdrmmn i already tried that as mount. Does Not Work in routeros on my side. Already tried mounting an empty file. Just got a script to remote it after an update. Im using routeros as chr - i dont have an option to add additional storage. Is it possible to change the filesystem at routeros side?

kerem commented 2026-02-26 07:34:15 +03:00

Author

Owner

Copy link

@mrdrmmn commented on GitHub (Sep 1, 2025):

Hmm, strange that mounting an empty file didn't work. Sounds like there must be something else going on with RouterOS to make that not help as there should be no way for the os to see the contents of the file if you've successfully mounted over. My best guess is that for whatever reason the mount you are setting is not actually getting applied.

Here an example of testing the mount from the commandline using podman. It should work identically replacing 'podman' with 'docker':

# The container running an ls without the mount:
root@podman:~# podman run --entrypoint '/bin/bash' -it docker.io/jc21/nginx-proxy-manager -c 'ls -l /etc/nginx/conf.d/dev.conf'
-rw-r--r-- 1 root root 625 Jul  9 21:19 /etc/nginx/conf.d/dev.conf

# Creating an empty file and running the same command with the mount over dev.conf 
root@podman:~# cat /dev/null > empty
root@podman:~# podman run --entrypoint '/bin/bash' -v ./empty:/etc/nginx/conf.d/dev.conf -it docker.io/jc21/nginx-proxy-manager -c 'ls -l /etc/nginx/conf.d/dev.conf'
-rw-r--r-- 1 root root 0 Sep  1 01:28 /etc/nginx/conf.d/dev.conf

I would be curious to see of you can reproduce this result on your side.

I might be able to try installing routeros in a vm to testing this myself in the next couple of days.

<!-- gh-comment-id:3240626946 --> @mrdrmmn commented on GitHub (Sep 1, 2025): Hmm, strange that mounting an empty file didn't work. Sounds like there must be something else going on with RouterOS to make that not help as there should be no way for the os to see the contents of the file if you've successfully mounted over. My best guess is that for whatever reason the mount you are setting is not actually getting applied. Here an example of testing the mount from the commandline using podman. It should work identically replacing 'podman' with 'docker': ``` # The container running an ls without the mount: root@podman:~# podman run --entrypoint '/bin/bash' -it docker.io/jc21/nginx-proxy-manager -c 'ls -l /etc/nginx/conf.d/dev.conf' -rw-r--r-- 1 root root 625 Jul 9 21:19 /etc/nginx/conf.d/dev.conf # Creating an empty file and running the same command with the mount over dev.conf root@podman:~# cat /dev/null > empty root@podman:~# podman run --entrypoint '/bin/bash' -v ./empty:/etc/nginx/conf.d/dev.conf -it docker.io/jc21/nginx-proxy-manager -c 'ls -l /etc/nginx/conf.d/dev.conf' -rw-r--r-- 1 root root 0 Sep 1 01:28 /etc/nginx/conf.d/dev.conf ``` I would be curious to see of you can reproduce this result on your side. I might be able to try installing routeros in a vm to testing this myself in the next couple of days.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

develop

dependabot/npm_and_yarn/backend/liquidjs-10.25.7

dependabot/npm_and_yarn/frontend/prod-minor-updates-2a16bf3987

dependabot/npm_and_yarn/frontend/dev-patch-updates-754666cf41

dependabot/npm_and_yarn/backend/basic-ftp-5.3.0

dependabot/npm_and_yarn/test/follow-redirects-1.16.0

dependabot/npm_and_yarn/test/axios-1.15.0

dependabot/npm_and_yarn/frontend/lodash-4.18.1

dependabot/npm_and_yarn/backend/lodash-4.18.1

dependabot/npm_and_yarn/test/lodash-4.18.1

dependabot/npm_and_yarn/frontend/vite-7.3.2

dependabot/npm_and_yarn/backend/prod-minor-updates-5ec19a7f21

dependabot/npm_and_yarn/frontend/lodash-es-4.18.1

dependabot/npm_and_yarn/frontend/happy-dom-20.8.9

dependabot/npm_and_yarn/backend/path-to-regexp-8.4.0

dependabot/npm_and_yarn/frontend/picomatch-4.0.4

dependabot/npm_and_yarn/backend/picomatch-2.3.2

dependabot/npm_and_yarn/frontend/yaml-1.10.3

dependabot/npm_and_yarn/test/flatted-3.4.2

dependabot/npm_and_yarn/test/tar-7.5.11

dependabot/npm_and_yarn/frontend/immutable-5.1.5

master

dependabot/npm_and_yarn/test/glob-10.5.0

dependabot/npm_and_yarn/frontend/mdast-util-to-hast-13.2.1

dependabot/npm_and_yarn/test/form-data-4.0.4

v3-abandoned

bump-freedns

openidc

ssl-passthrough-hosts

static-content

v2.14.0

v2.13.7

v2.13.6

v2.13.5

v2.13.4

v2.13.3

v2.13.2

v2.13.1

v2.13.0

v2.12.6

v2.12.5

v2.12.4

v2.12.3

v2.12.2

v2.12.1

v2.12.0

v2.11.3

v2.11.2

v2.11.1

v2.11.0

v2.10.4

v2.10.3

v2.10.2

v2.10.1

v2.10.0

v2.9.22

v2.9.21

v2.9.20

v2.9.19

v2.9.18

v2.9.17

v2.9.16

v2.9.15

v2.9.14

v2.9.13

v2.9.12

v2.9.11

v2.9.10

v2.9.9

v2.9.8

v2.9.7

v2.9.6

v2.9.5

v2.9.4

v2.9.3

v2.9.2

v2.9.1

v2.9.0

v2.8.1

v2.8.0

v2.7.3

v2.7.2

v2.7.1

v2.7.0

v2.6.2

v2.6.1

v2.6.0

v2.5.0

v2.4.0

v2.3.1

v2.3.0

v2.2.4

v2.2.3

v2.2.2

v2.2.1

v2.2.0

v2.1.2

v2.1.1

v2.1.0

2.0.14

2.0.13

2.0.12

2.0.11

2.0.10

2.0.9

2.0.8

2.0.7

2.0.6

2.0.5

2.0.4

2.0.3

2.0.2

2.0.0

v2.0.0

1.1.2

1.1.1

1.0.1

Labels

Clear labels   

awaiting feedback

  

bug

  

cannot reproduce

  

dns provider request

  

duplicate

  

enhancement

  

enhancement

  

enhancement

  

good first issue

  

help wanted

  

invalid

  

need more info

  

no certbot plugin available

  

product-support

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

stale

  

troll

  

upstream issue

  

v2

  

v2

  

v2

  

v3

  

wontfix

No labels

awaiting feedback

bug

cannot reproduce

dns provider request

duplicate

enhancement

enhancement

enhancement

good first issue

help wanted

invalid

need more info

no certbot plugin available

product-support

pull-request

question

stale

troll

upstream issue

v2

v2

v2

v3

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/nginx-proxy-manager-NginxProxyManager#2149

No description provided.