mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-25 09:25:55 +03:00
[GH-ISSUE #310] Bad Gateway on login attempt #274
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#274
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 @adman120 on GitHub (Feb 28, 2020).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/310
On container launch via the recommended compose file, I am unable to get past the login screen as it tells me I have a bad gateway every time I try and log in.
@ghost commented on GitHub (Feb 29, 2020):
Hello guys, any news regarding this topic?
@Xantios commented on GitHub (Feb 29, 2020):
I know this isn't much of a solution, but I had this very same issue and just let the container run for a couple of hours (as I went to bed) and now I can log in.
Maybe there is a bug in the initial startup?
@ghost commented on GitHub (Feb 29, 2020):
I still can't login. I'm afraid that i've configured it wrong, because i am new using docker.
@theniwo commented on GitHub (Mar 4, 2020):
having the same issue here. running on a pi4 with buster.
I read
app_1 | [3/4/2020] [12:48:41 PM] [Global ] › ✖ error create tableauth(idint unsigned not null auto_increment primary key,created_ondatetime not null,modified_ondatetime not null,user_idint unsigned not null,typevarchar(30) not null,secretvarchar(255) not null,metajson not null,is_deletedint unsigned not null default '0') - ER_PARSE_ERROR: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'json not null,is_deletedint unsigned not null default '0')' at line 1 app_1 | [3/4/2020] [12:48:42 PM] [Migrate ] › ℹ info Current database version: none app_1 | [3/4/2020] [12:48:42 PM] [Migrate ] › ℹ info [initial-schema] Migrating Up... app_1 | migration file "20180618015850_initial.js" failed app_1 | migration failed with error: create tableauth(idint unsigned not null auto_increment primary key,created_ondatetime not null,modified_ondatetime not null,user_idint unsigned not null,typevarchar(30) not null,secretvarchar(255) not null,metajson not null,is_deletedint unsigned not null default '0') - ER_PARSE_ERROR: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'json not null,is_deletedint unsigned not null default '0')' at line 1when starting docker-compose without -d
@jc21 commented on GitHub (Mar 5, 2020):
To debug everyone's problems I would need to see the docker-compose file you're using and output of both the NPM container and the DB container, if you're using it and not using a direct connection to a mysql/maria host.
The JSON field error suggests that the mariadb version is old? what version are you running?
@theniwo commented on GitHub (Mar 8, 2020):
Config
Errors
Errors with arm64v8/mariadb
Docker Version
@jc21 commented on GitHub (Mar 9, 2020):
@theniwo so from the first error logs, you're using jsurf/rpi-mariadb maria image which is v10.0. JSON field support was added in maria 10.2.
The second error log has
standard_init_linux.go:211: exec user process caused "exec format error"which is a clear indicator that you're using the wrong architecture image for your system. When using raspbian, no matter if it's rpi3 or 4, you need armv7. I can see that the official mariadb account doesn't make v7 versions. I'll have a stab at making my version multiarch.@jc21 commented on GitHub (Mar 9, 2020):
Try using
jc21/mariadb-aria:10.4here. Should work for Raspbian as well. Let me know how you go!@mark-130 commented on GitHub (Mar 9, 2020):
I'm having the same issues and getting the following error in portainer (container showing as unhealthy). I'm using linux as a base
@jc21 commented on GitHub (Mar 9, 2020):
A very cryptic message. is that from the db container or npm container? If it was a sql error there would be an error message in the npm container. But if it was an error that happens in the db container on start, it might be an issue of incompatible database versions.
@theniwo commented on GitHub (Mar 10, 2020):
Thanks, but I get the
db_1 | standard_init_linux.go:211: exec user process caused "exec format error"error message on this too.
Here's my new config.
@jc21 commented on GitHub (Mar 10, 2020):
@theniwo ok it's time to debug your OS. Can you paste the output of this command:
cat /proc/cpuinfo@theniwo commented on GitHub (Mar 10, 2020):
/proc/cpuinfo
EDIT:
Having the same result on a raspberry pi 3
/proc/cpuinfo
@Delvien commented on GitHub (Mar 11, 2020):
Im having the same issue. same config as the OP. Same raspberry pi CPU
@theniwo commented on GitHub (Mar 11, 2020):
Versions:
@drewbeer commented on GitHub (Mar 11, 2020):
this is because you are all missing the config. the instructions don't include it.
rm -rf config.json (its a dir it shouldn't be)
create a new config.json with
and that will fix it.
@theniwo commented on GitHub (Mar 11, 2020):
I have that config.json as a file in the same directory as the docker-compose.yml. I did not clone from the git, I created the files manually
@zerpex commented on GitHub (Mar 14, 2020):
Hi,
Got the same issue:
docker logs tool-nginx_db standard_init_linux.go:211: exec user process caused "exec format error" standard_init_linux.go:211: exec user process caused "exec format error" standard_init_linux.go:211: exec user process caused "exec format error"cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 10 (v7l) BogoMIPS : 3.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc09 CPU revision : 10I don't know if it can help, but it is working with the following image: https://hub.docker.com/r/yobasystems/alpine-mariadb/tags
Regards
@theniwo commented on GitHub (Mar 15, 2020):
I get an
ER_ACCESS_DENIED_NO_PASSWORD_ERRORerror on this image@jc21 commented on GitHub (Mar 15, 2020):
Funny, because I am using that same image as a base for mine:
https://github.com/jc21/docker-mariadb-aria/blob/master/Dockerfile
@jdkruzr commented on GitHub (Mar 23, 2020):
This issue still exists for anyone who starts from the instructions. I tried @drewbeer 's suggestion, but that didn't fix it either. The issue appears to be that it expects something on the host to be running on port 3000 (node, I guess?) but it isn't.
@miguelwill commented on GitHub (Mar 24, 2020):
check the log of the nginx-proxy-manager container to see if the npm process loads the configuration or shows an error
@adman120 commented on GitHub (Mar 24, 2020):
Tfw you start the thread but contribute 0 to it.
On Mon, Mar 23, 2020 at 9:37 PM Miguelwill notifications@github.com wrote:
@theniwo commented on GitHub (Mar 24, 2020):
I managed to get it running with yobasystems/alpine-mariadb
@drewbeer commented on GitHub (Mar 24, 2020):
ok so i tested this again and yes its doesn't create the config properly.
fresh install, on startup...
app_1 | [3/24/2020] [11:10:02 PM] [Global ] › ✖ error Config file /app/config/production.json cannot be read. Error code is: EISDIR. Error message is: EISDIR: illegal operation on a directory, read Error: Config file /app/config/production.json cannot be read. Error code is: EISDIR. Error message is: EISDIR:
illegal operation on a directory, read
stop the containers and list the files
drwxr-xr-x 2 root root 4096 Mar 25 00:09 config.json
drwxr-xr-x 8 root root 4096 Mar 25 00:10 data
-rw-r--r-- 1 root root 480 Mar 25 00:08 docker-compose.yaml
drwxr-xr-x 2 root root 4096 Mar 25 00:09 letsencrypt
all dirs are created correctly however the config.json is now a dir also... which is wrong...
so rm -rf config.json, edit it and then put in
save
docker-compose down
docker-compose up -d
fixed.
here is my compose pulled straight from the site
@jdkruzr commented on GitHub (Mar 25, 2020):
I’d like to add: if you, like me, thought this would be fine to run in an lxc container with nesting turned on and the appropriate AppArmor flags set:
lxc.apparmor.profile: unconfined
lxc.cgroup.devices.allow: a
lxc.cap.drop:
then I regret to inform you that we were both wrong, because nginx-proxy-manager exhibited the same symptoms in this configuration when I correctly set up the config.json file. I had to run it in a VM instead. Can’t speak to why; I don’t grok Docker networking.
@lopugit commented on GitHub (Mar 25, 2020):
I get this in my logs of the app container
And this from my sql container
@lopugit commented on GitHub (Mar 25, 2020):
Ok so I can confirm as I've read elsewhere, letting it sit for some time (I went to a friends for a few hours) and coming back, it'll be working, magically... I still wonder what the problem is though.
My docker has been a little slow to react because I moved it onto an HDD on AWS. So maybe it's just the slow HDD messing with something.
But yeah, if you leave it for a few hours it'll work.
Actually when I built it on my local machine, SSD, it had the same problem and I'm guessing it would have fixed itself too. I really wonder what causes this delay
@lopugit commented on GitHub (Mar 25, 2020):
Ok so now I only had to wait about 10 minutes, interesting!
@satanahell commented on GitHub (Mar 26, 2020):
Hello everyone,
I got a similar issue i guess on Centos 8 but with a different origin
After running the setup tutorial this is where i am :
I'm available if you need further information.
Thanks for your help,
@wwboynton commented on GitHub (Mar 27, 2020):
I could be mistaken, but it seems like the first run of the container is creating a directory called
config.jsoninstead of a file. It's possible that it's supposed to create a file and then input the default config contents, or perhaps the user is supposed to do it themselves, but either way it seems like completing a successful setup right now means:(pardon any typos in that sample, I hope you get the idea)
EDIT: For what it's worth, on my Raspi4 running Ubuntu 18.04.4LTS, I had issues with the suggested DB image. I switched to the official MariaDB image of the same version, changing my root user name to
rootto avoid duplication. I changed that value in thedocker-compose.ymland again in theconfig.jsonto userootas the user, and randocker-compose downbefore bringing it back up to purge the old containers. I'm all up and running now. The previous MariaDB container was dying immediately with:and I'd prefer to just use the official DB images anyway wherever I can.
@satanahell commented on GitHub (Mar 27, 2020):
@wwboynton thanks for the reply.
I also saw the config.json directory been created on the first run but only because i made a mistake in the docker-compose file. I have repeated many times the same operation without this mistake and all was going like a charm, except this database connection issue. But to be sure, i exactly tried what you've suggested, and i got the same error.
As you mentioned, i will try to switch to the official database container but i'm not quite familiar with docker.
Thanks for the advice !
@lopugit commented on GitHub (Mar 27, 2020):
Wait 10 minutes or 3 hours it should Magically start working
On Fri., 27 Mar. 2020, 9:49 pm SaTaNaeL, notifications@github.com wrote:
@satanahell commented on GitHub (Mar 27, 2020):
@lopugit i already tried this one all night long! ^_^
But with no success at the moment.
@satanahell commented on GitHub (Mar 29, 2020):
Since my last post, i figured out how to log on on each container to make some ping, all is fine obviously but in docker-compose events i got container exec-die about the rproxy_app_1.
I also tried to change db container to official image but i'm not use to docker and i would to check if i'm doing this the good way. @wwboynton can you please post your docker compose file with the official mariadb image ?
I still looking for a solution because my homelab really need a reverse proxy with a GUI to expose and secure many HTTP/HTTPS web servers (same ports/ diff internal IP) !!
@promuta commented on GitHub (Mar 31, 2020):
Thanks, this also fixed the issue for me
@Wonderbox2000 commented on GitHub (Apr 5, 2020):
Hi, I am still having the same issue.
I just tried with yobasystems/alpine-mariadb .=> same result in data/logs/error.log:
2020/04/05 06:51:04 [error] 226#226: *2159 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: "GET /api/ HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "127.0.0.1:81"
Can someone please guide me ?
So far I have also tried the quick-setup and the full-setup
But I have probably missed something.
Running on Ubuntu 18.04
@miguelwill commented on GitHub (Apr 6, 2020):
Are you sure you have created the configuration file and added it to the NPM image mount ?
Compare what you did with the instructions
https://nginxproxymanager.com/setup/
@unixbird commented on GitHub (Apr 10, 2020):
Having the same issues here and tried using a different mysql image. still bad gateway. I'll wait a little bit and see what happens
@unixbird commented on GitHub (Apr 11, 2020):
Alright so it works. What I've found is
That's seemingly how mine works now
@Xantios commented on GitHub (Apr 11, 2020):
So it basically comes down to making a PR to the docs so they explain how to create the json file, point to it in the docker-compose file and have to wait for it to populate?
@jpmurray commented on GitHub (Apr 11, 2020):
EDIT: Nevermind me, @unixbird mentionned it does! I'll just wait!
Full instructions page states that
Can anyone confirm to me that checking the
config.jsonwe created has additionnal entries when they can log in? I'm hitting the same trouble as everyone (having created my config.json file before as I am following full guide), but the file stays exactly the same.@jpmurray commented on GitHub (Apr 11, 2020):
Adding my voice to this, but using the proposed
jc21/mariadb-aria:10.4image, checkingdocker psthe database container status was alwaysRestarting (1) 1 second agoafter ~10 seconds. Switching to thealpine-mariadbdatabase solved it instantly.@jc21 commented on GitHub (Apr 13, 2020):
Why was the
jc21/mariadb-aria:10.4container restarting though? What errors were you able to see? I'm using this exact image in production (amd64) and don't have problems.@jpmurray commented on GitHub (Apr 14, 2020):
None that I could see, although I might be missing places where to look for said errors, I'm still not entirely versed into Docker's inner workings. What would be the usual place to catch thoses? I'll go and try to reproduce the problem.
@delacosta456 commented on GitHub (Oct 6, 2020):
hi all
i was also having this issue and reading some issues (this too didn't help) but bellow is what definitely worked:
So WORKAROUND on my ubuntu, step by step :
(from the npm folder where config and yaml file are ) in terminal i run : sudo docker-compose down
then sudo kill -9
sudo lsof -t -i:81or sudo kill -9 $(sudo lsof -t -i:9001)now sudo docker-compose up -d
IMPORTANT STEP wait for at least 10 to 15 seconds before refreshing you browser on http://127.0.0.1:81
hope this will help (sorry for my English i'am french)
@wimmme commented on GitHub (Dec 3, 2020):
For me on a RPI 3 running Hypriot
does not work, but this does:
@leaderit commented on GitHub (Jan 15, 2021):
docker exec -ti nginx-proxy-manager /bin/bash
where 'nginx-proxy-manager' is the name of your container
node index
SEE ERROR. Usualy : Error: Cannot parse config file: '/app/config/production.json': SyntaxError: Unexpected token } in JSON
or something like this
3.FIX FILE OR ERROR
@sbl05 commented on GitHub (May 2, 2021):
I had the same issues on my Raspberry 4 (armv7l) and solved it switching to SQLite using the following configuration:
@Subline-75 commented on GitHub (May 6, 2021):
What I needed to work this it out (bad gateway on the login page):
https://www.youtube.com/watch?v=ZrS3IT7HG2Y&
Create my first SQL user & database : 👍
@markspivey commented on GitHub (Jun 2, 2021):
Thank you. This is the only thing that worked for me. To anyone else messing around with trying to get mariadb working on a Raspberry Pi, stop what you are doing and choose the quoted route instead.
@wbox commented on GitHub (Jan 21, 2022):
I used this and the only thing I changed was the mariadb docker image from
10.4tolatest. Worked at the first try.@tnortman-raspi commented on GitHub (May 7, 2022):
Same for me! Waited 5 minutes after the initial deployment of the container and I was then able to login
@mrki0620 commented on GitHub (Jun 9, 2022):
This is the only change that worked for me also.
Peter.
Thanks to markspivey
@goodvandro commented on GitHub (Jan 13, 2023):
Hello,
Hello.
This do not work for me.
Has anyone else tried another solution that works?
@goodvandro commented on GitHub (Jan 13, 2023):
I was able to resolve the issue by adding the following parameters in nginx proxy manager settings.
In my case, I was returning a very large body in the http request, which was causing the problem.
I entered the container and created the file:
/data/nginx/custom/http.confand added the following configuration.@nep2ner commented on GitHub (Feb 5, 2023):
Just waiting a bit worked for me
@RobotsAreCrazy commented on GitHub (Feb 13, 2023):
Hi, can you give me a rough guide how to enter the container and make that change, just trying anything incase it works please?
@prakas17 commented on GitHub (Feb 22, 2023):
Lately I am having the same issue. Could someone please point out the correct way to deploy it on pi4 server.
I have tried all the work around as suggested but none of those worked.
Really appreciate it. Thanks
@goodvandro commented on GitHub (Feb 23, 2023):
And past the configuration in the http.conf
@prakas17 commented on GitHub (Feb 24, 2023):
@goodvandro Still facing the same error.
Its driving me crazy and there is no workaround which is working. Tried all these but still the same persistent error.
What else I could try. Anyone please advice.
Thanks.
@miguelwill commented on GitHub (Feb 24, 2023):
you need reload nginx or restart the container for reload changes
@prakas17 commented on GitHub (Feb 24, 2023):
Yes, I restarted the container after the change.
Also, open the private browser to reload the login page and tried but still the same error.
Do note that my pi4 is running on ssd.
Thanks
@goodvandro commented on GitHub (Feb 24, 2023):
Your problem is different from mine. Let me see your configuration in docker-compose.
@prakas17 commented on GitHub (Feb 25, 2023):
below is docker-compose.yml
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
ports:
# These ports are in format :
- '80:80' # Public HTTP Port
- '443:443' # Public HTTPS Port
- '81:81' # Admin Web Port
# Add any other Stream port you want to expose
# - '21:21' # FTP
environment:
DB_MYSQL_HOST: "db"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "npm"
DB_MYSQL_NAME: "npm"
# Uncomment this if IPv6 is not enabled on your host
DISABLE_IPV6: 'true'
volumes:
- ./config.json:/app/config/production.json
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
depends_on:
- db
db:
image: 'yobasystems/alpine-mariadb:latest'
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: 'npm'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'npm'
volumes:
- ./data/mysql:/var/lib/mysql
@prakas17 commented on GitHub (Feb 25, 2023):
docker logs:-
[2/25/2023] [5:50:52 AM] [Global ] › ℹ info Manual db configuration already exists, skipping config creation from environment variables
[2/25/2023] [5:50:52 AM] [Global ] › ✖ error connect ECONNREFUSED 172.21.0.2:3306
[2/25/2023] [5:50:53 AM] [Global ] › ℹ info Manual db configuration already exists, skipping config creation from environment variables
[2/25/2023] [5:50:53 AM] [Global ] › ✖ error connect ECONNREFUSED 172.21.0.2:3306
[2/25/2023] [5:50:54 AM] [Global ] › ℹ info Manual db configuration already exists, skipping config creation from environment variables
[2/25/2023] [5:50:54 AM] [Global ] › ✖ error connect ECONNREFUSED 172.21.0.2:3306
[2/25/2023] [5:50:55 AM] [Global ] › ℹ info Manual db configuration already exists, skipping config creation from environment variables
[2/25/2023] [5:50:55 AM] [Global ] › ✖ error connect ECONNREFUSED 172.21.0.2:3306
[2/25/2023] [5:50:56 AM] [Global ] › ℹ info Manual db configuration already exists, skipping config creation from environment variables
[2/25/2023] [5:50:56 AM] [Global ] › ✖ error connect ECONNREFUSED 172.21.0.2:3306
[2/25/2023] [5:50:57 AM] [Global ] › ℹ info Manual db configuration already exists, skipping config creation from environment variables
[2/25/2023] [5:50:57 AM] [Global ] › ✖ error connect ECONNREFUSED 172.21.0.2:3306
[2/25/2023] [5:50:58 AM] [Global ] › ℹ info Manual db configuration already exists, skipping config creation from environment variables
[2/25/2023] [5:50:58 AM] [Global ] › ✖ error connect ECONNREFUSED 172.21.0.2:3306
[2/25/2023] [5:50:59 AM] [Global ] › ℹ info Manual db configuration already exists, skipping config creation from environment variables
[2/25/2023] [5:50:59 AM] [Global ] › ✖ error connect ECONNREFUSED 172.21.0.2:3306
@prakas17 commented on GitHub (Feb 25, 2023):
Getting below error in container:-
cat /data/logs/fallback_error.log
2023/02/25 05:48:09 [error] 281#281: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.235, server: nginxproxymanager, request: "POST /api/tokens HTTP/1.1", upstream: "http://127.0.0.1:3000/tokens", host: "192.168.1.121:81", referrer: "http://192.168.1.121:81/login"
@goodvandro commented on GitHub (Feb 27, 2023):
@prakas17 Check these two points.
"jc21/mariadb-aria:latest"for DB@prakas17 commented on GitHub (Feb 28, 2023):
Thank you @goodvandro
However, I don't see any errors or warning in docker logs for nginx-proxy-manager container and maria-db container after step (1) as you suggested.
Now looking at the /data/logs/fallback_error.log inside nginx-proxy-manager, I could see below error:-
2023/02/28 09:31:04 [error] 284#284: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.235, server: nginxproxymanager, request: "POST /api/tokens HTTP/1.1", upstream: "http://127.0.0.1:3000/tokens", host: "192.168.1.121:81", referrer: "http://192.168.1.121:81/login"
2023/02/28 09:31:04 [error] 284#284: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.235, server: nginxproxymanager, request: "POST /api/tokens HTTP/1.1", upstream: "http://127.0.0.1:3000/tokens", host: "192.168.1.121:81", referrer: "http://192.168.1.121:81/login"
2023/02/28 09:31:05 [error] 284#284: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.235, server: nginxproxymanager, request: "POST /api/tokens HTTP/1.1", upstream: "http://127.0.0.1:3000/tokens", host: "192.168.1.121:81", referrer: "http://192.168.1.121:81/login"
Could you please let me know how to troubleshoot further.
@ErikUden commented on GitHub (Feb 28, 2023):
I am having the same issue after I updated.
@goodvandro commented on GitHub (Mar 1, 2023):
@prakas17 comment or remove the following code
DISABLE_IPV6: 'true'Make sure there is no other service using the ports configured in your docker-compose.
If the problem persists, re-share your docker compose git repository or post it here in the comments again.
@prakas17 commented on GitHub (Mar 1, 2023):
@goodvandro
Below is my docker-compse.yml:-
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
ports:
# These ports are in format :
- '80:80' # Public HTTP Port
- '443:443' # Public HTTPS Port
- '81:81' # Admin Web Port
environment:
DB_MYSQL_HOST: "db"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "npm"
DB_MYSQL_NAME: "npm"
# Uncomment this if IPv6 is not enabled on your host
# DISABLE_IPV6: 'true'
volumes:
- ./config.json:/app/config/production.json
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
depends_on:
- db
db:
#image: 'yobasystems/alpine-mariadb:latest'
image: 'jc21/mariadb-aria:latest'
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: 'npm'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'npm'
volumes:
- ./data/mysql:/var/lib/mysql
I deleted all the container and images, then re-deploy using docker-compose command.
Also, I checked my host to make sure no other service is running on 3306 and other ports.
Sadly, issue still persist with same errors in UI and /data/logs/fallback_error.log inside nginx-proxy-manager container.
Appreciate your assistance on this. Thanks.
@LunarLoom24 commented on GitHub (Mar 27, 2023):
i have same isuse with nginx proxy manager. When i try to login gettting error: Bad Getaway
@ErikUden commented on GitHub (Mar 27, 2023):
Here's the solution I had from back then:
I have found my error:
I reset my database to yobasystems' maria-db, however, that did not solve it. The issue lied within four files I had:
so nginx/data/mysql/npm
In here there there is
migrations.frm
migrations.ibd
migrations_lock.frm
migrations_lock.ibd
I replaced all of these files with a backup I made of them a while ago.
Now everything works again.
I cannot explain why, but these files got corrupted after listening on the same port as my Pi-hole. For everyone reading my solution, I hope you've made a backup, if not, try deleting these files, maybe (only after having made a backup)?
Good luck!
I hope this helps!
@ChronoWerX82 commented on GitHub (Mar 29, 2023):
After update Nginx to 2.10 I have the same problem. Bad Gateway on login
@ChronoWerX82 commented on GitHub (Mar 29, 2023):
Oh wow, delete, restart, same problem ... overwrite the new files with the backup before delete ... now it works wtf
@ErikUden commented on GitHub (Mar 29, 2023):
@ChronoWerX82 Yes, I have no idea why, but this solves it. I'm so glad this helped! This problem ruined my day a couple of years ago too! Haha.
@bvn13 commented on GitHub (Mar 29, 2023):
Hi!
I have the same problem on fresh install using this compose file:
Any ideas?
mariadb logs:
NPM logs:
@ErikUden commented on GitHub (Mar 29, 2023):
@bvn13 As I've described, you should switch to Yobasystem's MariaDB! Fixed it for me.
@bvn13 commented on GitHub (Mar 29, 2023):
@ErikUden It does not help me
@Bolex80 commented on GitHub (Apr 1, 2023):
Anyone managed to fix the issue.
I tried changing from yobasystems/alpine-mariadb:latest to jc21/mariadb-aria:latest
And vice versa.
I still get bad geteway when logging in.
My services are working correctly, but I cannot add anything new.
I hope someone has some other option I could try.
Unfortunately, my last snapshot has already this fault and I have nowhere to revert to that works correctly.
Please help!
@DonBamboo commented on GitHub (Apr 2, 2023):
Whew! after so many hours of figuring out what the problem is my solution is use the npm version 2.9.18 if you use latest then it will return error I'm not sure why?
version: "3.8"
services:
mariadb:
container_name: MariaDB
image: "jc21/mariadb-aria:latest"
restart: always
healthcheck:
test: mysqladmin ping -h mariadb --password=${MYSQL_ROOT_PASSWORD}
interval: 1s
retries: 15
environment:
volumes:
networks:
nginx:
container_name: Nginx-Proxy-Manager
image: jc21/nginx-proxy-manager:2.9.18
restart: always
ports:
environment:
volumes:
networks:
networks:
nginx_network:
external: true
@Sonnenbrand commented on GitHub (Apr 2, 2023):
SOLUTION:
Hi all, if just want to share my solution for the Bad Gateway Login issue after updating to V2.10:
I had one /data directory for both nginx and mysql in my docker-compose.yml. I created a second data_db folder, copied the /data/mysql folder and changed the yml file. Restart the containers and it worked.
Same here, after update to 2.10.2 (from 2.19.X) bad login error with this in the fallback_error.log
I assume the issue seems to be that it wants to connect to the 127.0.0.1:3000 which is refused. I tried it on the host machine as well as inside the container and that does not work. So that seems to be the issue here, right?
@Bolex80 commented on GitHub (Apr 2, 2023):
I was able to fix it following theese instructions HERE
@FroggMaster commented on GitHub (Apr 6, 2023):
The quickest/easiest workaround for this that doesn't require direct config changes is to change the permissions on the mysql folder:
chmod 777 -R <mysql folder>Permissions can be adjusted back to 755 once the issue has been resolved.
@TokugawaHeavyIndustries commented on GitHub (Apr 12, 2023):
This randomly cropped up for me this week. Weird. @FroggMaster 's chmod recommendation fixed it.
@manuelmartin-developer commented on GitHub (Apr 27, 2023):
This worked!
Thanks to @FroggMaster
@FroggMaster commented on GitHub (Apr 30, 2023):
I ended up having further issues with my MariaDB; So I ended up converting it to a SQLite DB. This resolved not being able to logon, as well as an "npm user not found" startup error I was facing due to the MariaDB. So far I've found that the docker configuration is easier and it's an overall easier DB format to manage.
I'll share an easy step by step that can be followed to do the same.
First we're going to prepare the Pre-Requisites to be able to follow these steps. You require the following packages installed:
mysqldump, sqlite3 and the script mysql2sqlite
a) If you're on FreeBSD the packages can be installed VIA:
pkg install mysqldump sqlite3b) If you're on Ubuntu/Debian the packages can be installed VIA:
apt-get install mysqldump sqlite3Download the mysql2sqlite script.
git clone https://github.com/dumblob/mysql2sqlite.gitExport your MariaDB MYSQL Database from your NPM DB Container
docker exec -it [db-container-name] mysqldump --user=[mysql-user] --password=[mysql-password] [mysql-db-name] -h 127.0.0.1 > npm-export.sqlConvert the .SQL file to a .SQLite file
./mysql2sqlite npm-export.sql | sqlite3 database.sqliteStop the NPM / DB Containers if they're running.
docker-compose stop [container-name]Copy the database.sqlite file into your container's persistent storage location. For me and most that followed the default configurations this will be the data directory.
Update the docker-compose.yaml and remove every DB_MYSQL_* environment entry.
OPTIONAL STEP: Update the docker-compose.yaml and add the following environment entry
DB_SQLITE_FILE: "/data/database.sqlite"Note: This step is OPTIONAL as /data/database.sqlite is the default location NPM will read the database file from. You only really need this line in the YAML if you want to relocate the database.sqlite file. If so, you can adjust the above path to something else.
Start your NPM container
docker-compose up -dCheck the docker Logs for the following line to validate the SQLlite file is being used. Using Sqlite: /data/database.sqlite This can be done easily with the following command:
docker compose logs|grep -i database.sqliteRejoice everything should hopefully be working now.
@alamoudimoh commented on GitHub (May 12, 2023):
three years later and still users have to go through this again and read many articles!!! with due respect what are the developers really doing? is this develop as an open source project to ease the life of people and to make them suffer!!!!
@ErikUden commented on GitHub (May 12, 2023):
Please. The developers here work for free. It is an issue, yes. Software is complex, it functions differently on every device: ERRORS HAPPEN! I understand your frustration, do not let it out on the people who, without anyone asking them to, provide their time and effort for FREE. Sure, without these developers you would not have this error, because without these developers you wouldn't even be able to complain about it in the first place because the software would not exist.
Let out your frustration on someone / something else, not these wonderful human beings who brought us the NGINX Proxy Manager.
@delacosta456 commented on GitHub (May 12, 2023):
Totally agreed with @ErikUden
@alamoudimoh commented on GitHub (May 12, 2023):
no one is disagreeing on that fact, i do appreciate every single second you guys spent, however, we cannot focus of new feature development only and forget the repeated issues! i spent 4 hours just searching the old issues for the solution, and it could be seconds if that was listed as a known issues that might occur at the installation guide, since it is reported more frequently.
BTW...i am an IT person specialized in IT GRC, and i understand developers sometimes focus on something and forgets to mention this known error somewhere, where people would spend time trying to solve it.
@ErikUden commented on GitHub (May 12, 2023):
Then let me put what you wanted to say in more constructive words:
Hey, I've encountered this issue many times and each time I do I spend hours searching for the solution. Could the following be listed on the "common errors" section of the NGINX Proxy Manager? I think this would save a lot of time for everyone who might also encounter this error in the future! Thanks.
Just write it like that! If you simply attack developers and question whether they deliberately make software in order to cause suffering, no one will take you seriously.
@alamoudimoh commented on GitHub (May 12, 2023):
Totally agree.
My bad!
@ademalidurmus commented on GitHub (Jun 12, 2023):
I had the same problem and resolved it with mysql data directory owner update
chown -R 100:101 ./data/mysql.@Antassium commented on GitHub (Aug 3, 2023):
FYI!!!
For anyone who was never helped by any of these solutions:
I removed the database section entirely as it's utterly unnecessary and poory functioning.
Here's the docker-compose.yaml file I used and it worked as it always does to simply get the proxy manager to allow me to login with default credentials:
version: "2.1"
services:
app:
image: jc21/nginx-proxy-manager:latest
container_name: nginx-proxy
volumes:
- ./data/app:/data
- ./letsencrypt:/etc/letsencrypt
ports:
- 80:80
- 443:443
- 81:81
restart: unless-stopped
@wimmme commented on GitHub (Aug 3, 2023):
Just a question. The workarround (mysql data directory owner update chown -R 100:101 ./data/mysql. )did work for me, the problem is I have to do it everytime NPM updates.
If we can eliminate the database completely that would solve the problem too off course :-)
Did you change form DB to Non-DB config without losing data/config ?
EDIT: probably have to use this procedure:https://github.com/NginxProxyManager/nginx-proxy-manager/discussions/1529#migrate-mariadb-to-sqlite-dbeaver
@MaPaLo76 commented on GitHub (Sep 3, 2023):
this worked also for me. Thanks.
@deminart commented on GitHub (Sep 14, 2023):
I suffered for a couple of days...
I tried everything that was written here, nothing helped....
Changing the rights chmod 777 -R helped at the moment, but after restarting, everything broke again...
In general, what helped personally on my configuration.
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
Maybe it will help someone)
The process is not complicated
Deleted all associated containers, volumes, networks and directories...
Then I recreated everything anew with this configuration.
cd /home/containers/npm/
nano docker-compose.yml
Save the file.
Run the following command.
nano config.json
Save the file and run:
docker-compose up -d
only after that I was able to log in)
@ademalidurmus commented on GitHub (Sep 15, 2023):
I'm using this version; I've removed the database part, and it's still working fine. When you can't define any database service, it will use the SQLite database. If you're trying to do a fresh install, you can choose this option. If you already have an installation, you can migrate by following @wimmme's suggestion here: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/310#issuecomment-1664125882
@silkyclouds commented on GitHub (Jan 20, 2024):
Same problem here. I already got it but can't remember how I fixed it...
nginx updated last night, here is what I can see in the logs :
On the other hand, npm starts and redirects the traffic as it should. I can reach all my web services.
I've recovered backups, same thing. - bad gateway at login screen.
I'm NOT using any separate database to run npm butthe integrated sqlite DB :
I will try to go back to previous version to see if it helps... but this problem happening from time to time makes me lesser confident in npm and I think I'm just gonna move to Traefik.
@goppinath commented on GitHub (Jan 21, 2024):
I am also using SQLite and getting the same error as @silkyclouds saying
Bad Gateway. I have reverted to the imagejc21/nginx-proxy-manager:2.10.4and I can log in again.@silkyclouds commented on GitHub (Jan 21, 2024):
Well I guess a downgrade is the only thing to go for, for now... Thanks for letting us know a downgrade worked for you !
@silkyclouds commented on GitHub (Jan 21, 2024):
so I did downgrade to 2.10.4 as you recommended @goppinath but unfortunately I'm still geting bad gateway at login.
and I also have some env variable issue now as I can see the backend is not starting at all and logs loops on this :
@skatespeare commented on GitHub (Jan 21, 2024):
Removing the node_options from the env variables did the trick for me. Not sure if it broke anything else, but Let's Encrypt still works.
@goppinath commented on GitHub (Jan 21, 2024):
@silkyclouds I have two NPM instances one on Debian 12 as a VPS and the other on the Raspberry Pi OS based on Debian 12. The VPS one gave the issue and the RPi one is running without any issue. Maybe try downgrading one more version as a workaround. I am seriously thinking of switching to a more stable reverse proxy manager and/or making the weekly incremental backup too.
@goppinath commented on GitHub (Jan 21, 2024):
Thank you @jc21 I have updated to version 2.11.1 which was released just an hour ago and this has resolved my issue. @silkyclouds @skatespeare Give it a try. Let's appreciate the developers and support the project.
@silkyclouds commented on GitHub (Jan 21, 2024):
well, I also have two broken instances (one running in a datacenter, under Debian vs. The one I just fixed using @skatespeare workaround (downgrading + removing the env. variable that refers to the legacy provider.
Now I just need to get the debian one running, but the same trick doesn't seem to help at all, it ain't starting anymore. :)
By the way, you could use the docker backup script I wrote if you plan to backup your docker containers ;)
@silkyclouds commented on GitHub (Jan 21, 2024):
Nope, as soon I pull the latest again, I now have a lot of other cert renewal issues. I guess it's because I removed the legacy thing...
@andreaswilli commented on GitHub (Jan 21, 2024):
Just encountered this issue with version
2.11.0. Upgrading to2.11.1fixed the issue for me.@DominikRoB commented on GitHub (Sep 3, 2024):
Encountered this error message as well after months of running without changes to any config or file. But a quick compose down. compose up fixed it.
@MarkRotNF commented on GitHub (Sep 8, 2024):
I also had an gateway error.
docker psshowed that " nginxproxymanager-db-1" (jc21/mariadb-aria:latest) ist "restarting" (in loop).docker-compose up(without -d) returned:I was able to fix it with the following:
cd to the mysql folder (should be the path thats in the docker-compose.yaml "db:" -> "volumes:". E.g. "./mysql" as in my case.
docker-compose downsudo mv aria_log. XXXXXXXXX bak.aria_log.XXXXXXXXXdocker-compose up -d(similar to described here: https://serverfault.com/questions/893626/mysql-wont-start-mysqld-got-signal-11)
(I'm not sure if this was due to insufficient free storage space. Mine was almost full.)
@jqknono commented on GitHub (Sep 26, 2024):
The Fetching https://ip-ranges.amazonaws.com/ip-ranges.json blocked at startup. Some times this will cost many time.
If you're blocked by this fetching too, just run:
This should skip the fetching of the startup.
@RichardSchulz52 commented on GitHub (Dec 21, 2024):
Just a hint for anyone also stuck here at some point. In my case the problem was using a cifs volume where the sqlite DB is placed. For some reason sqlite and cifs volumes do not work together. I fixed this setting up npm to use Maria-DB.