DB no longer starts up

[Shardboii]

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes / No
• Are you sure you're not using someone else's docker image?
  • Yes / No
• Have you searched for similar issues (both open and closed)?
  • Yes / No

Describe the bug

I don't really know what im supposed to do or change here

Error: in 18+, these Docker images are configured to store database data in a

       format which is compatible with "pg_ctlcluster" (specifically, using

       major-version-specific directory names).  This better reflects how

       PostgreSQL itself works, and how upgrades are to be performed.

       See also https://github.com/docker-library/postgres/pull/1259

       Counter to that, there appears to be PostgreSQL data in:

         /var/lib/postgresql/data (unused mount/volume)

       This is usually the result of upgrading the Docker image without

       upgrading the underlying database using "pg_upgrade" (which requires both

       versions).

       The suggested container configuration for 18+ is to place a single mount

       at /var/lib/postgresql which will then place PostgreSQL data in a

       subdirectory, allowing usage of "pg_upgrade --link" without mount point

       boundary issues.

       See https://github.com/docker-library/postgres/issues/37 for a (long)

       discussion around this process, and suggestions for how to do so.

This error popped up and NPM_DB no longer works. It's not affecting my current proxies but only the WebUI. Which means i won't be able to make any changes via the GUI

Nginx Proxy Manager Version

v2.12.6

To Reproduce
Steps to reproduce the behavior:

1. Update Nginx Proxy Manager a few times over the span of a year
2. oop
3. See problem - Stopped for 4 minutes with exit code 1

Expected behavior

It continues working

Screenshots

Operating System

Fedora Server

Additional context

Compose file:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      # These ports are in format <host-port>:<container-port>
      - '81:80' # Public HTTP Port
      - '1002:443' # Public HTTPS Port
      - '30020:81' # Admin Web Port
      # Add any other Stream port you want to expose
      # - '21:21' # FTP
    environment:
      # Postgres parameters:
      DB_POSTGRES_HOST: 'db'
      DB_POSTGRES_PORT: '5432'
      DB_POSTGRES_USER: '****'
      DB_POSTGRES_PASSWORD: '****'
      DB_POSTGRES_NAME: 'npm'
      # Uncomment this if IPv6 is not enabled on your host
      # DISABLE_IPV6: 'true'
    volumes:
      - /mnt/Server_NAS/dockerapps/nginx-proxy-manager/data:/data
      - /mnt/Server_NAS/dockerapps/nginx-proxy-manager/certs:/etc/letsencrypt
    depends_on:
      - db

  db:
    image: postgres:latest
    environment:
      POSTGRES_USER: '***'
      POSTGRES_PASSWORD: '***'
      POSTGRES_DB: 'npm'
    volumes:
      - postgres:/var/lib/postgresql/data

volumes:
  postgres:

Im using Watchtower to automatically update this

[lastsamurai26]

This is not a bug in Nginx but an error on the part of the user.

It is not recommended to use the latest version of Postgres because they simply perform a version jump, which can cause the database to become partially corrupted. Therefore, it is better to use version 17
postgres:17-alpine and make a backup before upgrading to version 18.

Every version of Postgres requires a manual upgrade.

When I upgrade from 17 to 18, I install a completely new database and import all the data. Then I change the name in the containers or restart the 18 version with the old name.
Maybe this helps aswell
https://github.com/NginxProxyManager/nginx-proxy-manager/pull/4805/files

https://hub.docker.com/_/postgres#pgdata

Here, too, repeated warnings are issued against using WatchDogs to automatically update the containers!!!!

[MarleTangible]

This is something I experienced with a different project.

The mistake you made is that you used postgres:latest as your postgres image. When there's a major upgrade to the postgres database, it sees the existing files from the previous version, which are not compatible, and usually ends up corrupting them.

One thing you can try, which might or might not work, is that you can update the current image tag for your postgres with postgres:17 and see if it's able to recover somehow. I assume that the last time you setup your environment the latest tag was pointing to 17 series.

[Shardboii]

Another weird thing. I tried just recreating the DB in Postgres 18. And when i tried that the same error came up. Even though i gave it an empty directory. Downgrading to Postgres 17 did fix the issue tho.
Either its an Error on my part or the Documentation needs to include this as a sidenote. I will try this again soon on a Fresh VM

[MarleTangible]

Maybe there's a bug about the postgres 18 support or something else is of issue with the current setup.

Have you tried creating a brand new installation with both postgres and NPM volumes are brand new? It's possible that the files on the NPM side might be causing the issue.

Regardless, I'm glad that you were at least able to recover your current setup.

[Shardboii]

Spinning up a Fresh installation with no previous data still gives the same error. Container Exited with code 1

Error: in 18+, these Docker images are configured to store database data in a
       format which is compatible with "pg_ctlcluster" (specifically, using
       major-version-specific directory names).  This better reflects how
       PostgreSQL itself works, and how upgrades are to be performed.
       See also https://github.com/docker-library/postgres/pull/1259
       Counter to that, there appears to be PostgreSQL data in:
         /var/lib/postgresql/data (unused mount/volume)
       This is usually the result of upgrading the Docker image without
       upgrading the underlying database using "pg_upgrade" (which requires both
       versions).
       The suggested container configuration for 18+ is to place a single mount
       at /var/lib/postgresql which will then place PostgreSQL data in a
       subdirectory, allowing usage of "pg_upgrade --link" without mount point
       boundary issues.
       See https://github.com/docker-library/postgres/issues/37 for a (long)
       discussion around this process, and suggestions for how to do so.

Heres the Compose file

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      # These ports are in format <host-port>:<container-port>
      - '89:80' # Public HTTP Port
      - '1032:443' # Public HTTPS Port
      - '30320:81' # Admin Web Port
      - '3139-3188:3001-3050'
      # Add any other Stream port you want to expose
      # - '21:21' # FTP
    environment:
      # Postgres parameters:
      DB_POSTGRES_HOST: 'db'
      DB_POSTGRES_PORT: '5432'
      DB_POSTGRES_USER: 'npm'
      DB_POSTGRES_PASSWORD: 'npmpass'
      DB_POSTGRES_NAME: 'npm'
      # Uncomment this if IPv6 is not enabled on your host
      # DISABLE_IPV6: 'true'
    volumes:
      - npmdata:/data
      - npmcerts:/etc/letsencrypt
    depends_on:
      - db

  db:
    image: postgres:latest
    environment:
      POSTGRES_USER: 'npm'
      POSTGRES_PASSWORD: 'npmpass'
      POSTGRES_DB: 'npm'
    volumes:
      - postgres:/var/lib/postgresql/data

volumes:
  postgres:
  npmdata:
  npmcerts:

[MarleTangible]

@Shardboii What you're experiencing is the side effects of various changes and that's why it's strongly advised that you pin the good working versions in your docker compose file when setting things up.

Postgres 18 is a major release and made some changes to how it's configured.

https://hub.docker.com/_/postgres

Important Note: (for PostgreSQL 17 and below) Mount the data volume at /var/lib/postgresql/data and not at /var/lib/postgresql because mounts at the latter path WILL NOT PERSIST database data when the container is re-created.