Volume mounts in windows does not work

Bingo. When the firewall is switched off, everything is fine.

I could not find yet how to whitelist the adapter in Window firewall, it is not on the device list. Could anyone post a PS command line?

You can whitelist the ip range ( /

1 Like

That’s what I do, but I understood your comment that it is possible to whitelist “for the adapter”

To finalize

– Could not get any volume sharing to work (1.12.0-rc2 meanhile, but same with earlier versions)
– Reinstalled all several times, including manual cleanup.
– Norton Premier is installed and takes over the firewall
– After switching off the firewall, sharing works
– After adding a rule to Norton Firewall to allow 10.0.75/ as suggested by @donurk, everything works

@friism: I think this should be fixed in the installation procedure. My coworkers are non-technical, and I use docker to provide out-of-the box packages. Asking them to manually update firewall rules is a bit scary.


I have tried everything in this thread, but my mounts still don’t work.

In particular I tried and ensured:

  • Firewall is disabled, no other firewall installed
  • Created docker user in Windows, multiple times, with various 8-char-only passwords
  • Made sure docker has access to shares in Windows sharing permissions
  • Tried to mount as docker, photon\docker,\docker
  • Tried with different volumes
  • Tried with my personal a@b.c login I use for my Windows machine
  • Made sure SMB1 sharing is enabled
  • Tried lowering SMB security from AES128 to DES(?) [forgot which one, there was on option I found some days back and tried …]
  • Enabled file sharing for public and private connections
  • Reset & re-installed Docker multiple times, also reset credentials.
  • Made sure I can mount C:, D:, E: from Mac OS via Finder
  • Rebooted about 20 times, and tried on about 5 different days over the past weeks and Docker versions.

In fact, the problem has persisted and never worked since the very first release, and is still present with 1.12.0-rc2-beta16. The host is Windows 10.

A typical Docker log extract looks like this:

[14:41:43.817][SambaShare ][Info ] “D” is shared
[14:41:43.817][SambaShare ][Info ] Challenging credentials with host
[14:41:43.836][SambaShare ][Info ] Challenging credentials with host succeeded
[14:41:43.836][NamedPipeClient][Info ] Received response for IsShared
[14:41:43.836][NamedPipeServer][Info ] IsShared done.
[14:41:43.837][NamedPipeClient][Info ] Sending IsShared(E, photon\docker:)…
[14:41:43.838][NamedPipeServer][Info ] IsShared(E, photon\docker:
[14:41:43.850][Cmd ][Info ] Share name E
[14:41:43.850][Cmd ][Info ] Path E:
[14:41:43.850][Cmd ][Info ] Remark
[14:41:43.850][Cmd ][Info ] Maximum users No limit
[14:41:43.850][Cmd ][Info ] Users rb
[14:41:43.850][Cmd ][Info ] Caching Caching disabled
[14:41:43.850][Cmd ][Info ] Permission Photon\docker, FULL
[14:41:43.850][Cmd ][Info ] Photon\rb, FULL
[14:41:43.851][Cmd ][Info ]
[14:41:43.851][Cmd ][Info ] The command completed successfully.

By ‘does not work’ I mean the typical behavior others described: For example in the basic Alpine, folders I try to mount via docker are just magically created in MobiLinux, but do not reflect anything actually residing on my hard drive.

If I log into Hyper-V Manager, open the MobiLinuxVM and try

mount.cifs //photon/e /media/xxx -o user=docker

I receive an:

mount error(112): Host is down

I don’t know if that’s related or not, but clearly the host is up (e.g., reacts to ping from same VM), and I can also mount the same Samba volume from, say, OSX.

Any suggestions?

1 Like

On my Windows 10 everything works Hood except that on a PC with only C: drive I can’t write in host folder.

For example: mkdir in alpine /data I got error: Can’t write, permission denied.

On other drives (D:, E:, F:) on other PCs (Win 10) everything good, I can write and read all files and folders.


All thing I did is use normal windows credential (for ex: docker/123) and It’s work well on

  • Windows 10 version 1511 (Build 10586.420)
  • Docker for windows: version 1.12.0-rc2, build 906eacd

Doesnt work volume sharing in C: drive
Make all writed in that topic
every firewall turned off

and i can get

  • ".:/srv"
    in container

any suggestions?

I have the same issue, and I’ve confirmed the same input/output within the Moby VM itself (connected via Hyper-V on windows). When I go into a container itself (docker run alpine sh, for example) I get the same type of scenario.

Possibly unrelated

I realized that from within a Ubuntu 16.04 container, I couldn’t mount back to my host, either, using my host local IP Address. If I boot my computer into Ubuntu 16.04, the same mount command works just fine. So there was something unique to the containers/moby that was disabling this type of mount from happening.

Trying other options, I went back to using Samba as a mount type instead of cifs. I started getting the same type of errors, until I made the following change to /etc/samba/smb.conf

client max protocol = SMB2

At this point, a Samba (smb) type mount worked as desired, and my containers could mount to my host computer’s shares as expected. A few packages were required from the bare Ubuntu:16.04 image to use “mount -t smb”.

It’s worth noting that CIFS completely ignores smb.conf, so it does not benefit from this fix. Reading more about CIFS because of this, I’m not even sure why docker is using it. SMB2 and SMB3 are the defaults on Windows and many other applications have moved away from CIFS.

1 Like

@donurks and @dmenne Thanks so much for posting your answers. After almost giving up on Docker for Windows, I was able to solve it. The firewall was blocking access to the shared drives! Finally I can continue working on my projects.

1 Like

What doesn’t work still with last beta 1.12.0-rc3-beta18 (build: 5193) on Windows is again the Shared Drive C:.

I can’t write also with “alpine”.

Example: If I launch this:

docker run -it -v %cd%:/mytest alpine sh

and then

ls /mytest

I see my folders and files. Ok. But, when I now write this:

mkdir foldertest

I got this:

mkdir: can't create directory 'foldertest': Permission denied

I’m on a folder on my Desktop.

How to fix?

If I use a D: drive everything works.

Adding the firewall rules to allow communication to/from wasn’t doing anything - it only worked for me when I disabled it completely.

I kept thinking a bit more about this issue. And in my case, it comes down to the way the virtual adapter was being profiled by Windows (i.e Unidentified Network) - and by default windows treats Unidentified Networks as a ‘public’ network, for security reasons.

So I went to Local Security Policy > Network List Manager Policies and Double-clicked ‘unidentified Networks’ and change the location type to ‘private’. Then I restarted Docker and it worked.

I couldn’t find another way to profile the virtual adapter used by Hyper-V/docker. Another possible solution would be to turn off file/printer sharing on Guest/public networks.

Might be useful to someone else.


Now it works on my C: drive. Thanks.

I’m having the same problem here. Switched from docker toolbox to docker for windows today and mounts simply are not working. Doesn’t matter if the windows firewall is enabled or not, nor does it matter which host drive I attempt to mount. I’m wondering if docker is trying to mount from the VM instead of from the host. If I try to mount something like C:/ initially, it shows up empty. If I mount C:/Users it also shows up empty. After that, if I mount C:/ instead again, the Users directory exists (but is empty).

Sharing is enabled for C: and D: in docker, no active directory involved, windows 10 pro, docker 1.12.0-rc2-beta17 (build: 5022).

The issue from what I’ve seen in the logs is that the Docker VM (Docker for Windows using their Alpine image called Moby) mounts to your Host drive, but immediately after unmounts. In this process, the /c/ folder (and the /c/Users/ folder in your second example) are created on the VM. This means that when the mount from the Container to the Docker VM occurs, it occurs smoothly and without any issue (because /c/ does exist on the Docker VM). When you list it, it’s empty.

The issue is definitely between the Host and the Docker VM.

When I went into Win 10’s Hyper-V Manager program, I can gain direct access to the Docker VM (Moby), wherein I can see that it cannot mount to the local Host’s directory at all. Manually adding a different mount driver, I was able to. CIFS was being used by default, and this did not work for me.

Hope this can help some dev probe for a solution.

FYI, just got the update to 1.12.0-rc3-beta18. No change in behavior, mounts are still not working.

I also should have added:

Docker version 1.12.0-rc3, build 91e29e8, experimental

And I’ve tried many of the “working” tricks, such as different Auth Credentials for the Shared Drives (adding the domain; local username; microsoft email; password changed to include no special chars; no password), and the Windows 10 shared drive settings itself (Some reported that unsharing the C: drive manually with Windows, and then resetting Docker, and sharing it within Docker’s UI helped). None of this made a difference.

Attached is the relevant logs of Docker trying to mount my drive.
docker-logs.txt (28.0 KB)

1 Like

I’m suffering from the same issue. Mounting works for folders, but not files. I.e. I can see the folders present on my Win10 host in my container, but ls shows an empty directory in the container.

I get the same 3 lines in the log whenever I try to mount a volume:
[ProxyProcess ][Info ] Failed to Walk to [snapshots b5f6995d02e1583de3f69e93f2beb4b7b9eb05c0 ro com.docker.driver.amd64-linux proxy http] 9p: No such file or directory [ProxyProcess ][Info ] Failed to Walk to [snapshots b5f6995d02e1583de3f69e93f2beb4b7b9eb05c0 ro com.docker.driver.amd64-linux proxy https] 9p: No such file or directory [ProxyProcess ][Info ] Failed to Walk to [snapshots b5f6995d02e1583de3f69e93f2beb4b7b9eb05c0 ro com.docker.driver.amd64-linux proxy exclude] 9p: No such file or directory

I tried specifying the source volume as an absolute path, relative path and relative to %USERHOME%, which according the log file are all correctly translated to an absolute path in *nix notation, i.e. /c/…

This is cumbersome for providing files to the container, but even worse in regards to storing data generated in the container. Those files never reach the host, the data thus is lost when the container is stopped.

I tried all of the above mentioned approaches (FW, local user, manually unsharing c:,…) to no avail so far. I’m running Win10 Pro 14385 (latest insider) with DfW 1.12.0-rc3-beta18 (build:5226) ec40b14.

Ok, I think I found something that worked for me. Right clicking on the docker icon in my task bar, then settings brings up the docker dialog. Under Shared Drives there is a check box to allow what drives are allowed to be shared to docker. As well as an example line in a powershell terminal below it. I had to check the box. I also opted to reset the credentials at the same time. So theoretically it could have been that too. But I did both then restarted docker and mounting seems to now work.

Note, I also made sure my printing settings were setup as above that others reported. Though mine were already enabled.

1 Like

@ijeweb This was the one that worked for me, finally! Thank you