starred/nginx-proxy-manager-NginxProxyManager
1
0
Fork 0
mirror of https://github.com/NginxProxyManager/nginx-proxy-manager.git synced 2026-04-25 17:35:52 +03:00
Code Issues 937 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #1277] New Install - init-stage2 failed - changing ownership not permitted on logs folder #1031

New issue
Open
opened 2026-02-26 06:35:29 +03:00 by kerem · 18 comments
kerem commented 2026-02-26 06:35:29 +03:00
Owner
Copy link

Originally created by @SaschaHenning on GitHub (Jul 31, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1277

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
After an update of the docker image the init did fail (see below). So I created a new container.

  1. start container
  2. "logs" folder in "data" is created successfully
  3. error as shown here in the log:
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01_perms.sh: executing... 
Changing ownership of /data/logs to 0:0
chown: changing ownership of '/data/logs': Operation not permitted
[cont-init.d] 01_perms.sh: exited 1.
!!!!!
 init-stage2 failed.
!!!!!

Nginx Proxy Manager Version
2.9.5 - pulled jc21/nginx-proxy-manager:latest today

Operating System
Portainer LXC on Proxmox server (x64)
Maybe important detail: Mapped folders for data etc. are on an NFS Share.

Originally created by @SaschaHenning on GitHub (Jul 31, 2021). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1277 **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** After an update of the docker image the init did fail (see below). So I created a new container. 1. start container 2. "logs" folder in "data" is created successfully 3. error as shown here in the log: ``` [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 01_perms.sh: executing... Changing ownership of /data/logs to 0:0 chown: changing ownership of '/data/logs': Operation not permitted [cont-init.d] 01_perms.sh: exited 1. !!!!! init-stage2 failed. !!!!! ``` **Nginx Proxy Manager Version** 2.9.5 - pulled _jc21/nginx-proxy-manager:latest_ today **Operating System** Portainer LXC on Proxmox server (x64) **Maybe important detail:** Mapped folders for data etc. are on an NFS Share.
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@bynicolas commented on GitHub (Nov 24, 2021):

Still same issue in 2.9.12
Also using data folder on a NFS share

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01_perms.sh: executing... 
Changing ownership of /data/logs to 0:0
chown: changing ownership of '/data/logs/proxy_host-15.log': Operation not permitted
chown: changing ownership of '/data/logs/error.log': Operation not permitted
chown: changing ownership of '/data/logs/default.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-1.log': Operation not permitted
chown: changing ownership of '/data/logs/letsencrypt-requests.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-2.log': Operation not permitted
chown: changing ownership of '/data/logs/default_host.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-3.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-4.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-5.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-6.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-7.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-8.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-9.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-10.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-11.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-14.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-12.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-13.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-16.log': Operation not permitted
chown: changing ownership of '/data/logs/proxy_host-17.log': Operation not permitted
chown: changing ownership of '/data/logs': Operation not permitted
[cont-init.d] 01_perms.sh: exited 1.
!!!!!
 init-stage2 failed.
!!!!!
<!-- gh-comment-id:977472288 --> @bynicolas commented on GitHub (Nov 24, 2021): Still same issue in 2.9.12 Also using data folder on a NFS share ``` [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 01_perms.sh: executing... Changing ownership of /data/logs to 0:0 chown: changing ownership of '/data/logs/proxy_host-15.log': Operation not permitted chown: changing ownership of '/data/logs/error.log': Operation not permitted chown: changing ownership of '/data/logs/default.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-1.log': Operation not permitted chown: changing ownership of '/data/logs/letsencrypt-requests.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-2.log': Operation not permitted chown: changing ownership of '/data/logs/default_host.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-3.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-4.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-5.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-6.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-7.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-8.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-9.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-10.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-11.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-14.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-12.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-13.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-16.log': Operation not permitted chown: changing ownership of '/data/logs/proxy_host-17.log': Operation not permitted chown: changing ownership of '/data/logs': Operation not permitted [cont-init.d] 01_perms.sh: exited 1. !!!!! init-stage2 failed. !!!!! ```
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@the1ts commented on GitHub (Dec 8, 2021):

The chown is being done as the root user, does the NFS export have no_root_squash? If not then the NFS server is simply reducing the permissions of the remote root user stopping docker and its containers from doing a chown 0:0.

<!-- gh-comment-id:988842022 --> @the1ts commented on GitHub (Dec 8, 2021): The chown is being done as the root user, does the NFS export have no_root_squash? If not then the NFS server is simply reducing the permissions of the remote root user stopping docker and its containers from doing a chown 0:0.
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@SrFrancia commented on GitHub (Mar 18, 2022):

I'm having the same issue running Rocky Linux 8.5 and using podman 3.4.2 on a proxmox VM
just checked my filesystem and its XFS does it have a similar system to root_squash @the1ts (I just learnt about it)?
This is what happens when running from scratch just after everything is downloaded

Creating nproxym_nproxym_1 ... done
Attaching to nproxym_nproxym_1
nproxym_1  | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
nproxym_1  | [s6-init] ensuring user provided files have correct perms...exited 0.
nproxym_1  | [fix-attrs.d] applying ownership & permissions fixes...
nproxym_1  | [fix-attrs.d] done.
nproxym_1  | [cont-init.d] executing container initialization scripts...
nproxym_1  | [cont-init.d] 01_perms.sh: executing...
nproxym_1  | Changing ownership of /data/logs to 0:0
nproxym_1  | chown: cannot read directory '/data/logs': Permission denied
nproxym_1  | [cont-init.d] 01_perms.sh: exited 1.
nproxym_1  |
nproxym_1  | !!!!!
nproxym_1  |  init-stage2 failed.
nproxym_1  | !!!!!

Nginx Proxy Manager Version
2.9.16 - pulled jc21/nginx-proxy-manager:latest today

<!-- gh-comment-id:1072016629 --> @SrFrancia commented on GitHub (Mar 18, 2022): I'm having the same issue running Rocky Linux 8.5 and using podman 3.4.2 on a proxmox VM just checked my filesystem and its XFS does it have a similar system to root_squash @the1ts (I just learnt about it)? This is what happens when running from scratch just after everything is downloaded ``` Creating nproxym_nproxym_1 ... done Attaching to nproxym_nproxym_1 nproxym_1 | [s6-init] making user provided files available at /var/run/s6/etc...exited 0. nproxym_1 | [s6-init] ensuring user provided files have correct perms...exited 0. nproxym_1 | [fix-attrs.d] applying ownership & permissions fixes... nproxym_1 | [fix-attrs.d] done. nproxym_1 | [cont-init.d] executing container initialization scripts... nproxym_1 | [cont-init.d] 01_perms.sh: executing... nproxym_1 | Changing ownership of /data/logs to 0:0 nproxym_1 | chown: cannot read directory '/data/logs': Permission denied nproxym_1 | [cont-init.d] 01_perms.sh: exited 1. nproxym_1 | nproxym_1 | !!!!! nproxym_1 | init-stage2 failed. nproxym_1 | !!!!! ``` **Nginx Proxy Manager Version** 2.9.16 - pulled _jc21/nginx-proxy-manager:latest_ today
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@WaldHabets commented on GitHub (May 8, 2022):

Try using the :Z suffix for your volumes, so

--volume /path/to/data:/data:Z

instead of

--volume /path/to/data:/data
<!-- gh-comment-id:1120461896 --> @WaldHabets commented on GitHub (May 8, 2022): Try using the `:Z` suffix for your volumes, so ``` --volume /path/to/data:/data:Z ``` instead of ``` --volume /path/to/data:/data ```
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@bynicolas commented on GitHub (May 20, 2022):

Still had issues and adding :Z suffixe did not work for me.

Since only the logs directory seems to have it's ownership changed, I've simply relocated the volume mapping for that log directory locally on the host (and not on the NFS share)

so in other words, I've added --volume /path/to/local/nginx-proxy-manager/data/logs:/data/logs in addition to the previous --volume /path/to/nfs/nginx-proxy-manager/data:/data

This workaround works fine for me, but maybe you'd want to create a cronjob to rsync or move over your log files to the nfs share in your particular situation

<!-- gh-comment-id:1133159509 --> @bynicolas commented on GitHub (May 20, 2022): Still had issues and adding `:Z` suffixe did not work for me. Since only the `logs` directory seems to have it's ownership changed, I've simply relocated the volume mapping for that log directory locally on the host (and not on the NFS share) so in other words, I've added `--volume /path/to/local/nginx-proxy-manager/data/logs:/data/logs` in addition to the previous `--volume /path/to/nfs/nginx-proxy-manager/data:/data` This workaround works fine for me, but maybe you'd want to create a cronjob to rsync or move over your log files to the nfs share in your particular situation
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@bynicolas commented on GitHub (May 20, 2022):

@the1ts

The chown is being done as the root user, does the NFS export have no_root_squash? If not then the NFS server is simply reducing the permissions of the remote root user stopping docker and its containers from doing a chown 0:0.

I have my NFS share set to map all users to the admin user on my NFS server. It seems to me that the container shouldn't have permissions issues, but I don't understand why I'm still getting this error. For the record, I'm using Synology DSM as the NFS host.

If anyone else has a better explanation or a fix, I'd be glad to learn about it, meanwhile, the workaround above will do just fine for me.

<!-- gh-comment-id:1133165842 --> @bynicolas commented on GitHub (May 20, 2022): @the1ts > The chown is being done as the root user, does the NFS export have no_root_squash? If not then the NFS server is simply reducing the permissions of the remote root user stopping docker and its containers from doing a chown 0:0. I have my NFS share set to map all users to the admin user on my NFS server. It seems to me that the container shouldn't have permissions issues, but I don't understand why I'm still getting this error. For the record, I'm using Synology DSM as the NFS host. If anyone else has a better explanation or a fix, I'd be glad to learn about it, meanwhile, the workaround above will do just fine for me.
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@the1ts commented on GitHub (May 20, 2022):

@bynicolas Yeah, I can cause this exact error by using your setup. I have the standard for a NFS only share. i.e. mapping none and security sys. This means that the client sets the permissions not the server. If you squash permissions with mapping a root user on the client doesn't have root on the server so cannot chown 0:0 and scripts in containers die.

<!-- gh-comment-id:1133410835 --> @the1ts commented on GitHub (May 20, 2022): @bynicolas Yeah, I can cause this exact error by using your setup. I have the standard for a NFS only share. i.e. mapping none and security sys. This means that the client sets the permissions not the server. If you squash permissions with mapping a root user on the client doesn't have root on the server so cannot chown 0:0 and scripts in containers die.
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@bynicolas commented on GitHub (May 20, 2022):

@the1ts Thanks for the tip, I managed to get it working (kind of) with the default setup as well mapping none security sys

The only thing now is that I see a bunch of warnings about failed logrotate due to insecure permissions

...
[5/20/2022] [10:09:19 PM] [Setup    ] › ⚠  warning   Error: Command failed: logrotate /etc/logrotate.d/nginx-proxy-manager 
error: skipping "/data/logs/default-host_access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
...

Do you happen to know how to how to fix this? Maybe I'm using incorrect mount options?

<!-- gh-comment-id:1133448359 --> @bynicolas commented on GitHub (May 20, 2022): @the1ts Thanks for the tip, I managed to get it working (kind of) with the default setup as well `mapping none` `security sys` The only thing now is that I see a bunch of warnings about failed logrotate due to insecure permissions ``` ... [5/20/2022] [10:09:19 PM] [Setup ] › ⚠ warning Error: Command failed: logrotate /etc/logrotate.d/nginx-proxy-manager error: skipping "/data/logs/default-host_access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation. ... ``` Do you happen to know how to how to fix this? Maybe I'm using incorrect mount options?
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@the1ts commented on GitHub (May 21, 2022):

All I can suggest is perhaps fix the permissions manually since they've been somewhat broken by the NFS issues in the past. My /data/logs is chown 0:0 and chmod 755 and /data/logs/*log is again chown 0:0 but chmod 644.

This looks correct as it follows the chmod for /data/logs in the NPM scripts and the 644 for the files implied by the logrotate config.

<!-- gh-comment-id:1133638032 --> @the1ts commented on GitHub (May 21, 2022): All I can suggest is perhaps fix the permissions manually since they've been somewhat broken by the NFS issues in the past. My /data/logs is chown 0:0 and chmod 755 and /data/logs/*log is again chown 0:0 but chmod 644. This looks correct as it follows the chmod for /data/logs in the NPM scripts and the 644 for the files implied by the logrotate config.
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@jpharaoh27 commented on GitHub (Jul 15, 2022):

Hey all, I'm having a similar issue here. In the screenshot, I created and chown/chmod the /data/logs directory and I got the chown error. Before I created the logs directory, I was getting a "mkdir - permission denied" error when it was trying to make /data/logs.

Any advice/help will be super appreciated.. been racking my head on this for days lol

image

<!-- gh-comment-id:1185430204 --> @jpharaoh27 commented on GitHub (Jul 15, 2022): Hey all, I'm having a similar issue here. In the screenshot, I created and chown/chmod the /data/logs directory and I got the chown error. Before I created the logs directory, I was getting a "mkdir - permission denied" error when it was trying to make /data/logs. Any advice/help will be super appreciated.. been racking my head on this for days lol ![image](https://user-images.githubusercontent.com/44850838/179209878-e4f2b750-4e38-4687-ac9c-90865ca79a6f.png)
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Mar 7, 2024):

