Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

netshare cifs and passing UID/GID through docker compose #162

Open
kanthamohan opened this issue Apr 29, 2018 · 5 comments
Open

netshare cifs and passing UID/GID through docker compose #162

kanthamohan opened this issue Apr 29, 2018 · 5 comments

Comments

@kanthamohan
Copy link

kanthamohan commented Apr 29, 2018

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.

@swells-ac
Copy link

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.

@spali
Copy link

spali commented Aug 15, 2018

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
Copy link

spali commented Aug 15, 2018

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.

@swells-ac
Copy link

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.

@spali
Copy link

spali commented Aug 15, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants