Postgres 18: VOLUME/PGDATA path change breaks existing mounts — docs/notes request

[morgoved]

With Postgres 18 the Docker Official Image appears to have changed the expected mount target.
Observed behavior:

• Mounting a volume at /var/lib/postgresql/data (the historical default) now fails at container start with a runc error like:
  “error mounting ... to rootfs at /var/lib/postgresql/data: ... no such file or directory”.
• Mounting the same volume at /var/lib/postgresql works and the container starts fine.

Impact:

• A huge amount of deployment tooling assumes /var/lib/postgresql/data by default:
  Helm charts, Kubernetes operators/manifests, Terraform/Ansible roles, docker-compose examples, CI templates, etc.
  This change breaks upgrades 17 → 18 with no action from users, often in production.

Requests:

1. Document prominently in the README/release notes for 18+ that the recommended mount has changed to /var/lib/postgresql,
   plus a clear upgrade/migration note (including PGDATA defaults for 18).
2. Provide a backward-compatibility path so that mounting at /var/lib/postgresql/data still works, e.g.:
   • Create the legacy directory in the image and allow either path to be a valid mountpoint; or
   • Add an entrypoint fallback that accepts both /var/lib/postgresql and /var/lib/postgresql/data; or
   • Provide an opt-in compat flag/tag/env (e.g. POSTGRES_COMPAT_MOUNT=1) that makes /var/lib/postgresql/data valid again; or
   • Ship a symlink that preserves the legacy target (if acceptable from a security/packaging standpoint).

This would greatly ease upgrades because so many ecosystems hard-code the legacy path.
Happy to provide exact error logs and minimal reproducer if needed.

[Liquidmasl]

+

This was a bitch to find out.

[zandercodes]

+1
Same problem here
With 17.6 works all fine

[jeffery9]

ERROR: for 58345ae78c23_odoo17_db_1 Cannot start service db: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/host_mnt/Users/jeffery/containers/odoo17/pgdata18" to rootfs at "/var/lib/postgresql/data": change mount propagation through procfd: open o_path procfd: open /var/lib/docker/overlay2/b51da6cca0c03cf537abb037093d587b3d38b9f28ea9903e6966918b67d2d9cd/merged/var/lib/postgresql/data: no such file or directory: unknown

[Liquidmasl]

I went back to 17 to not deal with this

[zandercodes]

I found a solution on Reddit. Link: here.

I decided to upgrade my databases to Postgres 18 because why not. Since my databases were small, I just did a docker exec db pg_dump > ~/backup.sql instead of using the dedicated upgrade tools. I changed the image from postgres:17-alpine to postgres:18-alpine, deleted the existing volume since it won't be compatible, and then started a pull.

It succeeded and I restored the backup again. I noticed however after doing docker volume ls that I have anonymous volumes linked to the Postgres container.

It turns out the mount has moved. Instead of /var/lib/postgresql/data, you need to mount now to /var/lib/postgresql.

Oh well. Sources:

Dockerfile for Postgres 18 Alpine

Dockerfile for Postgres 17 Alpine