Issue is now considered stale. If you want to keep it open, please comment 👍

<!-- gh-comment-id:1982186762 --> @github-actions[bot] commented on GitHub (Mar 7, 2024): Issue is now considered stale. If you want to keep it open, please comment :+1:
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@ensleep commented on GitHub (May 2, 2024):

I want to know why npm need chown?The root in npm has the right to edit file in nfs . Why It need a right to run chown?

<!-- gh-comment-id:2091100149 --> @ensleep commented on GitHub (May 2, 2024): I want to know why npm need chown?The root in npm has the right to edit file in nfs . Why It need a right to run chown?
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@jc21 commented on GitHub (May 2, 2024):

because the image can run nginx as non-root, if specified with PUID env variable.

<!-- gh-comment-id:2091873468 --> @jc21 commented on GitHub (May 2, 2024): because the image can run nginx as non-root, if specified with PUID env variable.
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@ian351c commented on GitHub (Jun 4, 2024):

[EDIT]
So it looks like there's more chowning going on than just Stage 2. I created a PR that skips chowning for the /data and /etc/letsecrypt folders since those (for me) are mounted remotely (VMware HGFS) and don't allow chowning to happen. It's PR-3792 and implements a SKIP_FILE_OWNERSHIP environment variable that, if set to true, will skip chowning anything in /data or /etc/letsencrypt. This works for me because I I mounted the HGFS volume with the same UID/GID that I am running the NPM container as, so there is no need to attempt to chown those files.
[END EDIT]

