2.10.0 unable to start on clean install #2753
Comments
|
I'm assuming different to #2734 because this is the same error on a clean install or existing install (and not resolved with a restart as the original issue poster) |
|
I have the same problem in a host with OpenMediaVault. On another host with Ubuntu Server I have no problem. |
|
Have a similar issue on multiple Hosts: s6-rc: info: service s6rc-oneshot-runner: starting |
|
After updating from 2.9.22 to 2.10.0 on my Synology DS it failed to start: I did a fresh new install with minimal configuration and got the error: Rolling back to 2.9.22 fixed the issue. 2.10.0 works on my laptop (Pop OS). |
|
When I do a portainter recreate including "re-pull image", I'm getting the error: I'm running on Back to 2.9.22 "solves" the problem for now :) |
|
can confirm this issue on synology for me. Rollback on 2.9.22 worked |
|
Hi @jicho , I also rolled back to 2.9.22 but got this log, and the login has a Bad Gateway. did you get that log too?
|
Hi @adammau2 after going back to tag/label 2.9.22 I had no issues had all. Some more info:
|
|
Hi, same issue here. Rolling back to 2.9.22 did the job for now... |
|
Same for me, running on arm7 |
|
Same issue here. Ubuntu 22.04 LTS (docker). Confirmed fix on rollback to 2.9.22 |
|
Same issue on Ubuntu. Confirmed rollback works fine. |
|
Same on a Arm7 |
|
Ditto. 2.10.0 has the error "'npmuser': no such user" and will not start. Switch back to 2.9.22, and everything works. |
|
Same for me on Synology. Switch back to 2.9.22, it works! |
|
Same for me on Synology DSM 6.2.4 |
|
Same problem on Debian (Docker). 2.9.22 works and I can log into the dashboard without any issue. |
|
same on synology, rollback to 2.9.22 fixed for now.. |
|
same on unraid rollback to 2.9.22 fixed it |
|
Hi, the same for me, with debian bullseye on RPI3. also rollback to 2.9.22 fixed the issue. |
|
For the |
compose file on latest Synology DSM |
|
@nitro424 pull and try again please? |
|
Same issue for me on Synology with latest DSM.
Rollback to 2.9.22 resolved for now as well. |
|
Same for debian 10 with docker, rollback to 2.9.22 fixed it. |
|
@jc21 when I change the tag into After a complete container restart I get: In both situations I can't access any of my sites, when I go back to
|
|
@jicho Nothing has changed from the port number side of things, if 2.9.22 could start listening on that port previously then it should be fine for 2.10.0 to do so :/ Does port 81 work for the admin interface? |
|
@jc21 When I change the tag back go So after a restart I'm getting the When I go to port 81 Safari is telling met that it can't connect. It's the same when I do a stop / start in Portainer. Logs are the same: Back to 2.9.22 (just a tag change) makes everything work again... Okay... another test... I'm using the tag 2.10.0, the logs are the same. I'm still getting As soon as I'm back to 2.9.22 everything is back to normal :) |
I'm not who your comment was directed at, but even with image: jc21/nginx-proxy-manager:github-s6-verbose
container_name: nginx_proxy_manager
profiles:
- all
- core
network_mode: synobridge
environment:
- TZ=America/New_York
- PUID=0
- PGID=0
- DEBUG=true
# - S6_CMD_WAIT_FOR_SERVICES_MAXTIME=60000
ports:
- "8341:80"
- "81:81"
- "8766:443"
volumes:
- /volume1/docker/npm/config.json:/app/config/production.json
- /volume1/docker/npm/data:/data
- /volume1/docker/npm/letsencrypt:/etc/letsencrypt
restart: unless-stopped |
|
Here's with DEBUG=true, the timeout happens on /etc/letsencrypt |
|
I noticed that there are 23.398 files in both the /etc/letsencrypt/csr folder and /etc/letsencrypt/keys folder. I'm guessing the chown isn't fast enough and has a set timeout of around 1000ms which isn't enough for the buttload of files there. How can I clean these folders safely? |
Yes, cert-prune fixed the problem for me. It deleted around 500 stale certificates, 23k csr and 23k keys. There must have been a big issue at some point that went unnoticed, and the change to 2.10.0 introduced new timeouts on chown which were not handled fast enough. Now all is good. Thank you! |
|
Cross-posting this from #2750 With v2.10.3, npm is now working perfectly again on my Synology. 🎉 from my env vars and that's it. I tested a fresh install and several server reboots and npm didn't have any issues starting up anymore. |
Hi, looks to me that 2.10.3 is working fine now on Orange Pi 3 LTS. After reboot it starts normally. Unfortunately I see that with :github-s6-verbose logs have grown up huge, 4Gb+ and my whole internal storage is 8Gb. How do I get rid of those huge logs? I am on :latest now. |
|
Hello, In fact, if I run that command from the shell, it never ends. If I do quickly after deploy these commands, npm start well. rm -rf /etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh
touch /etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh
chown -R "1000:1000" /data
chown -R "1000:1000" /etc/letsencrypt
chown -R "1000:1000" /run/nginx
chown -R "1000:1000" /tmp/nginx
chown -R "1000:1000" /var/cache/nginx
chown -R "1000:1000" /var/lib/logrotate
chown -R "1000:1000" /var/lib/nginx
chown -R "1000:1000" /var/log/nginx
chown -R "1000:1000" /etc/nginx/nginx
chown -R "1000:1000" /etc/nginx/nginx.conf
chown -R "1000:1000" /etc/nginx/conf.dEDIT chown -R 1000:1000 /opt/certbot -vlogs 1 file per second, so the deploy go timeout. |
I can confirm that this is exactly the same issue I've been seeing from my side as well. |
|
@anto294 @TristanHarms did you guys try the cert-prune command in the container? For me it was a problem of letsencrypt, thousands of junk files kept for a long time causing a timeout. Fixed the problem instantly. |
I did, it only removed 12 entries in my case and didn't fix the issue. It also didn't change the issue as indicated by @anto294 where chowning files seems to be extremely slow, leading to a timeout on deploy. |
Does certprune commands work now; at one point they were defunct? |
Of course, I have also tested with fresh containers. |
|
Im running unraid, and get this if I use :latest, but if i use :2.10.2 or now .3 it starts up fine. just deleted the containers and images and started fresh. still get permission denied with :latest |
You must be using an old "latest" than. Currently tag "latest", "2.10.3" and "v2" are the same image. |
Ya it’s a fresh install, v2 just removed my container completely since it failed. Latest and 2.10.3 should be exact same thing, but only works if I define the version also to add just jc21/nginx-proxy-manager (default on install) fails to start too. Only works when I specify a version. Weird |
|
I was having the exact same issue @JBake130. Thanks that fixed it. |
|
Is there any update for Rpi ecosystem? |
|
Can confirm, I have the same issue in TrueNAS Scale with the container getting stuck at I ended up mounting |
|
I had trouble installing Nginx Proxy Manager on Proxmox in LXC container. The install script (https://github.com/ej52/proxmox-scripts/blob/main/lxc/nginx-proxy-manager/install/alpine.sh) was telling me:
Solution was create a new user npm:
This fixed it for me. |
|
This is the only log item I am receiving with the github-s6 image and with debug enabled. |
|
I gave up trying to get this to run as # trying to start as user: npm fails, borked s6 overlay stuff; so delete the the user
# and just run as root to get going -- NOTE: running as root IS BAD
RUN sed -i '/user npm;/d' /etc/nginx/nginx.conf
# create the missing certbot in /opt and set include-system-site-packages true
# so --user doesn't cause the certbot command to fail
RUN \
cd /opt \
&& python -m venv certbot \
&& sed -i 's/include-system-site-packages = false/include-system-site-packages = true/' /opt/certbot/pyvenv.cfg |
… Includes workarounds for npm user error (NginxProxyManager/nginx-proxy-manager#2753)
|
This is how to fix it: truenas/charts#1212 (comment)
Or you can just wait for 5-10mins like I did... |
Mine won't even start after one night. Thanks for the ENV, they work :) |
|
Issue is now considered stale. If you want to keep it open, please comment 👍 |
This does indeed skips the steps and allows the app to start (i tried it on the container version too). |
and others
Checklist
jc21/nginx-proxy-manager:latestdocker image?/ No/ No/ NoDescribe the bug
The
:latestand2.10.0image fails to start either with an existing configuration, or with a clean install.Nginx Proxy Manager Version
2.10.0
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The container should start
Screenshots
Operating System
Rpi
Additional context
The text was updated successfully, but these errors were encountered: