NginxProxyManager / nginx-proxy-manager

Docker container for managing Nginx proxy hosts with a simple, powerful interface
https://nginxproxymanager.com
MIT License
22.67k stars 2.64k forks source link

NPM not loading after docker container update. #2791

Open wilotas opened 1 year ago

wilotas commented 1 year ago

Checklist

Describe the bug

Just update today and I see this error message in Logs:

/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.

Nginx Proxy Manager Version

I can not load NPM web interface.

To Reproduce Steps to reproduce the behavior:

  1. Just try to load webpage...

Expected behavior

Load webpage

Screenshots

image

Operating System Ubuntu 22.04 with docker

Additional context

It was working perfectly since last update.

djk1983 commented 1 year ago

This suggestion fixed this issue for me. #2774

wilotas commented 1 year ago

This suggestion fixed this issue for me. #2774

Hi guy,

I am not using mysql, just npm container.

I did a rollback to 2752 and it worked. Stop updating image until hace clear.

Norsagir commented 1 year ago

Exact same problem here with the latest docker package update, I have to do docker restart to have NPM up and running correctly. I'm on Raspberry Pi 4, each time the Rapsberry reboots, I have to restart NPM manually.

CanonCan commented 1 year ago

This suggestion fixed this issue for me. #2774

Hi guy,

I am not using mysql, just npm container.

I did a rollback to 2752 and it worked. Stop updating image until hace clear.

can you please specify the tag in the docker config you used??

I had a cache file corruption on my unraid server...i ran scrub then filesystem repair now had to create a new docker.img file and reinstall all my containers. I cannot load the interface for NPM at all not by internal ip or my Cloudflare

djk1983 commented 1 year ago

Hi @CanonCan I am using the latest tag (build 2.10.2) and everything remains operational

CanonCan commented 1 year ago

I'm on 2.10.2 as well. I can finally get to the web gui with the internal IP, my container was set to use port 81 for the interface but it was trying to use 80 for some reason I changed it to 181 and now I can get to the interface but all my reverse proxy stuffs gives me a cloud flare. 521 error

Sincerely,

Michael

On Apr 11, 2023 at 07:16, Dan Knight @.***> wrote:

Hi @CanonCan I am using the latest tag (build 2.10.2) and everything remains operational

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

github-actions[bot] commented 9 months ago

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

runarorested commented 6 months ago

I had a similar issue after updating to v2.11.1. I do not know if it may be a regression or a new bug, but it is similar enough.

It started working, but after setting up 3 proxies it started hanging up, as in totally hanging up the web server. The most basic proxy did not cause problems: phpmyadmin, a proxy HTTP to HTTP did not cause any problems, but portainer or owncloud (HTTPS to HTTPS , or HTTPS to HTTP) caused it to fail after some time.

Both the GUI and the redirections worked for a few minutes, and then suddently stopped responding, and the only solution was to delete the data volume and recreate the docker to force a full reset. Restarting the dockers did nothing. The health-check stalled too, until the health failures started showing.

Because the proxy stalled, there where no logs about why it failed. And even then, because I needed to delete the log files, it seems it failed to recreate them and start logging data after that.

Going back toward v2.10.4 and resetting the configuration allowed me to keep setting them up completly, until they kept worked without stalling.

  1. It would be nice to add some extra functionality to the startup script to verify the existence and integrity of the log files.

  2. The command line healthcheck is miss-documented, it is located at /bin/check-health, not /usr/bin/check-health.

  3. As a feature request: a. when creating a new redirection/proxy/whatever, a quick check verfying that a A, AAAA or CNAME register exists showing as a checkmark or badge, would prevent errors due to typing mistakes.

    b. Likewise when writing the target of the proxy, a checkmark showing that the configuration written matches with the target would be nice (ex: checking that the "portainer" docker with target HTTPS://local_IP:9433 it is really an HTTPS and not an HTTP listening port.

    Given that you can't read the logs from the GUI, that would prevent some of the most basic mistakes.