For folks that don't know how this works (which was me up until 10 minutes ago): @jc21 is using s6-overlay by Just Containers. This framework appears to automatically try to change ownership of (at least some of) the data/config/log files stored in volumes or binds for the container when PUID or GUID is set. This fails in certain situations (for example: I am running NPM in a Docker container on Debian VM inside VMWare Fusion on a Mac mini M1). To override this behavior, set the following environment variable: S6_BEHAVIOUR_IF_STAGE2_FAILS=0 in the docker command or compose file. Be aware that I have no idea what else this might break, but it seems to be working for me. I still have read/write access to all my files inside the container, I just can't change ownership.

References:
NPM Dockerfile (see line 15)
Customizing s6-overlay behavior

<!-- gh-comment-id:2147623111 --> @ian351c commented on GitHub (Jun 4, 2024): [EDIT] So it looks like there's more chowning going on than just Stage 2. I created a PR that skips chowning for the /data and /etc/letsecrypt folders since those (for me) are mounted remotely (VMware HGFS) and don't allow chowning to happen. It's PR-3792 and implements a SKIP_FILE_OWNERSHIP environment variable that, if set to true, will skip chowning anything in /data or /etc/letsencrypt. This works for me because I I mounted the HGFS volume with the same UID/GID that I am running the NPM container as, so there is no need to attempt to chown those files. [END EDIT] For folks that don't know how this works (which was me up until 10 minutes ago): @jc21 is using [s6-overlay](https://github.com/just-containers/s6-overlay) by Just Containers. This framework appears to automatically try to change ownership of (at least some of) the data/config/log files stored in volumes or binds for the container when PUID or GUID is set. This fails in certain situations (for example: I am running NPM in a Docker container on Debian VM inside VMWare Fusion on a Mac mini M1). To override this behavior, set the following environment variable: S6_BEHAVIOUR_IF_STAGE2_FAILS=0 in the docker command or compose file. **Be aware that I have no idea what else this might break**, but it seems to be working for me. I still have read/write access to all my files inside the container, I just can't change ownership. References: [NPM Dockerfile](https://github.com/NginxProxyManager/nginx-proxy-manager/blob/develop/docker/Dockerfile) (see line 15) [Customizing s6-overlay behavior](https://github.com/just-containers/s6-overlay/blob/master/README.md#customizing-s6-overlay-behaviour)
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@ian351c commented on GitHub (Jun 6, 2024):

@jc21 I'm not sure how to request this to be merged, but if you point me in the right direction, I'll go that way...

<!-- gh-comment-id:2152876821 --> @ian351c commented on GitHub (Jun 6, 2024): @jc21 I'm not sure how to request this to be merged, but if you point me in the right direction, I'll go that way...
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Dec 8, 2024):

Issue is now considered stale. If you want to keep it open, please comment 👍

<!-- gh-comment-id:2525382891 --> @github-actions[bot] commented on GitHub (Dec 8, 2024): Issue is now considered stale. If you want to keep it open, please comment :+1:
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@crazychatting commented on GitHub (Apr 16, 2025):

skipping the ownership would help to include custom configs via docker swarm config mounts

<!-- gh-comment-id:2809287339 --> @crazychatting commented on GitHub (Apr 16, 2025): skipping the ownership would help to include custom configs via docker swarm config mounts
kerem commented 2026-02-26 06:35:30 +03:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Nov 9, 2025):

Issue is now considered stale. If you want to keep it open, please comment 👍

<!-- gh-comment-id:3507331985 --> @github-actions[bot] commented on GitHub (Nov 9, 2025): Issue is now considered stale. If you want to keep it open, please comment :+1:
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
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#1031
No description provided.