PostgreSQL Docker Container Permission Issues with NFS Mount and custom User

[Abilash18]

Experiencing permission issues when deploying a PostgreSQL 9.6 container in Docker Swarm that uses an NFS-mounted volume for data storage. The container fails to start with the error:

FATAL: data directory "/var/lib/postgresql/data/pg_data" has wrong ownership HINT: The server must be started by the user that owns the data directory.

Environment Details
Platform: Docker Swarm
PostgreSQL Version: 9.6.24
NFS Server: re0srt10003.eresz03.com
NFS Mount: /vol/re0srt10003_vol011/NFS_customer_data_02/Production_data/nfs01/
Note:
→ only AD valid users (unix/windows) can be used to access a file share
→ local users access is not permitted (users that only exists on the local linux system)
→ Please be aware of that new file shares will be on new Server re0srt10003.eresz03.com and as mentioned in our docupedia page local users (Example UID 1000 / GID 1000) are not working. No exceptions possible! Please use your Domain Users and Groups (UID 188044 / GID 806642981) to connect to the share.

Dockerfile used to create image with custom user and group

FROM postgres:9.6.24

ENV http_proxy=http://proxy.com:8686
ENV https_proxy=http://proxy.com:8686

RUN sed -i '/stretch-updates/d' /etc/apt/sources.list && \
    sed -i 's|http://deb.debian.org/debian|http://archive.debian.org/debian|g' /etc/apt/sources.list && \
    sed -i 's|http://security.debian.org/debian-security|http://archive.debian.org/debian-security|g' /etc/apt/sources.list && \
    rm -f /etc/apt/sources.list.d/pgdg.list && \
    echo 'Acquire::Check-Valid-Until "false";' > /etc/apt/apt.conf.d/10-no-check-valid-until && \
    apt-get update && \
    apt-get install -y --allow-unauthenticated postgresql-contrib && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

RUN usermod -u 188044 postgres
RUN groupmod -g 806642981 postgres

RUN su root -c "chown -R postgres:postgres /var/lib/postgresql"

USER postgres
STOPSIGNAL SIGINT

What I've Tried

• Modified the Dockerfile to change postgres user UID/GID to match domain requirements

• Verified the user mapping inside the container shows correct IDs id postgres uid=188044(postgres) gid=806642981(postgres) groups=806642981(postgres),101(ssl-cert)

• Confirmed NFS mount is accessible by ownership shows as below, drwx--S--- 8 188044 806642981 db

• Tried to run the service without NFS volume - working as expected.

• Tried to run a postgres container with from the NFS-path: /vol/re0srt10003_vol011/NFS_customer_data_02/Production_data/nfs01/

docker run -d --name postgresCont_02 --user 188044:806642981 -e POSTGRES_PASSWORD=<pw> -v "$(pwd)":/var/lib/postgresql/data -p 5436:5432 postgres:16.10

docker logs -f 17arte345198k

chmod: changing permissions of '/var/run/postgresql': Operation not permitted
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are enabled.

fixing permissions on existing directory /var/lib/postgresql/18/docker ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok


Success. You can now start the database server using:

initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next tim
    pg_ctl -D /var/lib/postgresql/18/docker -l logfile start

postgres: invalid option -- 'v'
Try "postgres --help" for more information.

Additional Context
This setup worked previously with local user/root user, but fails when migrating to the new NFS-based storage system that enforces domain users.

Any suggestions regarding the possible root causes or alternative ways to address this issue would be highly appreciated!.