docker-volume-netshare icon indicating copy to clipboard operation
docker-volume-netshare copied to clipboard

netshare cifs and passing UID/GID through docker compose

Open kanthamohan opened this issue 6 years ago • 5 comments

According to the netshare help page (docker-volume-netshare cifs --help) cifs mount options like uid,gid etc can be passed through the -o flag. However how does one pass this through the compose file?

An extract of my compose file is below which seems to be doing nothing with the uid/gid being passed and instead the drive is mounted as root.

version: '3.2' volumes: appconfig: driver_opts: share: freenas.nkak.uk/nascifs/DockerAppData/app/config o: uid=10001,gid=50012,iocharset=utf8,rw driver: cifs appdata: driver_opts: share: freenas.nkak.uk/nasdata o: uid=0,gid=50011,iocharset=utf8,rw driver: cifs

Any thing to mount a cifs share with a given uid/gid will help.

kanthamohan avatar Apr 29 '18 14:04 kanthamohan

I am having the same issue with the docker run command: cker run -d --mount type=volume,volume-driver=cifs,volume-opt=uid=1000,volume-opt=gid=1000,source='10.10.10.10/storage',destination='/data/testing'

I tried variations on that but could not get it to work. Docker doesn't give me an error but it mounts the drive as root still. I can mount the drive manually using the "-o" option without any problems.

swells-ac avatar Aug 10 '18 18:08 swells-ac

there is also an option cifsopts which i found in the source code. in general cifsopts seems to work, because it uses the option nobrl as I want. But have the problem with other options like uid, gid, forceuid, forcegid.

tried it with this both variants:

--mount 'type=volume,dst=/var/lib/grafana,src=grafana_test,volume-driver=cifs,volume-opt=share=host01/services_data/grafana_data,volume-opt=username=myuser,volume-opt=password=mypw,volume-opt=domain=mydomain,volume-opt=fileMode=0777,volume-opt=dirMode=0777,volume-opt=uid=472,volume-opt=gid=472,"volume-opt=cifsopts=nobrl,forceuid,forcegid"'

and

--mount 'type=volume,dst=/var/lib/grafana,src=grafana_test,volume-driver=cifs,volume-opt=share=host01/services_data/grafana_data,volume-opt=username=myuser,volume-opt=password=mypw,volume-opt=domain=mydomain,volume-opt=fileMode=0777,volume-opt=dirMode=0777,"volume-opt=cifsopts=uid=472,gid=472,nobrl,forceuid,forcegid"'

uid, gid, forceuid and forcegid seems to be ignored. It always mounts with uid=0,noforceuid,gid=0,noforcegid,nobrl

spali avatar Aug 15 '18 12:08 spali

I think I got it... at least if named volume was used as in my example, but probably also in your case. one problem was... I need to delete delete the volume always manually on changes to the mount options. I'd expected to update itself by using it in the docker run command, which is not the case. So my second example above works if the volume is created the first time with the correct options or the volume is removed before executing the docker run again.

spali avatar Aug 15 '18 14:08 spali

I couldn't get that working. Are you sure you didn't mount it manually first? The mount should go away when you do a stop on the container. That is the advantage of the driver. It can mount when the container runs and remove it after.

I can mount it manually like this: mount -t cifs -o username=,password=,domain= -o uid=1000,gid=1000 //10.10.10.10/imaging2 /mnt

The driver supports the -o option and so does the mount command. So am not sure why docker isn't passing this along. Right now I mount it by hand and than load it in as a standard mount. But that means I can't use a scheduling software.

swells-ac avatar Aug 15 '18 15:08 swells-ac

I never used the o option for driver or docker. So can't say about this. In all my tests I used docker run or a stack compose file for volumes. As you said, the mount was unmounted when the container stops, but the volume keeps registered in docker. Including the options. Rerunning the docker run or composefile with changed options did not update the options in the volume. The volume was always reused with the previous defined options. So I had to remove it manually. This is not a problem of the netshare driver, but a limitation in docker which doesn't update the options in the volume. It was my wrong assumption that docker updates the volume like it does for services.

spali avatar Aug 15 '18 15:08 spali