A major sucky day... lost access to nginx proxy manager

Currently reading
A major sucky day... lost access to nginx proxy manager

4,027
1,378
NAS
DS4l8play, DS202j, DS3623xs+, DSM 7.3.3-25847
How do these things happen? I have had npm docker container running on rpi and all seems well. When I went to log in to add a new RP entry, I get "bad gateway".

After updating images, deleting and re-adding the stack, and trying 3 different browsers, all with the same result, I'm flummoxed.

I suppose the next step is to recall all the forwards by memory (I must have screenshotted this) and return them to Synology... then maybe wipe the rpi database and try again. I haven't updated this system for quite some time. So "nothing changed" (yea, we've all heard that qualifier before).

Appreciate any wise words from the more experienced.

😬
 

Attachments

  • npm-compose.yml.txt
    990 bytes · Views: 32
Upvote 0
it’s this account and it’s password

DB_MYSQL_USER: "nm"
DB_MYSQL_PASSWORD: "nm"

Can I just stop container, and change
you will have to have that account and pass inside the DB configured with permissions on that db/tables.

Then you can edit the compose. But you should be able just to make sure that the pass does not expire.

Double check the npm logs, it should register a clear password problem just so you are sure.
 
Upvote 0
Here;s the error (not helpful to me):
cat fallback_error.log 2022/05/13 18:08:18 [error] 282#282: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.15, server: nginxproxymanager, request: "GET /api/ HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "192.168.1.11:81", referrer: "http://192.168.1.11:81/"

Things I tried...

1. Stopped stack; deleted all images, restarted stack with update option checked... bad gateway
2. Stopped stack; renamed local volume /nginx/data to /nginx/dataSAVE; restarted stack... bad gateway
3. Stopped stack; renamed local volume /nginx/mariadb to /nginx/mariadbSAVE, and deleted /nginx/data; restarted stack... now able to start fresh with default npm login. Updated admin login. Logged out/in fine.
4. Stopped/restarted stack. New login worked.

I still haven't found any password expiration leads. Unsure how to recover settings from original for RP and LE wildcard cert renewal.
 
Upvote 0
Here;s the error (not helpful to me):
cat fallback_error.log 2022/05/13 18:08:18 [error] 282#282: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.15, server: nginxproxymanager, request: "GET /api/ HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "192.168.1.11:81", referrer: "http://192.168.1.11:81/"

Things I tried...

1. Stopped stack; deleted all images, restarted stack with update option checked... bad gateway
2. Stopped stack; renamed local volume /nginx/data to /nginx/dataSAVE; restarted stack... bad gateway
3. Stopped stack; renamed local volume /nginx/mariadb to /nginx/mariadbSAVE, and deleted /nginx/data; restarted stack... now able to start fresh with default npm login. Updated admin login. Logged out/in fine.
4. Stopped/restarted stack. New login worked.

I still haven't found any password expiration leads. Unsure how to recover settings from original for RP and LE wildcard cert renewal.
that log is npm log but I mean the npm docker container log.

Still, consider that things started working after you nuked the sql side confirms that it is the sql credentials problem.

You connect your npm back to that sql but before that make sure that the container is running and bash into it.

Log in as root and run the sql command that will eliminate password expiration for your npm <> sql account that you have configured with your stack.

Once you correct that, attach and run the instance of npm back to your initial sql instance.

You can use ALTER USER 'user'@'localhost' PASSWORD EXPIRE NEVER code against the account you are using with npm to modify the password policy.
 
Upvote 0
I'm connected to the db as "root"

When I execute
SHOW CREATE USER 'root'@'localhost';

Response is
+---------------------------------------------------------------------------------------------------+ | CREATE USER for root@localhost | +---------------------------------------------------------------------------------------------------+ | CREATE USER `root`@`localhost` IDENTIFIED BY PASSWORD '*9KFKNRTH24534THTRWEFEFEWFHTRFS78SKDKDLFL' | +---------------------------------------------------------------------------------------------------+

So far, so good. Next the command

SELECT User FROM mysql.user;

to show all users

And I get

+-------------+ | User | +-------------+ | mysuser | | root | | | | | | mariadb.sys | | mysql | | root | +-------------+

To check if password expire exists, I again use "myuser" in place of "root"
SHOW CREATE USER 'myuser'@'localhost';

but this fails
ERROR 1133 (28000): Can't find any matching row in the user table

Then I tried
SELECT User, HOST FROM mysql.user;

and discovered that "%" was HOST for "myuser".

so...
SHOW CREATE USER 'myuser'@'%';

This worked, but showed no password expiration.

Still I tried then...

ALTER USER 'myuser'@'%' PASSWORD EXPIRE NEVER;

and got...

