Cli: Unable to create a docker volume with local CIFS driver

[jamiejackson]

• CentOS 7.4
• Docker version 17.10.0-ce, build f4ffd25

I'm trying to create a volume with CIFS and a local driver.

Direct mounting works:

mount -t cifs -o username=user1,password=user1pass,vers=3.0 \
   //localhost/private /tmp/mediashare

Here's my attempt with docker volume create:

 docker volume create \
   --driver local \
   --opt type=cifs \
   --opt device=//localhost/private \
   --opt o=username=user1,password=user1pass,sec=ntlm,vers=3.0 \
   mediashare

docker run -it --rm -v mediashare:/tmp/mediashare \
  -d --name samba-client alpine ash

However, here's the output. The generic invalid argument error seems unhelpful.

docker: Error response from daemon: error while mounting volume '/var/lib/docker/volumes/mediashare/_data': error while mounting volume with options: type='cifs' device='//localhost/private' o='username=user1,password=user1pass,sec=ntlm,vers=3.0': invalid argument.

References

This must be old information, since I don't see a name argument for docker volume create:

• https://serverfault.com/a/848166/389114

I got it working with a plugin (docker-volume-netshare), but I want to try it without.

• https://github.com/ContainX/docker-volume-netshare/issues/143#issuecomment-343756298

My Docker Forums post:

• https://forums.docker.com/t/docker-volume-create-with-local-cifs-driver/41226/7

[radusuciu]

Works for me with a windows host, mounting into a Linux guest.

Same exact options as you except I don't have sec=ntlm,vers=3.0

[jamiejackson]

Thanks, @radusuciu.

Which works for you, docker volume create with --driver local? Could you share your command(s), to clarify?

[radusuciu]

@jamiejackson

docker volume create --driver local --opt type=cifs --opt device=//IP.ADDRESS.HERE/PATH --opt o=username=username,password=password VOLUME_NAME

Again, this was run from a Windows 10 host. Will eventually try to do this from a linux host as well. It would be awesome if this works cross-platform.

[cknowles]

Appears to be working on ubuntu, docker 17.12.0. In my case I used --opt o=username=user,password=pass,iocharset=utf8,sec=ntlmssp,file_mode=0777,dir_mode=0777

EDIT with all options, to confirm I used IP address for the device: --driver local --opt type=cifs --opt device=//IP.ADDRESS.HERE/PATH

[radusuciu]

Are all of those options necessary?

[HammerMeetNail]

I'm seeing the same issue as @jamiejackson when using a hostname and Docker 17.12.0-ce on Ubuntu and RancherOS hosts. Works fine if I use an IP Address instead as suggested by @radusuciu.

Seems this issue is specifically about being unable to create a volume using the local driver, type of cifs, and device of hostname?

[cknowles]

@radusuciu I'm not sure, just posted the options I used in their entirety just in case it can help.

[cpuguy83]

Closing since this is not really an error with docker.
All docker is doing is passing these options to the kernel as is, the "invalid argument" error is coming from the kernel because the passed in options are not correct based on the cifs module that's loaded in the kernel.

Thanks!

[ruxkor]

@cpuguy83 what's the difference between calling the mount command and docker calling it? Right now, using the same commands as one would with the mount command, the docker volume creation fails. @DJO3 's solution really seems to work, however.

[cpuguy83]

@ruxkor Docker isn't calling the mount command (which is different on every distro/release). Docker is passing the arguments directly to the mount system call.

[shuchow]

Anyone know why this only works with the IP address but not any sort of domain name?

[cpuguy83]

@shuchow There is currently a special case for resolving a domain name for type=nfs, if it we should do it for another type= then that's do-able.

[trajano]

@cpuguy83 is there a bug report for requiring a special case for resolving the domain name? I was thinking perhaps adding something like //${dns:somedomainname}/share which allows for extra processing for doing something with the domain name but be extensible for other forms of lookup like file: to read from a local file or exec: which will execute a script on the context of the local node and use the output, or secret: to read from a secret store.

[cpuguy83]

@trajano There is not. There would be no need to have a keyword just match on type and then parse the options accordingly.

[mpepping]

There is currently a special case for resolving a domain name for type=nfs, if it we should do it for another type= then that's do-able.

Since a resolve hook is in place for type=nfs, having the same functionality for type=cifs would be structural.

https://github.com/moby/moby/issues/26639

[trajano]

I opted to just make my own managed volume plugins to handle all of this so I have a bit more control and reduce the need to install additional software on the host itself. It still has the issue of installing the plugin on the host at the moment, but there is work on Docker to do the deployment via swarm which is not exposed to the CLI as of the moment.

[omartin2010]

I'm seeing the same issue as @jamiejackson when using a hostname and Docker 17.12.0-ce on Ubuntu and RancherOS hosts. Works fine if I use an IP Address instead as suggested by @radusuciu.

Seems this issue is specifically about being unable to create a volume using the local driver, type of cifs, and device of hostname?

That still seems to be an issue. I can mount on the OS using mount.cifs with the hostname, but with docker volume create ... it won't work unless I put the IP address in the path (//192.168..../share) versus //hostname/share. It seems pretty hard to believe it's the case but it is..

[cpuguy83]

@omartin2010 probably because the kernel driver does not resolve hostnames.
The only reason this works for nfs is because we special case it in docker and resolve the host name ourselves.