I'm having trouble on mounting an nfs share inside a container

Greetings everyone.

My challenge is to maintain / persist the configuration and data of a PostgreSQL Server on my docker-host.

My resources are:

  1. Host Docker - Ubuntu 21.04 Server / 96Gb Ram / 8Tb - NAS ( mounted NFS em /mnt/stg )
    1.1) Docker Server & Client Version: 20.10.7 / API version: 1.41
    1.2) Plugins: Volume: local local-persist nfs
  1. Scenery
    #>mkdir -p /mnt/stg/pg01
    #>chown -R nobody:nogroup /mnt/stg/pg01 && chmod 777 /mnt/stg/pg01
    #>docker network create --subnet=172.18.0.0/16 ntwkr_pg01

My problem is:
When creating the volume on host storage (eg /mnt/stg/pg01), Docker (does not respect) insists on creating a mount-point in /var/lib/docker/volumes

My failed attempts:

[1] - bind
#>docker run --name=pg01 -d --network ntwkr_pg01 --ip 172.18.0.55 -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=pg01 -e POSTGRES_DB=postgres -e ALLOW_IP_RANGE=0.0.0.0/0 -p 5432:5432 --mount type=bind,source=/mnt/stg/pg01,target=/var/lib/postgresql localhost:5000/ws-pg10-pgis:2.5

[2] - volume
#>docker run --name=pg01 -d --network ntwkr_pg01 --ip 172.18.0.55 -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=pg01 -e POSTGRES_DB=postgres -e ALLOW_IP_RANGE=0.0.0.0/0 -p 5432:5432 —mount type=volume,source=/mnt/stg/pg01,target=/var/lib/postgresql localhost:5000/ws-pg10-pgis:2.5

[3] - volume
#>docker run --name=pg01 -d --network ntwkr_pg01 --ip 172.18.0.55 -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=pg01 -e POSTGRES_DB=postgres -e ALLOW_IP_RANGE=0.0.0.0/0 -p 5432:5432 -v /mnt/stg/pg01:/var/lib/postgresql localhost:5000/ws-pg10-pgis:2.5

in all situations, for example [3], the docker created a disposable volume of its own

    "Mounts": [
        {
            "Type": "volume",
            "Name": "efc1846574e7434ee9b313d933fcbb6d6a18f51a883e1413930747c5622a090b",
            **"Source": "/var/lib/docker/volumes/efc1846574e7434ee9b313d933fcbb6d6a18f51a883e1413930747c5622a090b/_data",**
            "Destination": "/var/lib/postgresql/data",
            "Driver": "local",
            "Mode": "",
            "RW": true,
            "Propagation": ""
        }
    ],

Why does this happen?

I think the container root can’t create the PostgreSQL configuration structure on the given host directory, but the volume is created before passing the command to the container, so this idea doesn’t make sense.

On the NAS-Server
. The export that makes the share available contains:
(no_subtree_check,rw,sync,no_root_squash)
. And the exported directory holds chown nobody:nogroup

I should use some flag in docker run like --user or --privileged=true or --cap-add=ALL ?

General: the uid/gid of the container process must match the permissions of the nfs share.

To [1]: this is the solution you want to use, if your host should be responsible to mount the nfs share, and you simply want to bind it into the container. Caveats: If the nfs share becomes a stale mount, the container will go crazy :slight_smile:

To [2] this is the solution you want to use, if docker should be responsible to mount the nfs share when the container is started and unmount it when its stopped. It will mount the nfs share into /var/lib/docker/volumes/{volumename}/_data and binds this folder into the container for you. Afair Docker should remedy the stale mount situation (though I don’t remember if it re-starts the container for it)

To [3] is pretty much identical to [1] except this is a bind-mount and not a volume. Thus, you loose the feature that copies pre-existing data from the mount target into the volume.

Uhm, and that user nobody and group nogroup happens to have the same uid:gid the container process is running witht? Most likely this is the reason :slight_smile:

Recommended: [2]

Meyay, what exactaly does it mean

General: the uid/gid of the container process must match the permissions of the nfs share.

Does this mean that I should run the container with the indication of a specific User/Group?
How would I do this?
Using the --user XXXX flag?

In general: yes. Though, the postgres image is a delicate flower when it commes to running it with change uid:gid. It requires the uid to actualy exist in the containers /etc/passwd file. For nobody, it is high likely to be the same id. If it’s not, you will need to mount the hosts’s /etc/passwd as bind-mount volume into the container.