[GH-ISSUE #4205] Container will not restart due to chmod operation not permitted. Only works after a fresh install. #2722

New issue

Closed

opened 2026-02-26 07:36:35 +03:00 by kerem · 23 comments

kerem commented 2026-02-26 07:36:35 +03:00

Owner

Copy link

Originally created by @AlvaroMartinezB on GitHub (Dec 3, 2024).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/4205

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

The NPM container will not start after restarting the docker engine for any reason. It works fine on a fresh install, but fails to start after any restart. The error happens during "Setting ownership ..."

2.12.1 (lastest)

To Reproduce
Steps to reproduce the behavior:

1. Configure an NPM instance. Log in, setup credentials, configure proxy host with let's encrypt SSL.
2. Restart docker engine (for any reason, like updates or applying a memory size change)
3. Try to start NPM
4. Observe error in terminal logs

Expected behavior

NPM should start with no issues.

Screenshots

Operating System

Ubuntu 24.04.1

Additional context

Here are the terminal logs:

npm-app-1 | ❯ Configuring npm user ...
npm-app-1 | 0
npm-app-1 | usermod: no changes
npm-app-1 | ❯ Configuring npm group ...
npm-app-1 | ❯ Checking paths ...
npm-app-1 | ❯ Setting ownership ...
npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-1/cert.pem': Operation not permitted
npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-1/chain.pem': Operation not permitted
npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-1/fullchain.pem': Operation not permitted
npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-1/privkey.pem': Operation not permitted
npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-2/cert.pem': Operation not permitted
npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-2/chain.pem': Operation not permitted
npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-2/fullchain.pem': Operation not permitted
npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-2/privkey.pem': Operation not permitted
npm-app-1 | s6-rc: warning: unable to start service prepare: command exited 1
npm-app-1 | /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.

Originally created by @AlvaroMartinezB on GitHub (Dec 3, 2024). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/4205 **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** <!-- A clear and concise description of what the bug is. --> The NPM container will not start after restarting the docker engine for any reason. It works fine on a fresh install, but fails to start after any restart. The error happens during "Setting ownership ..." **2.12.1 (lastest)** <!-- What version of Nginx Proxy Manager is reported on the login page? --> **To Reproduce** Steps to reproduce the behavior: 1. Configure an NPM instance. Log in, setup credentials, configure proxy host with let's encrypt SSL. 2. Restart docker engine (for any reason, like updates or applying a memory size change) 3. Try to start NPM 4. Observe error in terminal logs **Expected behavior** <!-- A clear and concise description of what you expected to happen. --> NPM should start with no issues. **Screenshots** <!-- If applicable, add screenshots to help explain your problem. --> **Operating System** <!-- Please specify if using a Rpi, Mac, orchestration tool or any other setups that might affect the reproduction of this error. --> Ubuntu 24.04.1 **Additional context** <!-- Add any other context about the problem here, docker version, browser version, logs if applicable to the problem. Too much info is better than too little. --> Here are the terminal logs: npm-app-1 | ❯ Configuring npm user ... npm-app-1 | 0 npm-app-1 | usermod: no changes npm-app-1 | ❯ Configuring npm group ... npm-app-1 | ❯ Checking paths ... npm-app-1 | ❯ Setting ownership ... npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-1/cert.pem': Operation not permitted npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-1/chain.pem': Operation not permitted npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-1/fullchain.pem': Operation not permitted npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-1/privkey.pem': Operation not permitted npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-2/cert.pem': Operation not permitted npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-2/chain.pem': Operation not permitted npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-2/fullchain.pem': Operation not permitted npm-app-1 | chown: changing ownership of '/etc/letsencrypt/live/npm-2/privkey.pem': Operation not permitted npm-app-1 | s6-rc: warning: unable to start service prepare: command exited 1 npm-app-1 | /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.

kerem 2026-02-26 07:36:35 +03:00

• closed this issue
• added the
  bug
  label

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@VividDocument7 commented on GitHub (Dec 3, 2024):

Same issue here except I can't even install it. It just won't run at all

<!-- gh-comment-id:2513523072 --> @VividDocument7 commented on GitHub (Dec 3, 2024): Same issue here except I can't even install it. It just won't run at all

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@suprexus commented on GitHub (Dec 5, 2024):

Same here.
Work around for me was to change permissions of the letsencrypt/live directory on the host itself.

sudo chmod -R 775 letsencrypt_dir/live

Survives container restarts after that.

<!-- gh-comment-id:2519070465 --> @suprexus commented on GitHub (Dec 5, 2024): Same here. Work around for me was to change permissions of the letsencrypt/live directory on the host itself. sudo chmod -R 775 letsencrypt_dir/live Survives container restarts after that.

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@sonpeter88 commented on GitHub (Dec 16, 2024):

I have the same issue.
sudo chmopd -R 775 /live
doesn't seem to work for me

<!-- gh-comment-id:2546412617 --> @sonpeter88 commented on GitHub (Dec 16, 2024): I have the same issue. `sudo chmopd -R 775 /live` doesn't seem to work for me

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@suprexus commented on GitHub (Dec 16, 2024):

Check your path - /live doesn't seem correct. Check your docker config to see where you're saving the letsencrypt files.

sudo chmod -R 775 letsencrypt_dir/live

<!-- gh-comment-id:2546421005 --> @suprexus commented on GitHub (Dec 16, 2024): Check your path - /live doesn't seem correct. Check your docker config to see where you're saving the letsencrypt files. sudo chmod -R 775 letsencrypt_dir/live

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@sonpeter88 commented on GitHub (Dec 16, 2024):

The path seems correct. I just ommitted putting in letsencrypt_dir since it's different for everyone. the live folder has the application folder with pem files within it.

the files have rwx permissions

<!-- gh-comment-id:2546432485 --> @sonpeter88 commented on GitHub (Dec 16, 2024): The path seems correct. I just ommitted putting in letsencrypt_dir since it's different for everyone. the live folder has the application folder with pem files within it. the files have rwx permissions

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@suprexus commented on GitHub (Dec 16, 2024):

Gotcha - What user owns the directory? If you're specifying a PUID in your docker compose file, it should be the same user.

<!-- gh-comment-id:2546441384 --> @suprexus commented on GitHub (Dec 16, 2024): Gotcha - What user owns the directory? If you're specifying a PUID in your docker compose file, it should be the same user.

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@sonpeter88 commented on GitHub (Dec 16, 2024):

I actually tried specifying user/group (1000:1000) in my docker compose but it got angry that it has to run as root so i assume my docker is already running as root.

ls -al in letsencrypt_dir/live/npm-3 folder shows

lrwxrwxrwx1 peter peter
which is uid=1000 and gid=1000

<!-- gh-comment-id:2546571874 --> @sonpeter88 commented on GitHub (Dec 16, 2024): I actually tried specifying user/group (1000:1000) in my docker compose but it got angry that it has to run as root so i assume my docker is already running as root. ls -al in letsencrypt_dir/live/npm-3 folder shows lrwxrwxrwx1 peter peter which is uid=1000 and gid=1000

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@jaysee260 commented on GitHub (Dec 17, 2024):

In the same boat as @sonpeter88 ... sudo chmod -R 775 /path/to/letsencrypt/live in my host machine doesn't seem to work either 😞 .

<!-- gh-comment-id:2548901636 --> @jaysee260 commented on GitHub (Dec 17, 2024): In the same boat as @sonpeter88 ... `sudo chmod -R 775 /path/to/letsencrypt/live` in my host machine doesn't seem to work either :disappointed: .

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@sonpeter88 commented on GitHub (Dec 18, 2024):

okay I figured out a way to get it to work. The files in live folder are symlinks to the ../../archive/ folders and aren't happy when you try to chmod them on my ubuntu machine. I deleted all the symlinks in the live folder, and directly copied the pem files from the archive folder. Once I've done that and gave the files the correct permission, the container was able to restart fine.
Thanks for the tip @suprexus

<!-- gh-comment-id:2552371531 --> @sonpeter88 commented on GitHub (Dec 18, 2024): okay I figured out a way to get it to work. The files in live folder are symlinks to the ../../archive/ folders and aren't happy when you try to chmod them on my ubuntu machine. I deleted all the symlinks in the live folder, and directly copied the pem files from the archive folder. Once I've done that and gave the files the correct permission, the container was able to restart fine. Thanks for the tip @suprexus

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@jaysee260 commented on GitHub (Dec 19, 2024):

okay I figured out a way to get it to work. The files in live folder are symlinks to the ../../archive/ folders and aren't happy when you try to chmod them on my ubuntu machine. I deleted all the symlinks in the live folder, and directly copied the pem files from the archive folder. Once I've done that and gave the files the correct permission, the container was able to restart fine. Thanks for the tip @suprexus

heh, really nice catch @sonpeter88 ... thanks, I tried it and this works!

<!-- gh-comment-id:2552639050 --> @jaysee260 commented on GitHub (Dec 19, 2024): > okay I figured out a way to get it to work. The files in live folder are symlinks to the ../../archive/ folders and aren't happy when you try to chmod them on my ubuntu machine. I deleted all the symlinks in the live folder, and directly copied the pem files from the archive folder. Once I've done that and gave the files the correct permission, the container was able to restart fine. Thanks for the tip @suprexus heh, really nice catch @sonpeter88 ... thanks, I tried it and this works!

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@jaysee260 commented on GitHub (Dec 20, 2024):

Hate to report this, but this doesn't really seem to be a stable/lasting solution...

1. When you try to renew the LetsEncrypt cert, you get an error saying symlinks were expected on the *.pem files.
2. I suddenly started getting an issue where I could just not login into the Nginx Manager portal as my admin user.

I'm sure I was using the right credentials, I have them written down. Would straight up just fail authentication. I got so frustrated I just restarted everything from scratch. If it happens again, I'll capture logs and share.

Anyway, this seems like a temporary workaround at best.

<!-- gh-comment-id:2556139889 --> @jaysee260 commented on GitHub (Dec 20, 2024): Hate to report this, but this doesn't really seem to be a stable/lasting solution... 1) When you try to renew the LetsEncrypt cert, you get an error saying symlinks were expected on the `*.pem` files. 2) I suddenly started getting an issue where I could just not login into the Nginx Manager portal as my admin user. I'm sure I was using the right credentials, I have them written down. Would straight up just fail authentication. I got so frustrated I just restarted everything from scratch. If it happens again, I'll capture logs and share. Anyway, this seems like a temporary workaround at best.

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@suprexus commented on GitHub (Dec 20, 2024):

I didn't change the symlinks - What I probably did do was change the permissions on the entire npm directory to include the ../../archive/. Try recreating the symlinks and chmod the entire directory.

<!-- gh-comment-id:2557299505 --> @suprexus commented on GitHub (Dec 20, 2024): I didn't change the symlinks - What I probably did do was change the permissions on the entire npm directory to include the ../../archive/. Try recreating the symlinks and chmod the entire directory.

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@jaysee260 commented on GitHub (Dec 21, 2024):

@suprexus -sigh- that doesn't seem to work, still getting

2024-12-21 10:09:57 ❯ Configuring npm user ...
2024-12-21 10:09:57 ❯ Configuring npm group ...
2024-12-21 10:09:58 ❯ Checking paths ...
2024-12-21 10:09:58 ❯ Setting ownership ...
2024-12-21 10:09:57 useradd warning: npm's uid 0 outside of the UID_MIN 1000 and UID_MAX 60000 range.
2024-12-21 10:09:58 chown: changing ownership of '/etc/letsencrypt/live/npm-1/chain.pem': Operation not permitted
2024-12-21 10:09:58 chown: changing ownership of '/etc/letsencrypt/live/npm-1/cert.pem': Operation not permitted
2024-12-21 10:09:58 chown: changing ownership of '/etc/letsencrypt/live/npm-1/fullchain.pem': Operation not permitted
2024-12-21 10:09:58 chown: changing ownership of '/etc/letsencrypt/live/npm-1/privkey.pem': Operation not permitted
2024-12-21 10:09:58 s6-rc: warning: unable to start service prepare: command exited 1
2024-12-21 10:09:58 /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.

Even went as far as making sure I set the proper permissions to the entire letsencrypt directory with sudo chmod -R 775 /path/to/letsencrypt.

The only thing that's "worked" so far is @sonpeter88's suggestion to remove the symlinks and copy the *.pem files from ../../archive, but as pointed out earlier, that solution is unstable, and causes other issues.

Will keep digging...

<!-- gh-comment-id:2558148219 --> @jaysee260 commented on GitHub (Dec 21, 2024): @suprexus -sigh- that doesn't seem to work, still getting ```bash 2024-12-21 10:09:57 ❯ Configuring npm user ... 2024-12-21 10:09:57 ❯ Configuring npm group ... 2024-12-21 10:09:58 ❯ Checking paths ... 2024-12-21 10:09:58 ❯ Setting ownership ... 2024-12-21 10:09:57 useradd warning: npm's uid 0 outside of the UID_MIN 1000 and UID_MAX 60000 range. 2024-12-21 10:09:58 chown: changing ownership of '/etc/letsencrypt/live/npm-1/chain.pem': Operation not permitted 2024-12-21 10:09:58 chown: changing ownership of '/etc/letsencrypt/live/npm-1/cert.pem': Operation not permitted 2024-12-21 10:09:58 chown: changing ownership of '/etc/letsencrypt/live/npm-1/fullchain.pem': Operation not permitted 2024-12-21 10:09:58 chown: changing ownership of '/etc/letsencrypt/live/npm-1/privkey.pem': Operation not permitted 2024-12-21 10:09:58 s6-rc: warning: unable to start service prepare: command exited 1 2024-12-21 10:09:58 /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. ``` Even went as far as making sure I set the proper permissions to the _entire_ `letsencrypt` directory with `sudo chmod -R 775 /path/to/letsencrypt`. The _only_ thing that's "worked" so far is @sonpeter88's suggestion to remove the symlinks and copy the `*.pem` files from `../../archive`, but as pointed out earlier, that solution is unstable, and causes other issues. Will keep digging...

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@suprexus commented on GitHub (Dec 21, 2024):

What permissions are set on ../../archive/npm-1/

ls -la archive/npm-1/

are you running the container as a certain user?

<!-- gh-comment-id:2558199192 --> @suprexus commented on GitHub (Dec 21, 2024): What permissions are set on ../../archive/npm-1/ ls -la archive/npm-1/ are you running the container as a certain user?

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@jaysee260 commented on GitHub (Dec 22, 2024):

What permissions are set on ../../archive/npm-1

$ ll archive/npm-1/
total 48
drwxrwxr-x 2 jc jc 4096 Dec 19 21:27 .
drwxrwxr-x 3 jc jc 4096 Dec 19 21:27 ..
-rwxrwxr-x 1 jc jc 1314 Dec 19 21:27 cert1.pem
-rwxrwxr-x 1 jc jc 1566 Dec 19 21:27 chain1.pem
-rwxrwxr-x 1 jc jc 2880 Dec 19 21:27 fullchain1.pem
-rwxrwxr-x 1 jc jc  306 Dec 19 21:27 privkey1.pem

are you running the container as a certain user?

not another user than the one I usually use... as far as I'm aware?
same user I am running docker compose up -d with.

I ran docker inspect $(docker ps -q), and under the Config section of this container, I see the following for "User"

"Config": {
            "Hostname": "5f7a21d6b616",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": true,
            "AttachStderr": true,
           .....
}

<!-- gh-comment-id:2558320294 --> @jaysee260 commented on GitHub (Dec 22, 2024): > What permissions are set on ../../archive/npm-1 ```bash $ ll archive/npm-1/ total 48 drwxrwxr-x 2 jc jc 4096 Dec 19 21:27 . drwxrwxr-x 3 jc jc 4096 Dec 19 21:27 .. -rwxrwxr-x 1 jc jc 1314 Dec 19 21:27 cert1.pem -rwxrwxr-x 1 jc jc 1566 Dec 19 21:27 chain1.pem -rwxrwxr-x 1 jc jc 2880 Dec 19 21:27 fullchain1.pem -rwxrwxr-x 1 jc jc 306 Dec 19 21:27 privkey1.pem ``` > are you running the container as a certain user? not another user than the one I usually use... as far as I'm aware? same user I am running `docker compose up -d` with. I ran `docker inspect $(docker ps -q)`, and under the `Config` section of this container, I see the following for `"User"` ``` "Config": { "Hostname": "5f7a21d6b616", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, ..... } ```

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@jaysee260 commented on GitHub (Dec 22, 2024):

So, I was able to confirm this ONLY happens if you generate an SSL certificate. Otherwise, you can restart, destroy/recreate the container all day long, and it runs fine.

I can't quite figure out what it is about the container restarting or getting recreated that causes the cert files to become inaccessible...

Line 13 of this script is what changes the permissions of the letsencrypt directory (inside the container) on container start up... Why does it only work the first time? 🤔

<!-- gh-comment-id:2558328647 --> @jaysee260 commented on GitHub (Dec 22, 2024): So, I was able to confirm this **ONLY** happens if you generate an SSL certificate. Otherwise, you can restart, destroy/recreate the container all day long, and it runs fine. I can't quite figure out _what it is about the container restarting or getting recreated that causes the cert files to become inaccessible_... Line 13 of [this script](https://github.com/NginxProxyManager/nginx-proxy-manager/blob/develop/docker/rootfs/etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh#L13) is what changes the permissions of the `letsencrypt` directory (inside the container) on container start up... Why does it only work the first time? :thinking:

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@mr-prez commented on GitHub (Jan 1, 2025):

I was able to "solve the issue" by simply using jlesage/docker-nginx-proxy-manager. Apparently the only real differences are using ports 8080, 8181, and 4443, GUID/UID support that predates the main branch, and nginx runs as non root on non privileged ports.

<!-- gh-comment-id:2566849455 --> @mr-prez commented on GitHub (Jan 1, 2025): I was able to "solve the issue" by simply using [jlesage/docker-nginx-proxy-manager](https://github.com/jlesage/docker-nginx-proxy-manager). Apparently the [only real differences](https://github.com/jlesage/docker-nginx-proxy-manager/issues/256) are using ports 8080, 8181, and 4443, GUID/UID support that predates the main branch, and nginx runs as non root on non privileged ports.

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@dshizntpdt commented on GitHub (Jan 24, 2025):

Line 13 of this script is what changes the permissions of the letsencrypt directory (inside the container) on container start up... Why does it only work the first time? 🤔

So in order to get this to work for me i had to edit the file referenced above and comment out the chmod. once i did that it came up normally and i was able to renew a cert without issue.

<!-- gh-comment-id:2613622994 --> @dshizntpdt commented on GitHub (Jan 24, 2025): > Line 13 of [this script](https://github.com/NginxProxyManager/nginx-proxy-manager/blob/develop/docker/rootfs/etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh#L13) is what changes the permissions of the `letsencrypt` directory (inside the container) on container start up... Why does it only work the first time? 🤔 So in order to get this to work for me i had to edit the file referenced above and comment out the chmod. once i did that it came up normally and i was able to renew a cert without issue.

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@dmorsberger commented on GitHub (Mar 29, 2025):

Was this resolved? I changed the symbolic links "ln -s" to hard links "ln". It starts now and not sure if it will work through a cert renewal.

<!-- gh-comment-id:2764217454 --> @dmorsberger commented on GitHub (Mar 29, 2025): Was this resolved? I changed the symbolic links "ln -s" to hard links "ln". It starts now and not sure if it will work through a cert renewal.

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@mateus-werneck commented on GitHub (Jun 11, 2025):

Had the same problem after running docker system prune and the only way to fix it was

@sonpeter88's suggestion to remove the symlinks and copy the *.pem files from ../../archive, but as pointed out earlier, that solution is unstable, and causes other issues.

<!-- gh-comment-id:2962435896 --> @mateus-werneck commented on GitHub (Jun 11, 2025): Had the same problem after running `docker system prune` and the only way to fix it was > @sonpeter88's suggestion to remove the symlinks and copy the *.pem files from ../../archive, but as pointed out earlier, that solution is unstable, and causes other issues.

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@dmorsberger commented on GitHub (Jun 11, 2025):

I was able to get around the error by modifying and overriding /etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh

Make a local copy by extracting from the Docker container

30-ownership.sh: Use the 'find' command to skip symbolic links when changing ownership

# npm user and group
chown -R "$PUID:$PGID" /data
find /etc/letsencrypt -not -type l -exec chown -R "$PUID:$PGID" {} \;
chown -R "$PUID:$PGID" /run/nginx
chown -R "$PUID:$PGID" /tmp/nginx
chown -R "$PUID:$PGID" /var/cache/nginx
chown -R "$PUID:$PGID" /var/lib/logrotate
chown -R "$PUID:$PGID" /var/lib/nginx
chown -R "$PUID:$PGID" /var/log/nginx

docker-compose.yaml: Overwrite 30-ownership.sh with the bind command

volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
      - ./my-30-ownership.sh:/etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh

<!-- gh-comment-id:2962611662 --> @dmorsberger commented on GitHub (Jun 11, 2025): I was able to get around the error by modifying and overriding /etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh Make a local copy by extracting from the Docker container 30-ownership.sh: Use the 'find' command to skip symbolic links when changing ownership ``` # npm user and group chown -R "$PUID:$PGID" /data find /etc/letsencrypt -not -type l -exec chown -R "$PUID:$PGID" {} \; chown -R "$PUID:$PGID" /run/nginx chown -R "$PUID:$PGID" /tmp/nginx chown -R "$PUID:$PGID" /var/cache/nginx chown -R "$PUID:$PGID" /var/lib/logrotate chown -R "$PUID:$PGID" /var/lib/nginx chown -R "$PUID:$PGID" /var/log/nginx ``` docker-compose.yaml: Overwrite 30-ownership.sh with the bind command ``` volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt - ./my-30-ownership.sh:/etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh ```

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@AlvaroMartinezB commented on GitHub (Jun 13, 2025):

I was able to get around the error by modifying and overriding /etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh

Make a local copy by extracting from the Docker container

30-ownership.sh: Use the 'find' command to skip symbolic links when changing ownership

# npm user and group
chown -R "$PUID:$PGID" /data
find /etc/letsencrypt -not -type l -exec chown -R "$PUID:$PGID" {} \;
chown -R "$PUID:$PGID" /run/nginx
chown -R "$PUID:$PGID" /tmp/nginx
chown -R "$PUID:$PGID" /var/cache/nginx
chown -R "$PUID:$PGID" /var/lib/logrotate
chown -R "$PUID:$PGID" /var/lib/nginx
chown -R "$PUID:$PGID" /var/log/nginx

docker-compose.yaml: Overwrite 30-ownership.sh with the bind command

volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
      - ./my-30-ownership.sh:/etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh

Any chance of this getting merged onto the main branch? I have no idea how to do what you described haha

<!-- gh-comment-id:2971962817 --> @AlvaroMartinezB commented on GitHub (Jun 13, 2025): > I was able to get around the error by modifying and overriding /etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh > > Make a local copy by extracting from the Docker container > > 30-ownership.sh: Use the 'find' command to skip symbolic links when changing ownership > > ``` > # npm user and group > chown -R "$PUID:$PGID" /data > find /etc/letsencrypt -not -type l -exec chown -R "$PUID:$PGID" {} \; > chown -R "$PUID:$PGID" /run/nginx > chown -R "$PUID:$PGID" /tmp/nginx > chown -R "$PUID:$PGID" /var/cache/nginx > chown -R "$PUID:$PGID" /var/lib/logrotate > chown -R "$PUID:$PGID" /var/lib/nginx > chown -R "$PUID:$PGID" /var/log/nginx > ``` > > docker-compose.yaml: Overwrite 30-ownership.sh with the bind command > > ``` > volumes: > - ./data:/data > - ./letsencrypt:/etc/letsencrypt > - ./my-30-ownership.sh:/etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh > ``` Any chance of this getting merged onto the main branch? I have no idea how to do what you described haha

kerem commented 2026-02-26 07:36:36 +03:00

Author

Owner

Copy link

@AlvaroMartinezB commented on GitHub (Aug 1, 2025):

IT HAS BEEN FIXED!!! Just updated to v2.12.6, because I saw in the changelog that they skipped the Certbot thing... I just updated and my container was able to start again and it's working. Thank you to whoever fixed it!!!

<!-- gh-comment-id:3145673013 --> @AlvaroMartinezB commented on GitHub (Aug 1, 2025): IT HAS BEEN FIXED!!! Just updated to v2.12.6, because I saw in the changelog that they skipped the Certbot thing... I just updated and my container was able to start again and it's working. Thank you to whoever fixed it!!!

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#2722

No description provided.