First time boot takes incredibly long due to chown -R "$PUID:$PGID" /opt/certbot

[devedse]

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 start the container for the first time it's taking an incredibly long due to it setting ownership:

nginx-proxy-manager  | ❯ Configuring npm user ...
nginx-proxy-manager  | ❯ Configuring npm group ...
nginx-proxy-manager  | ❯ Checking paths ...
nginx-proxy-manager  | ❯ Setting ownership ...

I did a bit of investigation and found out it's due to this command:

chown -R "$PUID:$PGID" /opt/certbot

This code was added in this commit:
05307aa

I ran this command myself inside the container and it took about 5 minutes to complete:

To me it feels a bit strange to have to execute this command on the /opt folder which isn't even mapped to my host system. So why not do this during the creation of the container rather then during boot?

Nginx Proxy Manager Version

2.10.4

To Reproduce
See above

Expected behavior

Boot quickly

Screenshots

N/A

Operating System

Docker inside a container on a Synology NAS

Additional context

[Nightreaver]

I can confirm this. Sometimes it pretty annyoing

[panos-stavrianos]

Any workaround at least? 3-4 minutes downtime just to restart npm is a lot, and very annoying when changing configs and have to restart to see the results.

[devedse]

I guess you could map a volume to the root fs that persists the /opt folder

[panos-stavrianos]

I guess you could map a volume to the root fs that persists the /opt folder

Thanks, it worked!

[DWRedShoes]

I've ran into the exact same issue at startup of the docker container where the chown command (Setting Ownership) took around 25 minutes to complete and this happens every time I turn the container on.

[anantanandgupta]

I guess you could map a volume to the root fs that persists the /opt folder

Thanks, it worked!

How? can you please explain? I am not getting pass to the settings ownership and it simply timesout in my case. I am mounting the data and letsencrypt folder on an nfs share.

[corporategoth]

I too am hitting this issue on my TrueNAS system. How I resolve this for now.

Step 1: Create a PVC mount called /opt/certbot2 (ie. an external mount is managed by TrueNAS - this is not the same as a named mount managed by docker, from docker's perspective it's still a host mount, but it's as good as you get with truenas).
Step 2: Start the container, then log into it via. shell (use heavyscript or truenas to get into the shell)
Step 3: Copy everything in /opt/certbot to /opt/certbot2 (cp -a /opt/certbot/* /opt/certbot2)
Step 4: Stop the container and change the PVC mount from /opt/certbot2 to /opt/certbot
Step 5: Start the container again.

It should now be very quick to chown, because the storage is external, not copy on write.
Of course, this is a terrible solution, because we are now overriding the docker image for what is in /opt/certbot, so as the container updates, our /opt/certbot will not unless you remove the PVC and do the above steps again.

[Lapo-Statix]

I guess you could map a volume to the root fs that persists the /opt folder

Thanks, it worked!

@panos-stavrianos

How did you do that? I'm having the same problem running on my server, when I run it on my machine it doesn't take long. 😢

[Nightreaver]

I would guess, run the container and wait for it to start, use docker copy and copy the /opt from the container to a folder on your harddisk once this is done, stop the container add a volume that maps the copy on your local disk to the /opt inside the container start the container again Am Mo., 19. Feb. 2024 um 18:45 Uhr schrieb Lapo ***@***.***>:

…

I guess you could map a volume to the root fs that persists the /opt folder Thanks, it worked! @panos-stavrianos <https://github.com/panos-stavrianos> How did you do that? I'm having the same problem running on my server, when I run it on my machine it doesn't take long. — Reply to this email directly, view it on GitHub <#3154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAY6MDHQYN3XKWID27OJX3LYUOFSHAVCNFSM6AAAAAA34FODYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJSHE2DIMBUGM> . You are receiving this because you commented.Message ID: ***@***.***>

[Lapo-Statix]

I would guess, run the container and wait for it to start, use docker copy and copy the /opt from the container to a folder on your harddisk once this is done, stop the container add a volume that maps the copy on your local disk to the /opt inside the container start the container again Am Mo., 19. Feb. 2024 um 18:45 Uhr schrieb Lapo @.>:
…
I guess you could map a volume to the root fs that persists the /opt folder Thanks, it worked! @panos-stavrianos https://github.com/panos-stavrianos How did you do that? I'm having the same problem running on my server, when I run it on my machine it doesn't take long. — Reply to this email directly, view it on GitHub <#3154 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY6MDHQYN3XKWID27OJX3LYUOFSHAVCNFSM6AAAAAA34FODYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJSHE2DIMBUGM . You are receiving this because you commented.Message ID: @.>

@Nightreaver

Thank you!! it worked :)

[willtaylor]

I'm having the same problem with 2.11.1 via the TrueNAS catalog chart version 1.0.27

I never seem to get past the chown before TrueNAS decides that the container is unhealthy and attempts to restart it, causing an endless loop

2024-02-25 09:32:46.464991-05:00�[1;34m❯ �[1;36mConfiguring npm user ...�[0m
2024-02-25 09:36:39.192117-05:00�[1;34m❯ �[1;36mConfiguring npm group ...�[0m
2024-02-25 09:36:51.272227-05:00�[1;34m❯ �[1;36mChecking paths ...�[0m
2024-02-25 09:37:09.147531-05:00�[1;34m❯ �[1;36mSetting ownership ...�[0m

2024-02-25 09:58:04.848091-05:00�[1;34m❯ �[1;36mConfiguring npm user ...�[0m

I haven't tried the proposed workaround

EDIT

I was just in the console when the container was restarted and it echoed the following message to the console:
command terminated with exit code 137

[dasunsrule32]

Affected by this issue as well on TrueNAS SCALE 23.10.2. Same issue on the community train and installing the docker image directly as well. Takes about 10 minutes for mine to fully load.

[dasunsrule32]

I too am hitting this issue on my TrueNAS system. How I resolve this for now.

Step 1: Create a PVC mount called /opt/certbot2 (ie. an external mount is managed by TrueNAS - this is not the same as a named mount managed by docker, from docker's perspective it's still a host mount, but it's as good as you get with truenas).
Step 2: Start the container, then log into it via. shell (use heavyscript or truenas to get into the shell)
Step 3: Copy everything in /opt/certbot to /opt/certbot2 (cp -a /opt/certbot/* /opt/certbot2)
Step 4: Stop the container and change the PVC mount from /opt/certbot2 to /opt/certbot
Step 5: Start the container again.

It should now be very quick to chown, because the storage is external, not copy on write.
Of course, this is a terrible solution, because we are now overriding the docker image for what is in /opt/certbot, so as the container updates, our /opt/certbot will not unless you remove the PVC and do the above steps again.

So I copied the files to my HDD pool in my /data mount that mounts to npm and created a folder there called certbot and mounted a host path of /opt/certbot to /data/certbot it has the same effect. Boots in seconds now.