Query OK, 0 rows affected (0.002 sec)

So seemingly there is no password expiration.

What advice do you have for me? Thank you for helping here.
 
Upvote 0
Still, it would be great to see the NPM docker logs (not nginx) logs

I'm unclear on what you are seeking. I'm in Portainer and have logs for both the npm app and the maria app. I've attached the app (npm) log. If this is the incorrect log, please point me to the right place. Thanks!

I reverted to the mapped folders from my failed set-up and tried to log in again. I can't see anything in the logs that points to a fix/solution or specific problem.
 

Attachments

  • _nginx_app_1_logs.txt
    6.2 KB · Views: 10
Upvote 0
I'm in Portainer and have logs for both the npm app and the maria app. I've attached the app (npm) log
Yes, that's the log I was referring to. I also can't see clearly a problem that would point to a password problem tbh, but let me ask you this.

Your NPM with current hosts works fine correct? It is when you try and edit or add a host that you get into trouble?
 
Upvote 0
Your NPM with current hosts works fine correct? It is when you try and edit or add a host that you get into trouble?
Yes. The RP works fine. But I can't get through the login screen to make any changes.

I read a post that suggested creating a new user via CLI and then migrating settings from the old user (broken login) to the new user). But the instructions were vague enough that I can't see how to do that.

It's a simple matter of starting over, except, I had finally gotten npm to manage my LE wildcard cert renewal, and the thought of having to figure that out again exhausts me, so I'd love to restore things to the way they were.

That said, Cloudflare seems to be auto-renewing my cert... with the downside that there is no means to export/archive the LE cert from Cloudflare.

Even starting over concerns me, as I don't understand why this issue came up, so I may be doomed to repeat it 😠
 
Upvote 0
I hear you. One way you could try is set up a new SQL container with a new account and then from your existing one, export the npm DB.

Import the DB into your new SQL setup, make sure that the new DB account has permission to the NPM DB, and then reconnect your current NPM container to the new SQL container using the new DB account. See if that will help out.
 
Upvote 0
One way you could try is set up a new SQL container with a new account and then from your existing one, export the npm DB.
I'm going to give that a go.

I found several Github threads about npm "bad gateway"... none with any real fix. But I did happen upon this compose file which sidesteps the use of mariadb, and it seems (initially) to run fine.

version: "3" services: app: image: 'jc21/nginx-proxy-manager:latest' restart: always ports: - '80:80' - '443:443' - '81:81' environment: DB_SQLITE_FILE: "/data/npm.sqlite" volumes: - ./docker/npm//data:/data - ./docker/npm/letsencrypt:/etc/letsencrypt

With that new container running, I'll log into the original mariadb container, and see if I can figure out how to export its content, and then import that into the sqlite database on the new container.

Thanks for your comments!
 
Upvote 0
I seem to be going in circles here... in an SSH connection I run

sudo docker exec -it nginx_db_1 mysql -u root -p

After entering root pwd for the mariadb, I'm connected.

But when entering...

mysqldump -u root -p npm > data-dump.sql

Nothing happens unless I append a semicolon (;)

mysqldump -u root -p npm > data-dump.sql;

then this error...

ERROR 1064 (42000): 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 'mysqldump -u root -p npm > data-dump.sql,' at line 1

Not sure what is going on here... I tried to troubleshoot with:

mysqldump -u root p –help

... but had to apply ';' and again the error appeared.

Thoughts?
 
Upvote 0
try this:
1652857589321.png
 
Upvote 0
@Telos
- I spent 3 minutes with the new MariaDB container creating & connecting a manage the DB by the proposed Workbench

It's a quite better approach to check your DB from more complex perspective:
- no typos
- no errors
- full management

1652980488496.png


1652980310575.png
 
Upvote 0
Last edited:
try this:
Thanks. When I began export, I got this...

20220519_MySQLWorkbench_wd64xpDcwh.png


After continuing... errors on every export... leaving no files in the dump folder. :(
It's a quite better approach to check your DB from more complex perspective:
Just saw this after posting ... I'll try again.

----------------------
More problems...

q9o68ph.png


FWIW, I also get this when connecting...

Y1WzqoF.png
 
Upvote 0

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Synology fixed it for me, apparently Windows V below 10 need an adjustment to communicate with Synology...
Replies
7
Views
893
This is crazy... and they are saying this was all due to a Plex media RCE exploit Plex media server seen...
Replies
2
Views
1,573
Replies
6
Views
1,471
The IP address for the router connection (LAN 1) was 192.168.xxx.xx while the 10GbE (LAN 3) IP address is...
Replies
10
Views
2,349
Yesterday I've updated some packages, on my DS918+ (running DSM 7.1), assuming that included the nginx...
Replies
0
Views
1,392

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top