In 18+, /var/lib/postgresql is the mount target and still the postgres user's home directory. This brings back #274 (fixed by #277) when doing a bind mount on a new directory.
I have this issue again with v18. I started over with a fresh container and newly created volumes. This is my compose file:
services:
db:
image: postgres:18-alpine
restart: unless-stopped
environment:
- POSTGRES_PASSWORD=redacted
- TZ=Europe/Berlin
- PGTZ=Europe/Berlin
volumes:
- /mnt/storage/postgres-data:/var/lib/postgresql
ports:
- "5432:5432"
Originally posted by @dkadioglu in #274
If the local directory for the bind mount (like /mnt/storage/postgres-data) doesn't exist before doing a docker compose up, then it will be automatically created by docker as root owned. If users need the .psql_history file, then they'll need to pre-create the directory locally (or chown/chmod after) with permissions such that the postgres user of the image can use it (uid/gid 70 in Alpine; uid/gid 999 in Debian); alternatively, they can run the image as a different user (e.g. user: 1000:1000) that already has permissions to access that directory on the host.
Now that 18 has moved the volume to /var/lib/postgresql/ instead of PGDATA, then it might make sense for us to chown or chmod it in the entypoint script so that the postgres user correctly owns or can at least use their home directory. 🤔 It could be a breaking change though, so we'll have to give it some thought.
In 18+,
/var/lib/postgresqlis the mount target and still thepostgresuser's home directory. This brings back #274 (fixed by #277) when doing a bind mount on a new directory.Originally posted by @dkadioglu in #274
If the local directory for the bind mount (like
/mnt/storage/postgres-data) doesn't exist before doing adocker compose up, then it will be automatically created by docker as root owned. If users need the.psql_historyfile, then they'll need to pre-create the directory locally (or chown/chmod after) with permissions such that thepostgresuser of the image can use it (uid/gid 70 in Alpine; uid/gid 999 in Debian); alternatively, they can run the image as a different user (e.g.user: 1000:1000) that already has permissions to access that directory on the host.Now that 18 has moved the volume to
/var/lib/postgresql/instead ofPGDATA, then it might make sense for us tochownor chmod it in the entypoint script so that thepostgresuser correctly owns or can at least use their home directory. 🤔 It could be a breaking change though, so we'll have to give it some thought.