I also cannot get drive-sharing to work, trying all different workarounds/solutions mentioned in this post. I also see similar lines in my log as @cmurczek does.
I am running a Windows 10 Pro 14393 VM inside VMWare on a Linux-Host
> [01:41:02.473][NamedPipeServer][Info ] Start done.
> [01:41:02.489][Notifications ][Info ] Docker is running
> [01:41:02.493][Mixpanel ][Info ] Usage Statistic: installShowWelcomePopup
> [01:41:02.523][Mixpanel ][Info ] Usage Statistic: appRunning
> [01:41:14.200][Auth ][Info ] Storing credentials: dockerhost:***********
> [01:41:14.218][NamedPipeClient][Info ] Sending TryShare(C, dockerhost:**********)...
> [01:41:14.224][NamedPipeServer][Info ] TryShare(C, dockerhost:**********)
> [01:41:14.347][Cmd ][Info ] Share name C
> [01:41:14.352][Cmd ][Info ] Path C:\
> [01:41:14.357][Cmd ][Info ] Remark
> [01:41:14.362][Cmd ][Info ] Maximum users No limit
> [01:41:14.366][Cmd ][Info ] Users
> [01:41:14.372][Cmd ][Info ] Caching Caching disabled
> [01:41:14.376][Cmd ][Info ] Permission EM-PC-XXX\xxx, FULL
> [01:41:14.380][Cmd ][Info ]
> [01:41:14.384][Cmd ][Info ] The command completed successfully.
> [01:41:14.390][Cmd ][Info ]
> [01:41:14.394][SambaShare ][Info ] "C" is shared
> [01:41:14.401][SambaShare ][Info ] Challenging credentials with host
> [01:41:14.532][SambaShare ][Info ] Challenging credentials with host succeeded
> [01:41:14.535][NamedPipeServer][Info ] TryShare done.
> [01:41:14.538][NamedPipeClient][Info ] Received response for TryShare
> [01:41:14.552][NamedPipeClient][Info ] Sending Mount(C, dockerhost:**********)...
> [01:41:14.558][NamedPipeServer][Info ] Mount(C, dockerhost:**********)
> [01:41:14.562][HyperV ][Info ] Mount C
> [01:41:14.681][NamedPipeClient][Info ] Received response for Mount
> [01:41:14.676][NamedPipeServer][Info ] Mount done.
> [01:42:00.316][ApiProxy ][Info ] proxy >> POST /v1.24/containers/create [rewriteBinds]
> [01:42:01.330][ApiProxy ][Info ] Rewrote mount /c/Users/dockerhost:/mnt (volumeDriver=) to /c/Users/dockerhost:/mnt
> [01:42:01.337][ApiProxy ][Info ] Failed to Walk to [snapshots e4711dd0efca74a00762491816d64f8012ead703 ro com.docker.driver.amd64-linux proxy http] 9p: No such file or directory
> [01:42:01.349][ApiProxy ][Info ] Failed to read proxies/http from snaphshot p9p.MessageRerror{Ename:"No such file or directory"}
I am not sure what I have changed, but after playing around with some permissions and manually connecting the cifs share in Windows, Docker seems to be able to mount the shares correctly.
I had some issues as well, maybe due to a special case: the PC is in a domain, but I was using a Microsoft Account instead of a domain account. After I dumped the log files from the VM and saw that there is a permission issue I considered using a domain account and it turned out that using an account within the same domain as the PC it actually worked.
I had uses a non-domain account for another reason so I tried converting the Microsoft account back to a local account (remember not to have a domain user with the same name) and it turns out that works quite as well.
I personally stayed with the last solution - I hope this might help somebody else as well.
Using my work lappy was able to mount at the office on the network. Having no luck at home trying to mount. So does that mean something with Domain permissions?
Tried a few of the things above with no success. Uninstalled/re-installed. Nada. C’est la guerre.
WIN10 v 1607 OS Build 14383.0
Client:
Version: 1.12.0
API version: 1.24
Server:
Version: 1.12.0
API version: 1.24
mount -t cifs //10.0.75.1/C /C -o username=,password=,noperm
I get a mount error(115): Operation in progress. Pinging 10.0.75.1 results in 100% package loss, traceroute fails. Pinging the Linux VM from Windows works just fine. I have deactivated the Windows FW on the host for the 10.0.75.1 interface, but no improvement. Browsing \\10.0.75.1\C from the host works fine, so the share is active and accessible.
I then checked the routing table in the Linux VM and found that there are 2 default GWs configured (10.0.75.1 and 192.168.65.1), which normally is not a good thing and could explain the failing ping and traceroute.
I also found that the system time was way off (22h in the past). Even if everything else would have been ok, Windows would have treated all requests as replay attack and thus rejected them. I manually corrected it, but it might make sense to leverage NTP to ensure proper system time.
I’ve been also struggling with this problem for a while and I’ve found a working a solution (at least for me). I have a corporate machine, Windows 10 Enterprise, inside an Active Directory (my account is an AD account). I also created a local admin account to test.
So it’s kind of obvious that the problem is somewhere between the mobylinux and the host windows10. I wanted to try to mount the C drive directly from mobylinux I couldn’t do that so I created a another VM (it was an Ubuntu) on the same network (DockerNAT) and started to play. I just tried to mount the C drive of the host Windows and list it.
The working commands:
mount -t cifs //10.0.75.1/C /mnt/share -o username=<AD_username without domain>,password=<AD_password>
mount -t cifs //10.0.75.1/C /mnt/share -o username=<AD_username without domain>,password=<AD_password>,domain=<AD_domain>
mount -t cifs //10.0.75.1/C /mnt/share -o username=<local_admin_username>,password=<local_admin_passoword>,domain=<machine_name>
The non-working commands:
mount -t cifs //10.0.75.1/C /mnt/share -o username=<AD_Domain><AD_username without domain>,password=<AD_password>
mount -t cifs //10.0.75.1/C /mnt/share -o username=<machine_name><local_admin_username>,password=<local_admin_passoword>
Unfortunately there is no way to define explicitly the domain with the Docker for Windows so finally I entered my AD username without password and it started to work!
So I guess it could be fixed making the configuration more flexible.
Make sure to allow the drive on which the folder is located through to the containers in the docker settings:
Docker tray > Settings > Shared drives > Tick the drive on which the folder is located.
Thanks @ijeweb, this was very helpful. I ended up changing the specific interface to private instead of changing the ‘unidentified Networks’ policy. The following PowerShell command did it: