Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot change ownership of files under /etc/letsencrypt/live/npm-1 after restarting OR tearing down and recreating container #4239

Open
jaysee260 opened this issue Dec 16, 2024 · 2 comments
Labels

Comments

@jaysee260
Copy link

jaysee260 commented Dec 16, 2024

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 am setting up Nginx Proxy Manager for the very first time. I create my own SSL cert using LetsEncrypt.

The very first time I started the container, everything worked; I was able to login, register proxy hosts, etc.

However, whenever if I tear down and recreate the container, the process inside the container seems to be unable to access the cert files in /etc/letsencrypt/live/npm-1.

I am using docker compose on Debian 12, and here's what I see in the logs whenever I restart or recreate the container.

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

This makes it so that I can't login to the admin page.

Here's my docker-compose config for the service:

networks:
  proxy-net:
    name: proxy-net
    external: true

services:
  nginx-manager:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx-manager
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ${HOME}/docker-data/nginx/data:/data:rw
      - ${HOME}/docker-data/nginx/letsencrypt:/etc/letsencrypt:rw
    networks:
      - proxy-net

If I tear down EVERYTHING and start fresh, meaning... recreating an admin user, recreating an SSL cert, re-adding my proxy hosts, etc, then it works. But, of course, I'd like to avoid having to do this every time!

Is it something around the mounted volume's permissions? I've been scratching my head at this for a few hours, if anyone has any insight into what the problem might be, or how to fix it, I'd greatly appreciate it!

Nginx Proxy Manager Version

2.12.1

Expected behavior

Since I am using a mounted volume to store the nginx manager data and my SSL cert on my host machine, I would expected to be able to tear down the container and spin up a new one as many times, and still be able to login and re-use the cert I created.

Operating System

Debian 12

@jaysee260 jaysee260 added the bug label Dec 16, 2024
@jaysee260 jaysee260 changed the title Cannot change ownership of files under /etc/letsencrypt/live/npm-1 after tearing down and recreating container Cannot change ownership of files under /etc/letsencrypt/live/npm-1 after restarting OR tearing down and recreating container Dec 17, 2024
@jaysee260
Copy link
Author

Can confirm than I don't even have to tear down the container for this to happen... simply stopping it and restarting causes the issue to start happening!

@sonpeter88
Copy link

having the same issue...
there's already an open issue
#4205

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants