Mounted volumes are empty in the container. about for-win HOT 110 CLOSED

I hope to leave an useful advice. I have Windows 10 notebook with domain account. Docker version is "18.03.0-ce, build 0520e24". I had the issue of empty mount volumes. Restarting containers or even docker engine did not solve.

After googling and checking the above thread, I realized that I changed the password of the domain account (with a special character, BTW) since last time I stopped the containers.

I ensured the containers were stopped, opened docker settings, selected "Shared Drives", removed the tick on "C" and added it again. Docker asked for the Windows account credentials and I entered the new ones. After that and starting containers, mount volumes were ok. Problem solved.

Then I noticed the link "Reset credentials..." at the bottom of the "Shared Drives", which I think plays the same role as unticking and reticking shared drive checkboxes.

So, to summarize, after a (domain or local) Windows account password change, mount volumes do not work anymore because Docker engine connects using older credentials, which must then be reset in Docker "Shared Drives" settings.

I hope to save some googling/stackowerflowing to anyone who manages to get here...

from for-win.

@friism oh wow, just got it. Based on a comment in that forum thread you linked, I changed my windows password to not have special characters, reset the credentials in docker, and it started working. I don't know what docker is doing with passwords. How bizarre.

from for-win.

I had same issue after changing password in windows - after reset docker credentials it's working again

from for-win.

@DungLai From what I see, when using docker run -v with Docker Toolbox you use de path of the folder in the VM, not in your OS.

In my case Docker Toolbox created a VM named default in Virtualbox and I added the Shared Folder in the VM; Virtualbox -> default (VM) -> Settings -> Shared Folders -> Add

Then you can specify the paths in both your machine and the mapped path in the VM, like:

1. The 1st field is the path in your machine, like D:\my\app
2. The 2nd is the path in the VM, like /my-vm/app
3. Choose to Mount Automatically

(you can choose other paths too)

Restart the VM and then you can map volumes between the VM and the container like:

docker run -v /my-vm/app:/my-container/app alpine ls -la /my-container/app/

And you can access the folder inside your container using the path /my-container/app, like in the example above (you can change this path in the volume mapping).

Of couse, you can also map your entire partition, like D: to /d and access D:\some\path in your VM with /d/some/path (and use the later path when mapping volumes in docker run).

from for-win.

Hi @bagratte, thank you for taking the time to report the issue.

Have you shared the C drive before you run the docker command?

from for-win.

Docker Toolbox doesn't have Share Drive option. Changing the shared folder inside docker toolbox setting doesn't work.

from for-win.

@ctliv Thank you sir!

I had this same issue a long time ago (the company force password change every 6 months or something), but that was enough time for me to totally forget about this specific issue & solution... :)

Would be wonderful if docker could (at some convenient time) verify & highlight authentication issues.

from for-win.

I just did a fresh install of 1.12.1 on my work laptop. After installing and running docker run --rm -v c:/Users:/data alpine ls /data I got the usual empty output. I tried un-sharing and re-sharing the C drive and 'lo and behold, it's working now. Let me know if you'd like any debugging info.

from for-win.

I'm almost certain that this is an issue when a VPN is present. I had the same problem and as soon as I disconnected the VPN, things went back to normal.

from for-win.

Thanks for all the reports and details. We have just released Beta23, which has significant fixes to the way the volume mounts are implemented. It would be great if you could try it and report back if it fixes the issue with volume mounts.

You can download the Beta from here: https://download.docker.com/win/beta/InstallDocker.msi

Thanks
Rolf

from for-win.

I have uninstalled the stable and installed the new beta and I still have the same problem. In fact it now appears to be worse because I cannot mount any folders at all, whereas before I could at least mount folders in the root of my C: drive.

I have tried a local administrator account (with a simple alphanumeric password), my domain account (in domain\username format), and my domain account in just username format. My domain account does have a comma in its password.

There's definitely something strange going on with the mounts though because if I mount e.g. C:/Users, the docker container sees nothing. And if I then mount C:/Users/username, it also sees nothing. BUT if I then go back and again mount C:/Users, it will list username as a subdirectory. So just the fact of attempting to mount it previously -- even though it didn't mount correctly and its contents couldn't be seen in the container -- made it appear at least as a directory name upon subsequent mounts of its parent directory.

Diagnostic id: FCAFD1CA-0D4C-4CB3-BE10-9C0731BB8E58/2016-08-17_09-33-14

from for-win.

Just a further update, if I specify the credentials in domain\username format for my local user (that is, machine-name\username) then I can once again mount volumes outside C:\Users at least. Thank you for your attention on this issue.

from for-win.

hey @rneugeba, just wanted to report that I switched to the beta and volume mounting works fine, even when my password includes special characters. Looks like that particular issue is solved.

from for-win.

If you are login in with domain user like @ you'll need change it to / in docker setting > shaded drives.

from for-win.

@codingkeith Ah, I just realised that you switched users and this process is not as smooth as I'd like, especially wrt to shared volumes. When you switch users, say from user A to user B, and you had previously used the volume sharing as user A, even if you reset credentials etc, the drive is still shared with user A and may fail if you subsequently try to share a drive as user B.

Could you try, as your domain user, Reset Credentials, then, in an elevated powershell:

net share c

