Postgres in Docker: password authentication failed for user "postgres" from Node app after restore, even after ALTER ROLE

Hi all,

I am running a Node.js backend and PostgreSQL in separate Docker containers on a Linux server and I am stuck with an auth issue from the app side.

Setup

  • Backend container: vizayard-backend (Node.js app on port 6000)
  • Postgres container: postgres_container_v2 (image postgres:16)
  • Ports: 0.0.0.0:5433->5432/tcp on the Postgres container
  • Database name: postgres
  • User: postgres

I restored a full logical backup into the postgres DB inside the container using:

bash

docker exec -i postgres_container_v2 psql -U postgres -d template1 -c "CREATE DATABASE postgres WITH OWNER postgres;"
cat backup.sql | docker exec -i postgres_container_v2 psql -U postgres -d postgres

Tables and data look fine when checked via:

bash

docker exec -it postgres_container_v2 psql -U postgres -d postgres -c "\dt"

What I already tried

Inside the Postgres container I ran:

sql

ALTER ROLE postgres WITH PASSWORD 'SomeStrongPassword!';

I then updated my Node app DB config to use:

  • user: postgres
  • database: postgres
  • host: Postgres container / mapped host port
  • password: postgres!

However, the app still logs:

text

ERROR: Error in getTrendingVisa: password authentication failed for user "postgres"
ERROR: Error in getAllVisa: password authentication failed for user "postgres"

So it looks like the password change is not being honored (or not used correctly) for the Node connection, even though the role password was altered.

Questions

  1. What is the correct way to define and persist the password for the postgres user in the official postgres:16 Docker image so that a Node.js app in another container (or on the host) can authenticate reliably?
  2. Given that this container was already initialized and then I did a manual restore with psql, is it safe to just rely on ALTER ROLE postgres WITH PASSWORD 'postgres';, or should I recreate the container with POSTGRES_USER / POSTGRES_PASSWORD env vars and a fresh volume?
  3. Are there any pg_hba.conf / authentication or networking gotchas in this scenario (container‑to‑container vs host‑to‑container) that could explain why the Node app still gets password authentication failed while the role password was explicitly changed?

If needed, I can also share my Node DB connection config and the exact docker run / docker-compose definition for postgres_container_v2.

A container image is just a template to give you a software that can run in an isolated way in a container. The “postgres:16” official Docker image contains Postgres so how that stores passwords depends on how Postgres stores passwords. If you resotred the data of Postgres, either the data required to acces postgres was corrupted or the restored data didn’t contain the password you expected.

Regarding your questions:

  1. The image descriptions shows how you can store persistent data outside the container properly. Depending on the postgres version, the PGDATA path can be different, but if you used mounted folders and didn’t store data on the container’s filesystem, you did right: https://hub.docker.com/_/postgres

  2. Containers can be created, deleted, recreated and it will not affect data as long as you used volumes or bind mounted folders as I mentioned in point 1. So no, you don’t need to use environment variables to create a new user or modify an existing user. That is used only when the postgres database is first initialized. So it is not just tht you can use ALTER ROLE, but you need to entirely rely on any native Postgres solution, including ALTER ROLE.

  3. As far as I remember, the pg_hba.conf is stored in the same folder where other database files. So if you mounted a folder or volume I mentioned in point 1 and 2, that should have been restored as well. If it was corrupted in any way or not in a state you expect it to be, I think you need to fix that manually. The pga_hba.conf can control how and where you can access the db from, but it is not changed when the data dir is not empty. It is in an “IF” block based on a DATABASE_ALREADY_EXISTS variable: postgres/16/trixie/docker-entrypoint.sh at 2925b19f45ceeb8ab8488eec226f2736abf297e1 · docker-library/postgres · GitHub

    You can also see in the container logs whether initialization was “skipped” or not.

You can share that if you suspect you did something wrong like mounting something incorrectly. But if you found all the existing data in the container, except the password didn’t work, I assume your mount was correct..

Since the volume mounting and data persistence appear to be working correctly, I focused next on the Postgres-level configuration. I verified that pg_hba.conf is using scram-sha-256, and I also reset the role password from inside the container using ALTER ROLE, but the authentication issue still persists.

At this point, could you suggest what additional areas or configurations I should check next to further narrow down the root cause?

do I understand correctly, that not even ALTER ROLE works for setting a new password?
Does creating a new user work?

Maybe you could try a Postgres community

I am happy to continue helping when you find anything Docker-related, but for now, it doesn’t seem to be the case.

Maybe you find someone here as well who had a similar issue, but you could have better luck with more advanced Postgres users and administrators.

Thanks for suggestion , let me try postgres community regarding resolution of issue

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.