Bad Gateway on login attempt

[adman120]

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.

[markspivey]

I had the same issues on my Raspberry 4 (armv7l) and solved it switching to SQLite using the following configuration:

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:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

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]

Hello everyone,

I got a similar issue i guess on Centos 8 but with a different origin

* Issue : Bad gateway for every logon try on http://localhost:81/login or http://172.2.0.3:81/login

* Possible origin: app_1 logs show cannot connect 'EHOSTUNREACH 172.23.0.2:3306) and mariadb seems running fine on port 3306 on db_1 !

After running the setup tutorial this is where i am :

* Got my two files [config.json](https://pastebin.com/s9Nb6DzV) and [docker-compose.yml](https://pastebin.com/JK95uXGr).

* This is an [ls -la and a pwd](https://pastebin.com/FkgBYhc1).

* [docker-compose up result](https://pastebin.com/dVV6xviw)

* the config.json file remain not alterred (not encrypted) after starting the application.

* This is the l[ogs output ](https://pastebin.com/P8aaUFu5)of the both docker containers app db.

* Docker [version info.](https://pastebin.com/9rMJUNUZ)

I'm available if you need further information. Thanks for your help,

I used this and the only thing I changed was the mariadb docker image from 10.4 to latest. Worked at the first try.

[tnortman-raspi]

Ok so now I only had to wait about 10 minutes, interesting!

Same for me! Waited 5 minutes after the initial deployment of the container and I was then able to login

[mrki0620]

This is the only change that worked for me also. Peter. Thanks to markspivey

[goodvandro]

Hello,

I had the same issues on my Raspberry 4 (armv7l) and solved it switching to SQLite using the following configuration:

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:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

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.

I had the same issues on my Raspberry 4 (armv7l) and solved it switching to SQLite using the following configuration:

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:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

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.

I had the same issues on my Raspberry 4 (armv7l) and solved it switching to SQLite using the following configuration:

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:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Hello. This do not work for me. Has anyone else tried another solution that works?

[goodvandro]

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.conf and added the following configuration.

proxy_buffers                           8 2m;
proxy_buffer_size                    12m;
proxy_busy_buffers_size        12m;

[nep2ner]

Just waiting a bit worked for me

[RobotsAreCrazy]

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.conf and added the following configuration.

proxy_buffers                           8 2m;
proxy_buffer_size                    12m;
proxy_busy_buffers_size        12m;

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]

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]

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.conf and added the following configuration.

proxy_buffers                           8 2m;
proxy_buffer_size                    12m;
proxy_busy_buffers_size        12m;

Hi, can you give me a rough guide how to enter the container and make that change, just trying anything incase it works please?

docker container exec -it <container_name> bash
cd /data/nginx
mkdir custom
nano http.conf

And past the configuration in the http.conf

[prakas17]

@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]

you need reload nginx or restart the container for reload changes

[prakas17]

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]

Sim, reiniciei o container após a alteração. Além disso, abra o navegador privado para recarregar a página de login e tentei, mas ainda o mesmo erro.

Observe que meu pi4 está sendo executado no ssd.

Obrigado

Your problem is different from mine. Let me see your configuration in docker-compose.

[prakas17]

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]

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]

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]

@prakas17 Check these two points.

1. Use the docker image "jc21/mariadb-aria:latest" for DB
2. If there is no other service on port 3306 which is being used by nginx-proxy-manager database

[prakas17]

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]

I am having the same issue after I updated.

[goodvandro]

@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]

@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]

i have same isuse with nginx proxy manager. When i try to login gettting error: Bad Getaway

[ErikUden]

i have same isuse with nginx proxy manager. When i try to login gettting error: Bad Getaway

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]

After update Nginx to 2.10 I have the same problem. Bad Gateway on login

[ChronoWerX82]

i have same isuse with nginx proxy manager. When i try to login gettting error: Bad Getaway

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!

