Docker Community Forums

Share and learn in the Docker community.

Mount.nfs into container Centos

Hello,
I build a centos container FROM centos:latest

And i run this container with a docker-compose.yml like this

version: '3.7'
services:
    app:
        image: XXX
        container_name:XXX_SERVER
        restart: always
        volumes:
            - ${LOCAL_SOURCE}:/XXXX/SOURCES
        ports:
            - ${APACHE_LISTEN_PORT}:${APACHE_LISTEN_PORT}
        environment:
            - APACHE_LISTEN_PORT=${APACHE_LISTEN_PORT}
        cap_add:
          - ALL
        privileged: true

After i entered into my container and i do this:

docker exec -ti XXX_SERVER bash
[root@0f7053af28ff Server]# mount -a

I get this error:

mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use ‘-o nolock’ to keep locks local, or start statd.
mount.nfs: Protocol not supported

the file /etc/fstab looks like:

192.168.0.123:/volume1/DATA /home/XXXX/DATA nfs defaults 0 0

Ther is a way to do a mount into my container, to a network storage ?

mod update: wrapped compose file content in code block (</> icon) instead of quote block (" icon)

Try using the syntax

volumes:
      - type: bind
        source: .
        target: /src/website

Or don’t use docker-compose for this container, and specify the mounts as command line options.

@jeyzorus what you try to do is an anti-pattern: you soften the isolation just to be able to mount a remote share from inside the container… There is not much of the isolation left the way you try to do it.

Either use a docker volume baked by nfs to let docker manage the nfs mount for you (which is the prefered approach, nfsv4 will be less headache than nfsv3!) or mount your nfs share to a host folder and use a bind like @gonnagle suggest to mount the host folder into the container.

The 2nd approach will cause problems when the nfs share goes stale - the same way it does when a native host process accesses the mount point of a stale remote share.

I also tried doing this, making an external volume as you suggest but maybe I got it wrong. In my docker compose:

services:
    app:
        image: XXXXX
        ....
        volumes:            
           - shared_data:/home/xxxx/DATA
        cap_add:
          - ALL
        privileged: true

volumes:
  shared_data:
    driver_opts:
      type: cifs
      o: "username=xxxx,password=xxxx,addr=XXX.local,dir_mode=0777,file_mode=0777,noperm"
      device: "//192.168.0.123/DATA/"

This is the error when i run docker-compose up:

ERROR: for app Cannot create container for service app: failed to mount local volume: mount //192.168.0.123/DATA/:/var/lib/docker/volumes/docker_shared_data/_data, data: username=xxx,password=xxx,addr=192.168.0.2,dir_mode=0777,file_mode=0777,noperm: permission denied

Observations:

  • The thread title is about nfs
  • The OP is about mouting a nfs share from inside a container
  • My suggestion is about using nfsv4 baked volume instead
  • The last post presents an unrelated error caused by wrong cifs parameters

It was ntfs originally. I changed it because the conversation was about nfs and the error message contained mount.nfs not mount.ntfs.

update: but it was not the point of your observation I suppose :slight_smile:

Sorry I made a mistake.

Because I’m inspired by a classic centos machine at my disposal which had both cifs and nfs editing.

But what i want its nfs mount. So i will try nfsv4 following this

I tried this.

First, create a NFS volume like this:

docker volume create --driver local --opt type=nfs --opt o=addr=192.168.0.123,rw --opt device=:/DATA synodatas

Start my container using this volume like this

docker run -it -d --name tt --mount source=synodatas,target=/home/XXX/DATA myimagecontainer

docker: Error response from daemon: invalid mount config for type “volume”: invalid mount path: ‘C:/Program Files/Git/home/XXX/DATA’ mount path must be absolute.

I dont know why target its not consider as the path into mycontainer…

You give your best to keep it a moving target, don’t you? :slight_smile:

Let me bring it back to the compose file solution.

I use it like this with an nfsv4 share on a Syno with DSM6.2.x:

services:
    app:
        image: XXXXX
        ....
        volumes:            
           - shared_data:/home/xxxx/DATA
        cap_add:
          - ALL
        privileged: true

volumes:
  shared_data:
    driver_opts:
      type: nfs 
      o: addr=192.168.0.123,nfsvers=4
      device: ":/volume1/DATA"

Of course you need to make sure the process in the container either runs with the uid:gid of the exposed nfs share or the permissions are set loose that any process is able to write into it.

N.B.: once a volume is created its configuration is immutable! Whenever you change a volumes configuration in a compose file, you need to remove the volume and re-create it with the next execution of docker-compose up -d.

Make sure nfsv4 is enabled in your Syno (on DSM6.2.x you need to enable v4.1, on DSM7.x you need to enable v4) Make sure the fileshare’s NFS permissions allow the ip(-range) of docker engine’s ip.

When it commes to the error message with --mount: I have no idea. It doesn’t make sense to me, as target, destination or dst can be used to address the path inside the container. Must be a Docker Desktop for Windows speciality… not sure though, I don’t use DDfW.

Hi,
so i tried this:

volumes:
  shared_data:
    driver_opts:
      type: nfs 
      o: addr=192.168.0.123,nfsvers=4
      device: ":/volume1/DATA"

and i get : protocol not supported.

So i tried with nfsvers=3

volumes:
  shared_data:
    driver_opts:
      type: nfs 
      o: addr=192.168.0.123,nfsvers=3
      device: ":/volume1/DATA"

and i get: permission denied

So i tried to add username and password:

volumes:
  shared_data:
    driver_opts:
      type: nfs 
      o: addr=192.168.0.123,nfsvers=3,username=xxxx,password=xxx
      device: ":/volume1/DATA"

and i get, invalid argument

Do you have any idea ?

… ?

We have enabled NFS v4 in our DSM6.2.x with our admin.
The allowed ip are domain ip : 192.168.0.1/24

So i tried another time this:

volumes:
  shared_data:    
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.0.123,nfsvers=4
      device: :/volume1/DATA

And i get this error :
data: addr=192.168.0.123,nfsvers=4: no route to host

When i re-launch before i do:

docker-compose down
docker volume rm shared_data

But after i get this error
data: addr=192.168.0.123,nfsvers=4: operation not permitted