I opened an old side project again after several months. Its database was a Postgres 10 container in Docker Compose with a bind-mounted ./pgdata directory, and the compose file set POSTGRES_HOST_AUTH_METHOD: trust. The server refused every connection anyway:
FATAL: no pg_hba.conf entry for host "...", user "...", database "...", SSL off
The POSTGRES_* variables in the official image only do something when the data directory is empty. On first start, the entrypoint runs initdb and writes pg_hba.conf and the users. My pgdata directory already existed, so the container used the pg_hba.conf and roles inside it and ignored the variables.
The fix was to edit pg_hba.conf in the data directory, which is fine for a local development database:
local all all trust
host all all 0.0.0.0/0 trust
host all all ::/0 trust
docker compose restart db
That got me in. Then pg_dump -U postgres failed with role "postgres" does not exist, which fits the same story. The data directory probably didn’t come from this image’s first-start setup at all, so the roles were whatever had been created in it originally. Dumping as my own superuser role worked:
docker compose exec -T db pg_dump -U my_user -d my_app_development | gzip > my_app.sql.gz
The -T matters there. Without it, exec allocates a terminal and can mangle piped output.
The port mapping was a problem too. "5439:5432" listens on every network interface. With trust authentication, that’s a superuser login for anyone on the same network. Bind it to localhost:
ports:
- "127.0.0.1:5439:5432"
Before I got to the container, I also tried the old Homebrew Postgres installs. Those wouldn’t start, because a Homebrew update had replaced the ICU library they were linked against.