mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-26 01:45:54 +03:00
[GH-ISSUE #2707] Bad Gateway on login attempt #1866
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nginx-proxy-manager-NginxProxyManager#1866
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @walter787a on GitHub (Mar 18, 2023).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2707
Checklist
jc21/nginx-proxy-manager:latestdocker image?Describe the bug
bad gateway on login attempt i cant accese the ervice
Nginx Proxy Manager Version2.9.21
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Screenshots
Operating System
Additional context
@blaine07 commented on GitHub (Mar 18, 2023):
Did this too .21 on me earlier but reverted from snapshot and fine now. Is this new build broke?
@walter787a commented on GitHub (Mar 18, 2023):
Only on image with mariadb without it it works properly
El sáb., 18 mar. 2023 20:41, blaine07 @.***> escribió:
@dmalanij commented on GitHub (Mar 19, 2023):
This is kind of same than #2706. @walter787a it would be nice if you completed details as requested in the template to help others to help you better.
I just hit same behaviour. In my case problem appeared after updating my container from working on version
2.9.19to2.9.21.To Reproduce
http://yourcontainerhost:81/login)Sign InbuttonBad Gatewayerror is prompted, nothing else can be done from the UIExpected behaviour
User can login normally to the Nginx Proxy Manager
Workaround
So far I managed to get it back working by downgrading to
2.19.20(it also continues to work on2.9.19)Operating System
My setup is on a Raspberry Pi 4, running on Raspbian 11 - bullseye, recently upgraded.
Details:
Linux 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/LinuxDocker version:
23.0.1, build a5ee5b1Additional Context
I'm setting the passwords through secrets, therefore the
DB_MYSQL_PASSWORD__FILEvariable is the one being used to initialize the security bit.Container logs on
2.9.19Container logs on
2.9.20Container logs on
2.9.21Probable cause
Based on the logs, problem is happening as the database password can't be initialized from the secret file. Paying attention to the early container initialization stage it can be seen that script for setting the variables based on the ones with
_FILEsuffix fails due to permissions:And just before that another failure that is leading to that lack of permissions:
In the container itself I
That points to the
/usr/bin/with-contenvwitch indeed is missing, unlike in previous version (this is for2.9.20):I'll give it a try to review changes in the last version, related to how the image is being built that seems to be the root cause. I'll update if I find anything.
@dmalanij commented on GitHub (Mar 19, 2023):
@jc21 I think the root cause is that the new model for s6 is missing a bit, I want to clarify I've never used s6 on my own so clearly is not an authoritative opinion.
My reasoned guess after checking your commits and latest changes is that the installation is missing the
s6-overlay-symlinks-noarch.tar.xzcontents. I've donwloaded that myself and on inspection I found that the mentionedwith-contenvis there:I checked also that you pushed
82d9452, which looks like a workaround. I can't say it for sure, but seems you can avoid some of that by just getting the symlinks and the rest should be aligned with what is provided by s6.Hope it helps, cheers!
@jc21 commented on GitHub (Mar 19, 2023):
Yes I intentionally didn't use the symlinks package as the documentation suggested it was only really used for backwards compatibility. The new scripts use the proper paths. The scripts that 20/21 were having issues with were not meant to be in the codebase and have been removed/fixed on the develop branch and the secrets script works once again. You're welcome to try the
github-developdocker image tag to test that.I have a feeling though that even with these init scripts working, there might be a file permission issue on your hosts that I'm unable to replicate. The secrets file support was added by a contributor long ago and I don't use them. My database configuration is defined in a file in my
datafolder and I don't specify them as environment variables.@jc21 commented on GitHub (Mar 20, 2023):
I've tested the documented way of specifying env vars instead of a mounted config file and everything still works as I expect. I'll do some more digging with s6.
Is it possible that you're running the docker image as a non-priveleged user?
ie:
or
I'll check what happens with this next, but yeah let me know how you're bringing up your stack if not using the command line directly. Has someone created a portainer template that you're using for example..
@dmalanij commented on GitHub (Mar 20, 2023):
Just tried the
github-developtag and it also worked fine, here are the logs:As per your question, no, I'm not changing the user at all. Here is an excerpt from my compose file:
Last night was thinking around the original scripts and realised that even with the symlinks it wouldn't have worked due to the the strange permissions for the cont-init scripts (with no execution rights for the
01_s6-secret-init.sh), I'm still puzzled about that but couldn't figure out anything from the changes in the2.9.21.Let me know if you'd like me to test a given scenario. And by the way, thanks a lot for this great tool!
@geistchevalier commented on GitHub (Mar 22, 2023):
I'm facing the exact same issue as @dmalanij when I upgraded from .19 to .21, I am using a similar compose setup file with the DB credentials being referenced to a docker secret. The only difference is that my OS is Rocky 8.7 x86_64 instead.
Inspecting the NPM logs when it was on the .21 update gives the same error of
ER_ACCESS_DENIED_ERROR: Access denied for user <REDACTED>@<npm docker network> (using password: YES)Inspecting the logs on the DB side I get
Access denied for user '<REDACTED>@<npm docker network>' (using password: YES)I can also confirm that reverting NPM to version .20 resolves the issue for the time being. My mariadb container is still on the latest tag with no further issues.
@jc21 commented on GitHub (Mar 22, 2023):
@geistchevalier what about
github-developdocker image tag?fwiw 2.9.20 has a bad bug with access lists, so use that with care
@geistchevalier commented on GitHub (Mar 22, 2023):
using
github-developtag seems to be working as it should, nothing abnormal in the logs@jc21 commented on GitHub (Mar 23, 2023):
2.9.22has been released so I'd recommend using that docker tag instead ofgithub-developas I'm about to merge some new stuff to develop.@dmalanij commented on GitHub (Mar 27, 2023):
Back to normal with
2.9.22. Thanks a lot, @jc21@tiftiabc1234 commented on GitHub (Mar 28, 2023):
i realized that you have to use the ip of the container.
For example 172.19.0.2:81
@dmalanij commented on GitHub (Mar 28, 2023):
I'm not sure what are you trying to say with:
In any case how you access and refer to your NPM admin interface is determined by other parts of your particular environment setup; based on what can be seen from your Portainer screenshot I'd say you should be able to access NPM with
http://<your-portainer-host-name>:81. I'd always try to avoid using IP address, specially those assigned to Docker networks... but that's me.