Oh wow, delete, restart, same problem ... overwrite the new files with the backup before delete ... now it works wtf

[ErikUden]

@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]

Hi! I have the same problem on fresh install using this compose file:

version: '3.7'

networks:
  nginx-proxy-manager:
    external: true

services:
  npm:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx-proxy-manager
    restart: unless-stopped
    ports:
      - '80:80'
      - '43013:81'
      - '443:443'
    networks:
      - nginx-proxy-manager
    depends_on:
      - npm-db
    environment:
      DB_MYSQL_HOST: npm-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:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

  npm-db:
    image: 'jc21/mariadb-aria:latest'
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: npm
      MYSQL_DATABASE: npm
      MYSQL_USER: npm
      MYSQL_PASSWORD: npm
    networks:
      - nginx-proxy-manager
    volumes:
      - ./data/mysql:/var/lib/mysql

Any ideas?

mariadb logs:

MySQL init process done. Ready for start up.

exec /usr/bin/mysqld --user=mysql --console --skip-name-resolve --skip-networking=0
2023-03-29 17:25:33 0 [Note] /usr/bin/mysqld (mysqld 10.4.15-MariaDB) starting as process 1 ...
2023-03-29 17:25:33 0 [ERROR] mysqld: File '/var/lib/mysql/aria_log_control' not found (Errcode: 13 "Permission denied")
2023-03-29 17:25:33 0 [ERROR] mysqld: Got error 'Can't open file' when trying to use aria control file '/var/lib/mysql/aria_log_control'
2023-03-29 17:25:33 0 [ERROR] Plugin 'Aria' init function returned error.
2023-03-29 17:25:33 0 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
2023-03-29 17:25:33 0 [Note] Plugin 'InnoDB' is disabled.
2023-03-29 17:25:33 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-03-29 17:25:33 0 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2023-03-29 17:25:33 0 [ERROR] Failed to initialize plugins.
2023-03-29 17:25:33 0 [ERROR] Aborting
[i] pre-init.d - processing /scripts/pre-init.d/01_secret-init.sh
[i] mysqld already present, skipping creation
[i] MySQL directory already present, skipping creation
2023-03-29 17:25:34 0 [Note] /usr/bin/mysqld (mysqld 10.4.15-MariaDB) starting as process 1 ...
2023-03-29 17:25:34 0 [Note] Plugin 'InnoDB' is disabled.
2023-03-29 17:25:34 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-03-29 17:25:34 0 [Note] Server socket created on IP: '::'.
2023-03-29 17:25:34 0 [Warning] 'user' entry '@3726bb8bb89f' ignored in --skip-name-resolve mode.
2023-03-29 17:25:34 0 [Warning] 'proxies_priv' entry '@% root@3726bb8bb89f' ignored in --skip-name-resolve mode.
2023-03-29 17:25:34 0 [Note] Reading of all Master_info entries succeeded
2023-03-29 17:25:34 0 [Note] Added new Master_info '' to hash table
2023-03-29 17:25:34 0 [Note] /usr/bin/mysqld: ready for connections.
Version: '10.4.15-MariaDB'  socket: '/run/mysqld/mysqld.sock'  port: 3306  MariaDB Server
2023-03-29 17:25:39 3 [Warning] Aborted connection 3 to db: 'unconnected' user: 'unauthenticated' host: '172.19.0.3' (This connection closed normally without authentication)
2023-03-29 17:25:40 4 [Warning] Aborted connection 4 to db: 'unconnected' user: 'unauthenticated' host: '172.19.0.3' (This connection closed normally without authentication)
2023-03-29 17:25:41 5 [Warning] Aborted connection 5 to db: 'unconnected' user: 'unauthenticated' host: '172.19.0.3' (This connection closed normally without authentication)
2023-03-29 17:25:42 6 [Warning] Aborted connection 6 to db: 'unconnected' user: 'unauthenticated' host: '172.19.0.3' (This connection closed normally without authentication)
2023-03-29 17:25:43 7 [Warning] Aborted connection 7 to db: 'unconnected' user: 'unauthenticated' host: '172.19.0.3' (This connection closed normally without authentication)

