Volume mounts in windows does not work

Wow, closer to target thanks to your help. Not that I understand why this works. After all, my computer knows what is.

/ # mount -t cifs //DieterPC/C /C -o username=Dieter,password=mypassword,noperm                                                                                                                      
/ # ls                                                                                                                                                                                           
C         Database  Mac       bin       c         dev       etc       home      init      lib       linuxrc   media     port      proc      root      run       sbin      sys       tmp       usr
/ # ls C                                                                                                                                                                                         
$Recycle.Bin                 Documents and Settings       Program Files (x86)          Recovery                     Windows                      inetpub                                         
BOOTNXT                      Dokumente und Einstellungen  ProgramData                  Rtools                       autoexec.bat                 pagefile.sys                                    
BOOTSECT.BAK                 IO.SYS                       

(Rest removed, but looking fine)

Glad to hear that’s working now… your turn to let us know what did you do to make it to work… :slight_smile: One thing I noticed: you’re mounting the share using the computer name instead of the IP address…

Mounting the share using the computer name instead of the IP address: I read this from your comment: “And use the computername instead of domain name in the cifs mount command”. The blame goes to you :slight_smile:

However, I do not think that this is a solution, just a way of getting it to work in my setting. After all, this should work without four rather nasty lines on the command prompt (five, one more for c/C). I hope that it will help the developers to get this done automatically. I use docker to supply ready-to-use installation of R and Shiny to my colleagues at the hospitals, and even one line in the black box will lead to immediate “not for us” reactions.

docker run --privileged -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /usr/bin/docker:/usr/bin/docker alpine sh
# inside the created shell, you run the 2nd command:
docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/host alpine /bin/sh 
mount -t cifs //<computername>/C /C -o username=Dieter,password=yourpassword,noperm

Note: computername is the Network name of the computer.


I tried the solution from @elucas and it works for me.

1/ to be sure, change your windows password with something simple with no special chars
2/ reset your shared drive credentiel, and don’t mount C:
3/ when you are prompt for login / password use :\yourusername (or\yourusername@something.com if necessary)
and your password
4/ try with the docker example : docker run --rm -v ./folderwithfiles:/data alpine ls /data

It worked for me on 2 different PCs

1 Like

Sounds like a clever complement to my “use computername instead of 10.xx”,

Nevertheless sorry: This did not work for me.

Did you try with an absolute path ? docker run --rm -v /e/folderwithfiles:/data alpine ls /data

Tried, no success.

There is a confusing step in you description. It says “don’t mount C:” Where do you enter the login/password?

Yes. For me, there is a bug if I mount the C drive. If I check C: and E:, I can’t mount volumes. But if I reset credentials, and only mount E:, it works.

I was having the same problems with volume mounts yersterday. I could resolve it with following steps:

  1. Created a new account ‘dockeruser’ with [0-9a-zA-Z]+ password.
  2. Shared drive with shared drives screen of the traybar application.
  3. Entered\dockeruser as username and dockeruser’s password
  4. Removed sharing of the drive in windows explorer.
  5. Reshared the drive with docker
  6. Now working

It seems like the ResetCredentials option is not working properly. Basically it should do the required steps including removing the shared driver status for the connected docker users. However, this is not the case. Only manually removing the shared option on the volume allowed it to be shared correctly afterwards. I’m not sure about the account though, it might also work with your user account.

Thank you @dennisfischer! This worked for me; I have been battling with this for a while, and this fixed it right up.

I think you are correct the ResetCredentials function is probably missing something.

Docker v1.11.1-beta14
Windows 10 Pro Insider Preview

This continues to not work for me using Win10 14342, with DFW 1.11.1-beta14.
I’ve tried all of the above.

When I use: docker run --rm -v d:/:/data alpine ls -R /data

I only see a very small subset of the directories on d:, and nearly all of those that show up are empty (according to ls). It’s interesting that I do see a couple of files a couple levels down. I have no idea why.

I do see files that were created in the container, but these don’t show up in the host.


1 Like

Interestingly, I did a Reset of DFW, then reestablished the mapped drives, and things started working.

But now I’m seeing “host is down” with the same folders that worked ok an hour ago. Grrr.

I am also having trouble getting volumes to mount. I can see the directory when listing directories in the console of the VM, but there are no contents.

The test above that others have mentioned gives no results for me.

docker run -v c:/Users:/data alpine ls /data

The shared drives functionality is just too flaky to be used. It seems to be additionally impacted by connection to, or disconnection from, VPN. I find that resetting the DFW install will usually fix the problem for a while, but it always returns.

This even happens within a single docker-compose session, where a number of images are being pulled, and containers started up – it will just suddenly drop the shared drive connection, and this come to a halt.

It’s just not ready to be used.
It’s disappointing to not see more updates, with at least an attempt to improve things in this important area.

I think I’m going to have to abandon the beta for a while, go back to docker toolbox, or even vagrant. :disappointed:


1 Like

Fully agree. Too bad that docker toolbox with VM can only share the home directory easily.

Tested with Beta 15: Same as reported above, i.e. no sharing.

I had the same problem. Here is my solution: the firewall.

The HyperV-VM needs access to the host through tcp/ip, so maybe your firewall (or antivirus) is blocking the communication from inside the vm to outside. So just whitelist the adapter (vEthernet (DockerNAT) - Hyper-V Virtual Ethernet Adapter) in your local firewall/antivirus.

Hope this helps - for me it worked like a charm


@donurks Did you do this through the Windows firewall? If so, did you use a Program, Port, Predefined or Custom rule?
It looks like I already have rules added for Hyper-V related services in my firewall.

I use the kaspersky firewall. I dont know how to configure the windows firewall correctly.

I recommend that you first check your network.

You can try to unplug or turn off your internet. After that you can disable the windows firewall, restart docker (docker traybar icon -> settings -> restart docker). Now test and reactived your firewall.

You can also try the hyper v manager to connect to your vm (username: root) and try to ping your host ( If the pings works then your network is fine.

1 Like