(or net share d if you are using the D: drive. If this shows something like this:

PS C:\WINDOWS\system32> net share c
Share name        C
Path              C:\
Remark
Maximum users     No limit
Users             RNEUGEBA
Caching           Caching disabled
Permission        RN-WIN10VM\rneugeba, FULL

ie Permissions <host>\<username>, FULL could you then remove the share with

net share c /delete

and re-share the drive via the UI. Now net share c should show this with your domain user and hopefully it'll work. You may have to use Beta24 for this, as I'm not sure how well the stable release handles usernames with spaces...it may work.

from for-win.

@codingkeith excellent. Glad that it worked for you. As said the multiple user scenario is not very smooth at the moment, but we also don't want to unconditionally unshare the drive either in case the user uses it for something else.

@londoncalling maybe we could add something to the FAQ. something along the line of this #25 (comment)

from for-win.

@ChristianPejrup you should need to jump through these hoops. we have a test setup with a AD controller now and it seems to work when using <domain>\<user> in the username field. If the credentials are supplied like this, the domain is definitely passed through to Linux.

One issue with multiple users is explained here: #25 (comment)

from for-win.

@rneugeba I followed your comment #25 (comment) and figured out the crucial part is domain\user.

For others I'll share different things I tried:
What worked for me for the first time:

1. Create a local admin account
2. Use a password without special characters
3. in docker reset credentials, in powershell delete the share, then reshare and make sure to use computer-name\user as username

Then I tried using a password with a bunch of special characters: This still works.
Then I tried using not the local admin account, but the domain user -- and this works too!

I had the additional problem that I am using a Microsoft account, which is somehow a different thing than a domain user. But the Microsoft account creates a domain account, one just needs to figure out which of the users is reflected in that account.

The command docker run --rm -v c:/Users:/data alpine ls /data works with this setup in:

• poweshell
• cygwin
• ubuntu bash
• cmd
  all elevated and not elevated. It doesn't work in
• git bash (mingw)

The command docker run -it -vpwd:/mnt -w /mnt ubuntu /bin/bash -c ls does not work anywhere at all.

from for-win.

I think the credentials dialogue on windows needs to be changed. It should point out that the username needs to be entered in the form domain\user or computername\user -- ideally it would fill it out automatically for the current user.

from for-win.

Fine with me too, but the crucial part is that the user should be informed that the domain is important, because well, otherwise it doesn't work and you don't get any feedback at all.

from for-win.

@kcd83 you might be able to use the net share command (e.g., see Net share command: List / create / delete network shares from command line).

And just for reference, here are some relevant Docker Docs topics on shared drives, which I assume you've already looked at:

• Shared Drives
• FAQ on VERIFY DOMAIN USER HAS PERMISSIONS FOR SHARED DRIVES (VOLUMES)

@joaofnfernandes, @friism, @FrenchBen any thoughts?

from for-win.

Is there any way to reset credentials in docker toolbox?

from for-win.

Yes, I had shared the C drive as in your screenshot.

from for-win.

Also having this problem.

C:\Users\emil.kantis> docker run --rm -v c:/Users:/data alpine ls /data
C:\Users\emil.kantis> ls C:/users


     Directory: C:\users


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       2016-08-05     11:32                administrator
d-----       2016-08-04     13:41                Default.migrated
d-----       2016-08-05     12:53                Dockerhost
d-----       2016-08-04     13:45                Emil
d-----       2016-08-05     10:13                emil.kantis
d-----       2016-08-04     13:50                PEadmin
d-r---       2016-08-04     13:40                Public

[13:22:35.071][ApiProxy       ][Info   ] proxy >> POST /v1.24/containers/create [rewriteBinds] 
[13:22:35.073][ApiProxy       ][Info   ] Rewrote mount c:/Users:/data (volumeDriver=) to /c/Users:/data
[13:22:35.096][ApiProxy       ][Info   ] Failed to Walk to [snapshots 7244a4d64be1fd01a67c160cf6869899b3c192d9 ro com.docker.driver.amd64-linux proxy http] 9p: No such file or directory
[13:22:35.098][ApiProxy       ][Info   ] Failed to read proxies/http from snaphshot p9p.MessageRerror{Ename:"No such file or directory"}

I've tried unsharing/re-sharing, uninstalling and re-installing docker

from for-win.

Same here.

PS D:\> docker run --rm -v c:/Users:/data alpine ls -a /data
.
..
PS D:\>

PS D:\> docker --version
Docker version 1.12.0, build 8eab29e
PS D:\> docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 10
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 17
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge overlay host null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.15-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 6
Total Memory: 8.021 GiB
Name: moby
ID: 6A56:MU5U:HN2X:F2XP:KKZR:DUFM:B4RB:RMNP:DQXA:U745:UYNW:KFZ5
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

EDIT: add relevant log section

[19:43:24.684][ApiProxy       ][Info   ] proxy >> POST /v1.24/containers/create [rewriteBinds]
[19:43:24.688][ApiProxy       ][Info   ] Rewrote mount c:/Users:/data (volumeDriver=) to /c/Users:/data
[19:43:24.702][ApiProxy       ][Info   ] Failed to Walk to [snapshots 33809d47c4c64c6834bbfa8ead740e920317cd32 ro com.docker.driver.amd64-linux proxy http] 9p: No such file or directory
[19:43:24.705][ApiProxy       ][Info   ] Failed to read proxies/http from snaphshot p9p.MessageRerror{Ename:"No such file or directory"}
[19:43:24.711][ApiProxy       ][Info   ] proxy >> POST /v1.24/containers/create
[19:43:24.715][ApiProxy       ][Info   ] Dial Hyper-V socket 81e04832-8a73-4b67-90bb-a3bb3ce5b156:23a432c2-537a-4291-bcb5-d62504644739
[19:43:24.819][ApiProxy       ][Info   ] proxy << POST /v1.24/containers/create
[19:43:24.827][ApiProxy       ][Info   ] proxy >> POST /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04/attach?stderr=1&stdout=1&stream=1
[19:43:24.834][ApiProxy       ][Info   ] Dial Hyper-V socket 81e04832-8a73-4b67-90bb-a3bb3ce5b156:23a432c2-537a-4291-bcb5-d62504644739
[19:43:24.841][ApiProxy       ][Info   ] Upgrading to raw stream
[19:43:24.849][ApiProxy       ][Info   ] proxy >> POST /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04/start [start]
[19:43:24.855][ApiProxy       ][Info   ] proxy >> POST /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04/start
[19:43:24.859][ApiProxy       ][Info   ] Dial Hyper-V socket 81e04832-8a73-4b67-90bb-a3bb3ce5b156:23a432c2-537a-4291-bcb5-d62504644739
[19:43:25.156][ApiProxy       ][Info   ] proxy << POST /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04/start
[19:43:25.243][ApiProxy       ][Info   ] proxy << POST /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04/attach?stderr=1&stdout=1&stream=1
[19:43:25.248][ApiProxy       ][Info   ] proxy >> POST /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04/wait
[19:43:25.252][ApiProxy       ][Info   ] Dial Hyper-V socket 81e04832-8a73-4b67-90bb-a3bb3ce5b156:23a432c2-537a-4291-bcb5-d62504644739
[19:43:25.549][ApiProxy       ][Info   ] proxy << POST /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04/wait
[19:43:25.556][ApiProxy       ][Info   ] proxy >> GET /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04/json
[19:43:25.564][ApiProxy       ][Info   ] Dial Hyper-V socket 81e04832-8a73-4b67-90bb-a3bb3ce5b156:23a432c2-537a-4291-bcb5-d62504644739
[19:43:25.570][ApiProxy       ][Info   ] proxy << GET /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04/json
[19:43:25.581][ApiProxy       ][Info   ] proxy >> DELETE /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04?force=1&v=1
[19:43:25.587][ApiProxy       ][Info   ] Dial Hyper-V socket 81e04832-8a73-4b67-90bb-a3bb3ce5b156:23a432c2-537a-4291-bcb5-d62504644739
[19:43:25.594][ApiProxy       ][Info   ] proxy << DELETE /v1.24/containers/7441d331ab6a2e78a5669c5fcbca9a664140d87038f1df3b5247a7bf10ccbc04?force=1&v=1

from for-win.

Samsies

Update: tried changing password (removed special characters), but it did not fix my problem.

Update 2: Another thing I can't figure out and I think it is related is that with the docker-toolbox I could use and from there I was able to login and pull my image into my vm. I am unable to ssh into MobyLinuxVM. Also when I pull up the vm through the Hyper-V Manager it just shows a black screen, so I can't even do anything from there. Should I just use a docker-compose file instead of trying to mount?

diagnostic id: 1A1304D4-EA05-47A9-88C8-55DB45E9BA2E/2016-08-09_12-59-31

Update3: I installed beta 23 and it is still not working for me. I am on a domain computer

diagnostic id: D91B0EBA-383B-4CC3-9C6F-FA4C02EE6D81/2016-08-17_12-26-28

Update4: It still is not working even with [domain][username] as login or [computer name].[domain][username]

Not sure if it helps to know or not but I use vpn cisco anyconnect v 3 client as well.

diagnostic id: D91B0EBA-383B-4CC3-9C6F-FA4C02EE6D81/2016-08-19_11-53-10

Update5: I am working on an older DELL Latitude. I have upgraded it to Windows 10, but it looks like the machine isn't supported by Windows 10. It runs fine, but I have noticed it doesn't seem to like my CD/DVD drive. Could this be having an adverse affect on mounting the mobylinux.iso?

from for-win.

Also the same problem.
I think it is because of some issues with permissions.

When I try to run containers that need to write some files to the disk (like for instance, Bitnami's laravel container) the container fails to write those files due to a permission denied error.

That's probably related to the reason why there are no listed files on mounted volumes.

I've even twiked arround on the windows permission system giving full access to everyone in the folder of the project with no success.

uploaded diagnostic ID: 618072AE-BDD6-4A12-8E6B-BD3E53120D0F/2016-08-05_22-16-01

from for-win.

Same problem here. I've tried multiple commands to mount the host directory, but none of them worked.

docker run --rm -v c:/Users/myusername/Downloads:/data ubuntu ls -la /data
total 4
drwxr-xr-x  2 root root   40 Aug  6 02:53 .
drwxr-xr-x 34 root root 4096 Aug  6 02:53 ..

/data was created, but it contained nothing.

from for-win.

Can you check whether you have 3rd party antivirus software installed? Some users have reported problems due to that:

• https://twitter.com/philiciousPhil/status/761529849878089728
• https://forums.docker.com/t/volume-mounts-in-windows-does-not-work/10693/108?u=friism

from for-win.

Yes, I have Mcafee installed and I don't have the permission to uninstall or disable it. I guess the anitvirus software might be the reason but there's no way for me to check it.

from for-win.

@friism I've just got windows defender and firewall. Everything default I think.

from for-win.

Well the password thing did it for me!
thanks @ProCynic

from for-win.

I also confirm the workaround of removing special characters from the password. In my case the offending character was the semicolon (;).
This must be either documented or, better still, fixed.

from for-win.

I've had nothing but flaky behavior with shared drives with DFW for months. Just updated to the latest build (5971), and have shared my 2 drives. One of them appears to be visible, while the other is not:

PS C:\Users\pekj> docker run --rm -v d:/:/data alpine ls /data
PS C:\Users\pekj>

Maybe this is some sort of permissions thing, but as I provided my own credentials, not sure what it could be. Here is log snippet from above:

[08:09:57.351][ApiProxy ][Info ] proxy >> POST /v1.24/containers/create [rewriteBinds]
[08:09:57.354][ApiProxy ][Info ] Rewrote mount d:/:/data (volumeDriver=) to /d:/data
[08:09:57.365][ApiProxy ][Info ] Failed to Walk to [snapshots 3ffc6ae09d300fab4008d79f7e94b1886ab0830e ro com.docker.driver.amd64-linux proxy http] 9p: No such file or directory
[08:09:57.368][ApiProxy ][Info ] Failed to read proxies/http from snaphshot p9p.MessageRerror{Ename:"No such file or directory"}
[08:09:57.371][ApiProxy ][Info ] proxy >> POST /v1.24/containers/create
[08:09:57.373][ApiProxy ][Info ] Dial Hyper-V socket c54bc9af-2a64-4e51-9d3d-4a95d2eda316:23a432c2-537a-4291-bcb5-d62504644739
[08:09:57.471][ApiProxy ][Info ] proxy << POST /v1.24/containers/create
[08:09:57.480][ApiProxy ][Info ] proxy >> POST /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252/attach?stderr=1&stdout=1&stream=1
[08:09:57.482][ApiProxy ][Info ] Dial Hyper-V socket c54bc9af-2a64-4e51-9d3d-4a95d2eda316:23a432c2-537a-4291-bcb5-d62504644739
[08:09:57.485][ApiProxy ][Info ] Upgrading to raw stream
[08:09:57.487][ApiProxy ][Info ] proxy >> POST /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252/start [start]
[08:09:57.490][ApiProxy ][Info ] proxy >> POST /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252/start
[08:09:57.495][ApiProxy ][Info ] Dial Hyper-V socket c54bc9af-2a64-4e51-9d3d-4a95d2eda316:23a432c2-537a-4291-bcb5-d62504644739
[08:09:57.730][ApiProxy ][Info ] proxy << POST /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252/start
[08:09:57.783][ApiProxy ][Info ] proxy << POST /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252/attach?stderr=1&stdout=1&stream=1
[08:09:57.786][ApiProxy ][Info ] proxy >> POST /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252/wait
[08:09:57.788][ApiProxy ][Info ] Dial Hyper-V socket c54bc9af-2a64-4e51-9d3d-4a95d2eda316:23a432c2-537a-4291-bcb5-d62504644739
[08:09:58.012][ApiProxy ][Info ] proxy << POST /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252/wait
[08:09:58.022][ApiProxy ][Info ] proxy >> GET /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252/json
[08:09:58.034][ApiProxy ][Info ] Dial Hyper-V socket c54bc9af-2a64-4e51-9d3d-4a95d2eda316:23a432c2-537a-4291-bcb5-d62504644739
[08:09:58.043][ApiProxy ][Info ] proxy << GET /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252/json
[08:09:58.048][ApiProxy ][Info ] proxy >> DELETE /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252?force=1&v=1
[08:09:58.053][ApiProxy ][Info ] Dial Hyper-V socket c54bc9af-2a64-4e51-9d3d-4a95d2eda316:23a432c2-537a-4291-bcb5-d62504644739
[08:09:58.060][ApiProxy ][Info ] proxy << DELETE /v1.24/containers/51e14c432369325c6ebac0ca0c51460eb75a407242b8941eb7184fce4742d252?force=1&v=1

I do not have special characters in my password.

from for-win.

I am affected by this issue as well. I log into my machine with a domain account (username = "mtr932") and when I use that account's credentials to share the C: drive (specifying them in "domain\username" format) and then run the command in the "shared drives" dialog, I see this:

PS C:\Users\mtr932> docker run --rm -v c:/Users:/data alpine ls /data
mtr932

If I create a local administrator on the machine and use those credentials instead to share the C: drive, I see this instead:

PS C:\Users\mtr932> docker run --rm -v c:/Users:/data alpine ls /data
All Users
Default
Default User
Default.migrated
MSOLAP$SQLEXPRESS
MSSQL$SQLEXPRESS
Matthew
Public
defaultuser0
desktop.ini
mtr932

Obviously there is a lot of junk in there but the point is the local administrator account can see things that the domain account can't even though the domain account I use is in the local administrator group.

The domain account does have a non-alphanumeric character in its password but it is still an ASCII character. Because of my employer's password policy I can't create a password that only contains alphanumeric characters.

I would just stick with the local administrator account to share the C: drive except when I do so, I still cannot mount any files or folders within my domain user's account (C:\Users\mtr932):

PS C:\Users\mtr932> docker run --rm -v c:/Users/mtr932:/data alpine ls /data
PS C:\Users\mtr932>

If I share my C: drive using the domain account's credentials and run that same command I get this output:

PS C:\Users\mtr932> docker run --rm -v c:/Users/mtr932:/data alpine ls /data
Documents

Which is extremely strange because there are of course far more files and folders in C:\Users\mtr932 than just the Documents folder.

As a temporary workaround I will just put folders I want to volume mount in the root of C: but it would be ideal to be able to use the folders within my actual windows home directory.

I have tried setting "Unidentified networks" to "Private" as per this forum post but that did not help in my case.

Diagnostic id: FCAFD1CA-0D4C-4CB3-BE10-9C0731BB8E58/2016-08-08_16-47-24

from for-win.

@technivore Beta23 should support spaces, and pretty much any character from UTF-8 range (that was the fix mentioned in the changelog). So unfortunately, there still seems to be another issue.

There isn't anything strange happening in the sense, that the subdirectories are there as mountpoints from the previous volume share. So if you first to -v C:\:/tmp and it fails, then -v C:\Users:/tmp and it fails, and then again -v C:\:/tmp you'll see an empty Users directory in you container. Confusing....but normal, i think.

I had a look at your logs and see in the Linux VM:

Aug 17 14:27:55 moby kern.notice kernel: Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
Aug 17 14:27:55 moby kern.err kernel: CIFS VFS: Send error in SessSetup = -13
Aug 17 14:27:55 moby kern.err kernel: CIFS VFS: cifs_mount failed w/return code = -13

do you maybe have non-default authentication, like kerberos, enabled?

from for-win.

@rneugeba I don't know of any non-default authentication set up on my system. File and printer sharing is enabled for private networks but other than that I don't know what to look for. I'm on Win10 enterprise and joined to a domain. Please let me know what I can do to help troubleshoot; I really want to get this working and not have to go back to Docker Toolbox!

from for-win.

@technivore thanks for getting back. domains users is one of the things we don't test regularly as we don't have AD setup (we do now test with strange passwords, live accounts etc). Look like I have to bite the bullet and set up AD somewhere soon.

from for-win.

@rneugeba According to the mount.cifs man page there is a separate domain argument. Maybe the sharing credentials form needs to prompt for the (optional) domain or at least parse it out of the username input (if specified as domain\username or username@domain) and specify it in the mount command?

from for-win.

@technivore we do parse and handle the domain and username part and pass it to the CIFS mount. Also, AFAIK, we have user with domain accounts where it is working.

from for-win.

Another update: I explicitly granted full access for the local administrator user to my domain account's home directory (C:\Users\mtr932), rather than just relying on the fact that the local administrators group should have had full access. And now it works -- using local administrator credentials (in machine-name\username format), and explicitly granting that user full access to my user directory, I can now mount volumes within my user directory and see them within the container.

from for-win.

Hi Mathew, thanks for the info. Glad that you got unblocked. I'll close this issue for now, but update our internal tracking issue for AD users with the info you provided. We certainly should provided a smoother experience for these scenarios.

from for-win.

re-opening as i just realised that there are a whole bunch of other users with different issues on this issue.

from for-win.

@ProCynic great! thanks for reporting back

from for-win.

@IhorSyerkov tried that... still not sharing the volume. It allows the user and password, and docker says running... but any attempt to mount a folder with -v does not show the contents of the folder in the container still.

EDIT1: OH and FYI, this all started happening after the Windows 10 Anniversary Update
EDIT2: It seems to work if i specify the full path "/c/foo/bar instead of a relative path "./bar" .... like I said, this worked just fine before the Anniversary update.

from for-win.

@UTGuy A couple of questions/comments.

• The first paths in -v have to be absolute (as per https://docs.docker.com/engine/reference/run/#volume-shared-filesystems)
• which shell are you using? It looks like it might be git-bash or similar since you quote /c/foo/bar.
• can you try, in powershell, the sample command listed in the UI: docker run --rm -v c:/Users:/data alpine ls /data?
  thanks

from for-win.

@IhorSyerkov actually it's \ not /, so the for domain users the format is domain\username

from for-win.

@rneugeba Eventually I got it working by uninstalling and reinstalling docker. Shared the C drive using "Domain\Username".

It was probably something that the Anniversary update overwrote somewhere.... thats my only guess.

On a side note...
Relative pathing works using Docker-compose -volumes (e.g. ./foo:/home/foo).
it seems like relative pathing should also work with docker run -v.

from for-win.

Samsies

Update: tried changing password (removed special characters), but it did not fix my problem.

Update 2: Another thing I can't figure out and I think it is related is that with the docker-toolbox I could use and from there I was able to login and pull my image into my vm. I am unable to ssh into MobyLinuxVM. Also when I pull up the vm through the Hyper-V Manager it just shows a black screen, so I can't even do anything from there. Should I just use a docker-compose file instead of trying to mount?

diagnostic id: 1A1304D4-EA05-47A9-88C8-55DB45E9BA2E/2016-08-09_12-59-31

Update3: I installed beta 23 and it is still not working for me. I am on a domain computer

diagnostic id: D91B0EBA-383B-4CC3-9C6F-FA4C02EE6D81/2016-08-17_12-26-28

Update4: It still is not working even with [domain][username] as login or [computer name].[domain][username]

Not sure if it helps to know or not but I use vpn cisco anyconnect v 3 client as well.

diagnostic id: D91B0EBA-383B-4CC3-9C6F-FA4C02EE6D81/2016-08-19_11-53-10

Update5: I am working on an older DELL Latitude. I have upgraded it to Windows 10, but it looks like the machine isn't supported by Windows 10. It runs fine, but I have noticed it doesn't seem to like my CD/DVD drive. Could this be having an adverse affect on mounting the mobylinux.iso?

from for-win.

@UTGuy thanks for reporting back. Yes, it looks like the Anniversary update has caused quite a few issues...

from for-win.

@johnrb2 it looks like you entered the username in an interesting way. You seem to have tried combination of johnrb2/foo.bar, machine.foo.local\johnrb2, johnrb2/foo.local, foo.local\johnrb2, and machine.foo.local\johnrb2. Judging by the log files, you domain is FOO.
Could you try FOO\johnrb2 (obviously i annonymised this a little...)
thanks

from for-win.

@rneugeba I tried and it didn't work. Thank you for the suggestion.

D91B0EBA-383B-4CC3-9C6F-FA4C02EE6D81/2016-08-25_17-35-02

from for-win.

@johnrb2 thanks for getting back. There is a little too much noise in the diagnostics. Could you:

• reset credentials (in the shared drive settings)
• quit the app
• on an elevated shell: net share C /delete
• start the app
• share drive with FOO\johnrb2
• execute: docker run --rm -v c:/Users:/data alpine ls /data

If this fails, generate another diagnostics report and report the ID.

Thanks again

from for-win.

@rneugeba Here is what I got.

D91B0EBA-383B-4CC3-9C6F-FA4C02EE6D81/2016-08-25_18-58-10

from for-win.

@johnrb2 thanks for the quick return. On the Linux side I see:

Aug 26 00:57:42 moby kern.err kernel: CIFS VFS: Error connecting to socket. Aborting operation.
Aug 26 00:57:42 moby kern.err kernel: CIFS VFS: cifs_mount failed w/return code = -115

Do you know if there is any third party firewall or virus scanning software on your host?

from for-win.

@rneugeba I am running Sophos Endpoint Security and Control. It is a work computer. Not sure how to adjust the settings. Thank you for your help. I have reached out to see if I can get the settings adjusted. I am calling it a night. Cheers!

from for-win.

@rneugeba What about an issue with special characters in the computer name (just a guess here). A lot of companies the one I work at included use some special naming convention for the computers. As there seem to have been an issue with the special characters in the password...could there be a similar issue here?
I can't test it out my self - when the computer is on the domain I need domain admin credentials to play around with the name....(My laptop that's not joined to the domain and does not comply with company policy for computer naming works...)

from for-win.

@ChristianPejrup that issue was fixed with Beta23 and @johnrb2 is on Beta24

from for-win.

@rneugeba i do realize that it has been fixed for passwords (https://docs.docker.com/docker-for-windows/release-notes/) but mount happens as a network share - could there be a problem with having something like "-" in the computer name when setting up the network share?

from for-win.

@ChristianPejrup no, this shouldn't be a problem as the computer name is not used. We use the internal switch for SMB mounting and just use the IP address.

from for-win.

@rneugeba I disabled the third party software and attempted it again and it still didn't work for me. I disable it via the application and the services so it was just running with Windows Defender on.

D91B0EBA-383B-4CC3-9C6F-FA4C02EE6D81/2016-08-26_16-14-23

Are you still seeing the same thing?

from for-win.

982D3056-7F02-499D-9D7C-EF0A998E78AF/2016-08-28_19-21-28

I think I'am having same problem. Already uninstalled and re-installed docker.
Docker cannot seem to see objects beyond /c/Users/username

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

docker run --rm -v c:/Users/ken:/data alpine ls /data
_empty_

I only have windows defender and password is only alphanumeric

Edit:

Problem solved itself in insider build 14915

from for-win.

I have the same problem. I found that if I create a local user account and log in with that account the issue is resolved, but if I log in with a Windows Domain account the problem exists. My Windows Domain user is a Domain Administrator and a local Administrator and my local user is a local Administrator - so this is not a file permissions issue.

Diagnostic ID when logged in under Windows Domain account:
9AD6B421-31D3-4F5E-8E7F-EA006C78C557/2016-09-05_09-54-13

Diagnostic ID when logged in as local account:
02059261-750C-4750-B8BB-841DFAAA6758/2016-09-05_10-00-19

TO REPLICATE (not working scenario):

Log in as domain user (with administrator access):

File system structure:

D:
D:\M3
D:\M3\hello.txt

All files/folders have been granted "Everyone" full access.

Running this:

docker run --rm -v D:/:/data alpine ls /data

Listing produced:

M3

Running this:

docker run --rm -v D:/M3:/data alpine ls /data

Listing produced:

nothing

Running this:

docker run --rm -v D:/M3:/data alpine touch /data/another.txt

Then this:

docker run --rm -v D:/M3:/data alpine ls /data

Listing produced:

another.txt

Also, windows does not see "another.txt" in D:\M3

Diagnostic ID when logged in under domain account:
9AD6B421-31D3-4F5E-8E7F-EA006C78C557/2016-09-05_09-43-31

TO REPLICATE (working scenario):

Log in as local user (with administrator access):

docker run --rm -v D:/M3:/data alpine ls /data

Listing produced: hello.txt

from for-win.

@codingkeith the symptoms you report are in line with what I would expect when the CIFS mount in the VM fails. Something like docker run --rm -v c:/Users:/data alpine ls /data should show up empty.

How do you enter the domain account? It should work with domain\user but probably not with user@domain. Also, the 1.12.0-stable version you are using has an issue with a lot of special characters in the password which are fixed on the Beta channel. You could try Beta24 from https://download.docker.com/win/beta/InstallDocker.msi

from for-win.

@rneugeba I did try with the Beta24 just to make sure it wasn't already fixed, but the problem was the same.

I am entering my domain user as DOMAIN\FIRST LAST (with a space between first name and last name). I can try other styles if you want, I am a domain admin so am free to experiment.

from for-win.

@johnrb2 thanks for checking and turning the 3rd party software off. Yes, I still see:

Aug 26 22:13:21 moby kern.err kernel: CIFS VFS: Error connecting to socket. Aborting operation.
Aug 26 22:13:21 moby kern.err kernel: CIFS VFS: cifs_mount failed w/return code = -115

in your latest diagnostics.

I'm currently leaning towards this potentially being an issue with the firewall. Could you try a few more things?

First, open Windows Firewall with Advanced Security. Cortana should be able to help you with that.... Under Inbound rules can you sort the possibly long list by Local Port and see if there are any active rules for port TCP 445? This is used for SMB/CIFS mount.

Second, check if the VM can connect to the host on port 445. For this you need two powershell windows, PS1 and PS2. In PS1, type:

docker run --rm -it --privileged --pid=host debian nsenter -t 1 -m -n sh

this enters into the VM (via a container). The on the prompt type the following commands:

apk update
apk add tcpdump
tcpdump -i eth0

This starts a packet capture on the network interface used for CIFS mounting.

Now, in the second Powershell windows (PS2):

docker run --rm -it --privileged --pid=host debian nsenter -t 1 -m -n sh
nc -w 2 10.0.75.1 445

This also gets you a shell in the VM, and then we use the nc utility trying to connect to the SMB server on the host. The -w 2 sets a time out for 2 seconds. If this exits, the VM can't connect to the host.

While the nc -w 2 10.0.75.1 445 command executes in PS2, you should see some output in PS1. I'd be interested in the output.

Thanks again for your help

from for-win.

@rneugeba usingnet share c I was able to see that the local user was set up to access the drive rather than the domain user. After un-sharing the drive and resetting credentials and re-sharing it has worked on the stable release with my domain account - thanks.

from for-win.

@rneugeba I am actually out of town and won't be able to try your suggestion out until the middle of December, but I will try it thanks! Sorry for the delay.

from for-win.

@rneugeba Hi - I finally solved my problem (the broadsword solution) there is something funky about supplying a domain account when mapping a drive on the local computer.

Problem
I think the domain part of the credentials are not translated/handled correctly when mounting the C drive from the Linux host running docker.
I'm expecting this is because domain is not included in the mapping request or not correctly interpreted by the host machines os - which will cause the account to register as a local user on the windows machine.

Not working attempt at solving the issue
(I have attempted to add a "dockerservice" account before with local access to the computer but with out any success. In some cases docker stopped working completely...

My solution/workaround
Adding a user with same name and credentials as my domain account locally did the job (there is some logic in windows/ad which means that an account with the same name and credentials as a domain account will build the same authentication token - I don't know if that's playing in here).
I have verified this works on multiple other computers with other domain credentials.

from for-win.

@dreamflasher Good to know that it works for you!

If I read the history correctly, it seems that the issue is fixed for everybody so I'm going to close the ticket. Feel free to reopen a new one if it still occurs.

from for-win.

@dreamflasher I'd suggest a checkbox for "current user" instead. But I love the idea of pointing out that you must enter the domain and username as you pointed out. That actually had me chasing my tail last week.

from for-win.

@rneugeba and @dreamflasher , I'm working with johnrb2 on this issue. I'm running Docker version 1.12.0, and I entered the following in Powershell like @dreamflasher suggested: docker run --rm -v c:/Users:/data alpine ls /data. The data folder comes back empty for me.

from for-win.

@stuft2 Did you make sure to enter the exact correct domain\user as username in credentials?

from for-win.

@dreamflasher I did login with the correct domain\user. I'm going to try the steps that @rneugeba suggested to johnbr2 4 days ago. Then I'll leave an update.

from for-win.

@rneugeba I did the the two shell and docker commands with nc -w and PS1 printed out the following:

16:48:32.735308 IP 10.0.75.2.40198 > 10.0.75.1.445: Flags [S], seq 1412172603, win 29200, options [mss 1460,sackOK,TS val 500036 ecr 0,nop,wscale 7], length 0
16:48:33.735327 IP 10.0.75.2.40198 > 10.0.75.1.445: Flags [S], seq 1412172603, win 29200, options [mss 1460,sackOK,TS val 500136 ecr 0,nop,wscale 7], length 0
16:48:37.745248 ARP, Request who-has 10.0.75.1 tell 10.0.75.2, length 28
16:48:37.745755 ARP, Reply 10.0.75.1 is-at 00:15:5d:0b:58:01 (oui Unknown), length 28

There is an inbound rule on Local Port: 445

Name: SMB over TCP   Group: File and Printer Sharing   Profile: Private, Public   Enable: Yes   Action: Block   Override: No   Program: Any   Local Address: Any   Remote Address: Any   Protocol: TCP   Local Port: 445   Remote Port: Any   Authorized Users: Any   Authorized Computers: Any   Authorized Local Principals: Any   Local User Owner: Any   Application Package: Any

from for-win.

fyi, @rneugeba I'm working on adding this to the FAQs and will re-publish later
today. It's just taking me a little longer to figure this one out.

On Mon, Sep 5, 2016 at 8:28 AM, Rolf Neugebauer [email protected]
wrote:

@codingkeith https://github.com/codingkeith excellent. Glad that it
worked for you. As said the multiple user scenario is not very smooth at
the moment, but we also don't want to unconditionally unshare the drive
either in case the user uses it for something else.

@londoncalling https://github.com/londoncalling maybe we could add
something to the FAQ. something along the line of this #25 (comment)
#25 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#25 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALHuA47IxGRXfF8RelQqf4uz_psbLjIVks5qnDU3gaJpZM4JdgBF
.

from for-win.

Any updates... still having issues here.

from for-win.

@stuft2 sorry, I was on PTO and thanks for providing the information.

It looks like your firewall is blocking SMB/CIFS, though, I'm a little surprised not to see the initial syn packet on the TCP dump.

can you disable the rule, by any chance?

from for-win.

re-opening as this is not yet fixed in shipping version, but hopefully will be fixed/improved in Beta27

from for-win.

@rneugeba I uninstalled the previous stable version of Docker for Windows and then installed the latest beta version. I haven't been able to disable the inbound rule for port 445. I'm still not getting the expected output in PowerShell.

C:\Users\stuft2> docker run --rm -v c:/Users:/data alpine ls /data
C:\Users\stuft2> docker --version
Docker version 1.12.1, build 23cf638, experimental

from for-win.

Just a note that unchecking the "Remember my credentials" box when sharing a drive causes the sharing to fail with no explanation even if the credentials are correct (the popup just comes back empty) so I'm not sure why it's even there as this has caused me a lot of confusion :P

from for-win.

@stuft2 is your firewall managed by some corporate policy, or what's the reason you can't disable the rule?

from for-win.

Currently it's managed by my company but I'm looking into disabling it.

from for-win.

Once I disabled the Windows Firewall, I then reinstalled Docker and shared the C drive. Then I ran the follow code in PowerShell and command prompt:
docker run --rm -v c:/Users:/data alpine ls /data

from for-win.

Working with latest drop (1.12.2-rc1-beta27 - build 7450). I set up a share of my 2nd drive (D), and the mapping worked fine. I then connected to VPN to our company network, and got a failure:

PS C:\Users\pekj> docker run --rm -v d:\git-magestic:/data alpine ls /data
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: mkdir /d: file exists.

I went into settings, reset credentials, and then tried to share the drive again. It (eventually) prompted for my credentials, and when I clicked OK, it waited a while, then eventually came back with the checkbox on the drive cleared.

docker_log.txt

from for-win.

@rneugeba can you keep me up-to-date with whether we need more docs for this? What I've done is in this PR: https://github.com/docker/pinata/pull/5125 and published here: Shared Drives UI description and more importantly here in Troubleshooting: Verify domain user has permissions for shared drives (volumes)

Also, please review my questions in that PR.

from for-win.

Thank you all for your feedback. I'm going to close this issue as a duplicate of #114

The major remaining roadbock to sharing a drive is firewalls. All other issues (password escaping, domain names...) look like they have been fixed.

from for-win.

All works in Beta28! Thanks :D

from for-win.

Figured out the issue we were having. I'm not so sure it was the firewall after all. Docker didn't like the image of Windows 10 that my company was using. After re-imaging my computer to a standard Windows image, Docker ran successfully. Also, I couldn't be on the company domain to be able to share the C drive. Thanks for the help!

from for-win.

@Kantis 1.12.3 was already released

from for-win.

Some VPN's are configured to block access to local network and/or local VMs which includes Moby Linux.

Random question, is there a CLI way to open the "Shared Drives dialog" and prompt the user to update their password to get samba sharing working again?

from for-win.

Thanks for the reply. That would be outside the docker UI so a little confusing.

I'm just thinking a command I can tack on to the end of a PowerShell script we have to update IIS apppool credentials when people have to change their password every 3 months. But ideally just leverage the existing UX because your team does a great job at making shares work without any knowledge of the samba share hackery required to make it all work.

from for-win.

@kcd83 Sorry for not getting back sooner. I see what you are saying. Someone should be able to address this, maybe @tiborvass @thaJeztah @crosbymichael ?

from for-win.

@londoncalling I guess this is more an enhancement for Docker for Desktop (but not too familiar in that area); @gtardif ?

from for-win.

... so if the same cli could also check if the current samba creds were still valid that would be awesome. But harder.

from for-win.

This issue can appear using a domain attached account when unplugged from the company network before starting docker.

• In case a domain account is already downloaded on the pc and the pc is not connected to the company network, giving this account credentials to share a drive seems to work but the drive appear empty.

• This error can appear again if you plug a new device while the pc is disconnected from the company network. Then you have to disconnect this new device and plug the network before connect it again.

• Having the company network available at all time or at least when docker start and when docker (re)mount drives solve the issue.

Having a local user should have fixed the issue but it's not possible on this pc because of the company security policy.

from for-win.

FWIW, In my experience with WSL/Docker, this happens to me when a folder exists in my src (copied in to workdir with COPY), and then I try to mount a volume to a folder that then exists in the container storage.

from for-win.

seems this doesn't work using ubuntu + bash for windows 10

from for-win.

Hi @lucasbasquerotto Thank you for your comment, the entire partition works for me, but my problem was that my folder is empty when mounted. This seems like a problem that lots of people share.

from for-win.

I’m having exact same issue as mentioned by @DungLai above.

I’m using Windows 10 Home with Docker Toolbox.

After mounting, container’s directory is empty (actually, for some weird reason it only shows my package.json file)

Also looking for a way to reset credentials in Docker Toolbox...

from for-win.