NPM logs:

❯ Starting nginx ...
❯ Starting backend ...
s6-rc: info: service frontend successfully started
s6-rc: info: service nginx successfully started
s6-rc: info: service backend successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[3/29/2023] [5:25:33 PM] [Global   ] › ℹ  info      Using MySQL configuration
[3/29/2023] [5:25:33 PM] [Global   ] › ℹ  info      Creating a new JWT key pair...
[3/29/2023] [5:25:38 PM] [Global   ] › ℹ  info      Wrote JWT key pair to config file: /data/keys.json
[3/29/2023] [5:25:39 PM] [Global   ] › ✖  error     Packets out of order. Got: 1 Expected: 0
[3/29/2023] [5:25:40 PM] [Global   ] › ✖  error     Packets out of order. Got: 1 Expected: 0
[3/29/2023] [5:25:41 PM] [Global   ] › ✖  error     Packets out of order. Got: 1 Expected: 0
[3/29/2023] [5:25:42 PM] [Global   ] › ✖  error     Packets out of order. Got: 1 Expected: 0
[3/29/2023] [5:25:43 PM] [Global   ] › ✖  error     Packets out of order. Got: 1 Expected: 0
[3/29/2023] [5:25:44 PM] [Global   ] › ✖  error     Packets out of order. Got: 1 Expected: 0
[3/29/2023] [5:25:45 PM] [Global   ] › ✖  error     Packets out of order. Got: 1 Expected: 0
[3/29/2023] [5:25:46 PM] [Global   ] › ✖  error     Packets out of order. Got: 1 Expected: 0

[ErikUden]

@bvn13 As I've described, you should switch to Yobasystem's MariaDB! Fixed it for me.

[bvn13]

@ErikUden It does not help me

❯ Starting backend ...
❯ Starting nginx ...
s6-rc: info: service frontend successfully started
s6-rc: info: service backend successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[3/29/2023] [9:15:52 PM] [Global   ] › ℹ  info      Using MySQL configuration
[3/29/2023] [9:15:53 PM] [Global   ] › ✖  error     ER_HOST_NOT_PRIVILEGED: Host '172.19.0.3' is not allowed to connect to this MariaDB server
[3/29/2023] [9:15:54 PM] [Global   ] › ✖  error     ER_HOST_NOT_PRIVILEGED: Host '172.19.0.3' is not allowed to connect to this MariaDB server
[3/29/2023] [9:15:55 PM] [Global   ] › ✖  error     ER_HOST_NOT_PRIVILEGED: Host '172.19.0.3' is not allowed to connect to this MariaDB server

[i] mysqld not found, creating....
[i] MySQL directory already present, skipping creation
2023-03-29 21:15:51 0 [Note] Starting MariaDB 10.6.12-MariaDB source revision 4c79e15cc3716f69c044d4287ad2160da8101cdc as process 1
2023-03-29 21:15:51 0 [Note] InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be created!
2023-03-29 21:15:51 0 [Note] InnoDB: Compressed tables use zlib 1.2.13
2023-03-29 21:15:51 0 [Note] InnoDB: Using transactional memory
2023-03-29 21:15:51 0 [Note] InnoDB: Number of pools: 1
2023-03-29 21:15:51 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2023-03-29 21:15:51 0 [Note] mysqld: O_TMPFILE is not supported on /var/tmp (disabling future attempts)
2023-03-29 21:15:51 0 [Note] InnoDB: Using Linux native AIO
2023-03-29 21:15:51 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
2023-03-29 21:15:51 0 [Note] InnoDB: Completed initialization of buffer pool
2023-03-29 21:15:51 0 [Note] InnoDB: Setting file './ibdata1' size to 12 MB. Physically writing the file full; Please wait ...
2023-03-29 21:15:51 0 [Note] InnoDB: File './ibdata1' size is now 12 MB.
2023-03-29 21:15:51 0 [Note] InnoDB: Setting log file ./ib_logfile101 size to 100663296 bytes
2023-03-29 21:15:51 0 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
2023-03-29 21:15:51 0 [Note] InnoDB: New log file created, LSN=10313
2023-03-29 21:15:51 0 [Note] InnoDB: Doublewrite buffer not found: creating new
2023-03-29 21:15:51 0 [Note] InnoDB: Doublewrite buffer created
2023-03-29 21:15:51 0 [Note] InnoDB: 128 rollback segments are active.
2023-03-29 21:15:51 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2023-03-29 21:15:51 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2023-03-29 21:15:51 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2023-03-29 21:15:51 0 [Note] InnoDB: 10.6.12 started; log sequence number 0; transaction id 3
2023-03-29 21:15:51 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-03-29 21:15:51 0 [Note] Server socket created on IP: '0.0.0.0'.
2023-03-29 21:15:51 0 [Note] Server socket created on IP: '::'.
2023-03-29 21:15:51 0 [Warning] 'user' entry '@3726bb8bb89f' ignored in --skip-name-resolve mode.
2023-03-29 21:15:51 0 [Warning] 'proxies_priv' entry '@% root@3726bb8bb89f' ignored in --skip-name-resolve mode.
2023-03-29 21:15:51 0 [ERROR] Incorrect definition of table mysql.event: expected column 'definer' at position 3 to have type varchar(, found type char(141).
2023-03-29 21:15:51 0 [ERROR] mysqld: Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler.
2023-03-29 21:15:51 0 [Note] /usr/bin/mysqld: ready for connections.
Version: '10.6.12-MariaDB'  socket: '/run/mysqld/mysqld.sock'  port: 3306  MariaDB Server
2023-03-29 21:15:53 3 [Warning] Aborted connection 3 to db: 'unconnected' user: 'unauthenticated' host: '172.19.0.3' (This connection closed normally without authentication)
2023-03-29 21:15:54 4 [Warning] Aborted connection 4 to db: 'unconnected' user: 'unauthenticated' host: '172.19.0.3' (This connection closed normally without authentication)

version: '3.7'

networks:
  nginx-proxy-manager:
    external: true

services:
  npm:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx-proxy-manager
    restart: unless-stopped
    ports:
      - '80:80'
      - '43013:81'
      - '443:443'
    networks:
      - nginx-proxy-manager
    depends_on:
      - npm-db
    environment:
      DB_MYSQL_HOST: npm-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:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

  npm-db:
    image: 'yobasystems/alpine-mariadb:latest'
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: npm
      MYSQL_DATABASE: npm
      MYSQL_USER: npm
      MYSQL_PASSWORD: npm
    networks:
      - nginx-proxy-manager
    volumes:
      - ./data/mysql:/var/lib/mysql

[Bolex80]

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]

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:

• MYSQL_ROOT_PASSWORD
• MYSQL_DATABASE
• MYSQL_USER
• MYSQL_PASSWORD volumes:
• ./data/mysql:/var/lib/mysql networks:
• nginx_network

nginx: container_name: Nginx-Proxy-Manager image: jc21/nginx-proxy-manager:2.9.18 restart: always ports:

• "80:80"
• "81:81"
• "443:443" environment:
• DB_MYSQL_HOST
• DB_MYSQL_PORT
• DB_MYSQL_USER
• DB_MYSQL_PASSWORD
• DB_MYSQL_NAME volumes:
• ./data:/data
• ./letsencrypt:/etc/letsencrypt networks:
• nginx_network

networks: nginx_network: external: true

[Sonnenbrand]

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

*107 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.178.127, server: nginxproxymanager, request: "POST /api/tokens HTTP/1.1", upstream: "http://127.0.0.1:3000/tokens", host: "192.168.178.111:81", referrer: "http://192.168.178.111:81/login"

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]

I was able to fix it following theese instructions HERE

[FroggMaster]

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]

This randomly cropped up for me this week. Weird. @FroggMaster 's chmod recommendation fixed it.

[manuelmartin-developer]

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.

This worked!

Thanks to @FroggMaster

[FroggMaster]

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.

1) 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 sqlite3 b) If you're on Ubuntu/Debian the packages can be installed VIA: apt-get install mysqldump sqlite3

2) Download the mysql2sqlite script. git clone https://github.com/dumblob/mysql2sqlite.git

3) Export 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.sql

4) Convert the .SQL file to a .SQLite file ./mysql2sqlite npm-export.sql | sqlite3 database.sqlite

5) Stop the NPM / DB Containers if they're running. docker-compose stop [container-name]

6) 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.

7) Update the docker-compose.yaml and remove every DBMYSQL* environment entry.

8) 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.

9) Start your NPM container docker-compose up -d

10) Check 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.sqlite

11) Rejoice everything should hopefully be working now.

[alamoudimoh]

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]

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!!!!

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]

Totally agreed with @ErikUden

[alamoudimoh]

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!!!!

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.

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]

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!!!!

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.

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.

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]

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!!!!

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.

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.

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.

Totally agree.

My bad!

[ademalidurmus]

I had the same problem and resolved it with mysql data directory owner update chown -R 100:101 ./data/mysql.

[root@dev-2-183593 data]# pwd
/projects/nginxproxymanager/data
[root@dev-2-183593 data]# chown -R 100:101 mysql/
[root@dev-2-183593 data]# ls -al
total 4
drwxr-xr-x. 8 root root  127 Jun 12 17:34 .
drwxr-xr-x. 4 root root   63 Jun 12 17:33 ..
drwxr-xr-x. 2 root root    6 Jun 12 17:25 access
drwxr-xr-x. 2 root root    6 Jun 12 17:25 custom_ssl
-rw-r--r--. 1 root root 2190 Jun 12 17:26 keys.json
drwxr-xr-x. 2 root root    6 Jun 12 17:25 letsencrypt-acme-challenge
drwxr-xr-x. 2 root root  120 Jun 12 17:39 logs
drwxr-xr-x. 5  100  101  154 Jun 12 17:34 mysql
drwxr-xr-x. 9 root root  130 Jun 12 17:25 nginx

[Antassium]

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]

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

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]

:2.9.18

this worked also for me. Thanks.

[deminart]

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

version: "3.8"
services:
  app:
    container_name: nginx-proxy-manager
    image: jc21/nginx-proxy-manager
    hostname: nginx-proxy-manager
    restart: unless-stopped
    ports:
      # Public HTTP Port:
      - 80:80
      # Public HTTPS Port:
      - 443:443
      # Admin Web Port:
      - 81:81
    environment:
      # Uncomment this if IPv6 is not enabled on your host
      DISABLE_IPV6: 'true'
    volumes:
      # Make sure this config.json file exists as per instructions below:
      - ./config.json:/app/config/production.json
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    depends_on:
      - db
    healthcheck:
      test: ["CMD", "/bin/check-health"]
      interval: 10s
      timeout: 3s
  db:
    container_name: proxy-mariadb
    image: yobasystems/alpine-mariadb:10.5.11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: 'SOMETHING'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'proxyManager'
      MYSQL_PASSWORD: 'SOMETHING'
    volumes:
      - ./data/mysql:/var/lib/mysql

networks:
  default:
      name: proxy

Save the file. Run the following command.

nano config.json

{
  "database": {
    "engine": "mysql",
    "host": "db",
    "name": "npm",
    "user": "proxyManager",
    "password": "SOMETHING", #Only change the password to what you put in the `docker-compose.yml` file.
    "port": 3306
  }
}

Save the file and run:

docker-compose up -d

only after that I was able to log in)

[ademalidurmus]

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

version: '3.8'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt