Volume mounts in windows does not work

thanks for the quick reply…next step would be to poke around in the VM a little. If you have time, it would be great if you could run:

docker run -it --privileged --pid=host debian nsenter -t 1 -m -n mount
and
docker run -it --privileged --pid=host debian nsenter -t 1 -m -n tail -50 /var/log/messages

preferably, after you have disabled sharing, reset credentials and the re-shared the drive.

Thanks in advance
Rolf

I’m experiencing the same problems as others.

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

is returning

[quote]tmpfs on / type tmpfs (rw,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) tmpfs on /run type tmpfs (rw,nodev,relatime,size=204760k,mode=755) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime) dev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=249827,mode=755) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime) cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755) openrc on /sys/fs/cgroup/openrc type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/rc/sh/cgroup-release-agent.sh,name=openrc) cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cpu on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu) cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct) blkio on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) memory on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) devices on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) freezer on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) net_cls on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) perf_event on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) net_prio on /sys/fs/cgroup/net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio) hugetlb on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) pids on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime) /dev/sda2 on /var type ext4 (rw,relatime,data=ordered) /dev/sda2 on /var/lib/docker/aufs type ext4 (rw,relatime,data=ordered) none on /var/lib/docker/aufs/mnt/742172f1a9e0e8472078de72c871c8059750acbcddc02188c6592244724bc4b1 type aufs (rw,relatime,si=a46c07623ae34520,dio,dirperm1) shm on /var/lib/docker/containers/4402900b5c795e0d7bcda9e2bc180c41e63ce81fd48021237b6e827e076c1e7f/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k) nsfs on /run/docker/netns/d351533f4c30 type nsfs (rw)[/quote]

and

docker run -it --privileged --pid=host debian nsenter -t 1 -m -n tail -50 /var/log/messages

[quote]May 7 08:02:46 docker kern.info kernel: device veth6004ef4 left promiscuous mode May 7 08:02:46 docker kern.info kernel: docker0: port 1(veth6004ef4) entered disabled state May 7 08:02:46 docker kern.info kernel: docker0: port 1(veth6004ef4) entered disabled state May 7 08:02:55 docker user.info KVP: umount: /C and /c May 7 08:02:55 docker user.err KVP: umount: error: 2 No such file or directory May 7 08:02:55 docker user.info KVP: mount: cifs //10.0.75.1/C to /C and /c May 7 08:02:55 docker user.err KVP: mount: error: 2 No such file or directory May 7 08:02:55 docker kern.notice kernel: Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE May 7 08:02:55 docker kern.err kernel: CIFS VFS: Send error in SessSetup = -13 May 7 08:02:55 docker kern.err kernel: CIFS VFS: cifs_mount failed w/return code = -13 May 7 08:02:55 docker user.info KVP: umount: /D and /d May 7 08:02:55 docker user.err KVP: umount: error: 2 No such file or directory May 7 08:02:55 docker user.info KVP: umount: /F and /f May 7 08:02:55 docker user.err KVP: umount: error: 2 No such file or directory May 7 08:03:09 docker user.info KVP: umount: /C and /c May 7 08:03:09 docker user.err KVP: umount: error: 2 No such file or directory May 7 08:03:10 docker user.info KVP: umount: /D and /d May 7 08:03:10 docker user.err KVP: umount: error: 2 No such file or directory May 7 08:03:10 docker user.info KVP: umount: /F and /f May 7 08:03:10 docker user.err KVP: umount: error: 2 No such file or directory May 7 08:03:20 docker user.info KVP: umount: /C and /c May 7 08:03:20 docker user.err KVP: umount: error: 2 No such file or directory May 7 08:03:20 docker user.info KVP: mount: cifs //10.0.75.1/C to /C and /c May 7 08:03:20 docker user.err KVP: mount: error: 2 No such file or directory May 7 08:03:20 docker kern.notice kernel: Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE May 7 08:03:20 docker kern.err kernel: CIFS VFS: Send error in SessSetup = -13 May 7 08:03:20 docker kern.err kernel: CIFS VFS: cifs_mount failed w/return code = -13 May 7 08:03:20 docker user.info KVP: umount: /D and /d May 7 08:03:20 docker user.err KVP: umount: error: 2 No such file or directory May 7 08:03:21 docker user.info KVP: umount: /F and /f May 7 08:03:21 docker user.err KVP: umount: error: 2 No such file or directory May 7 08:03:30 docker kern.info kernel: device veth641ec63 entered promiscuous mode May 7 08:03:30 docker kern.info kernel: IPv6: ADDRCONF(NETDEV_UP): veth641ec63: link is not ready May 7 08:03:30 docker kern.info kernel: IPVS: Creating netns size=1328 id=4 May 7 08:03:30 docker kern.info kernel: eth0: renamed from veth828ee12 May 7 08:03:30 docker kern.info kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth641ec63: link becomes ready May 7 08:03:30 docker kern.info kernel: docker0: port 1(veth641ec63) entered forwarding state May 7 08:03:30 docker kern.info kernel: docker0: port 1(veth641ec63) entered forwarding state May 7 08:03:30 docker kern.info kernel: veth828ee12: renamed from eth0 May 7 08:03:30 docker kern.info kernel: docker0: port 1(veth641ec63) entered disabled state May 7 08:03:30 docker kern.info kernel: docker0: port 1(veth641ec63) entered disabled state May 7 08:03:30 docker kern.info kernel: device veth641ec63 left promiscuous mode May 7 08:03:30 docker kern.info kernel: docker0: port 1(veth641ec63) entered disabled state May 7 08:06:18 docker kern.info kernel: device veth6b7d5f7 entered promiscuous mode May 7 08:06:18 docker kern.info kernel: IPv6: ADDRCONF(NETDEV_UP): veth6b7d5f7: link is not ready May 7 08:06:18 docker kern.info kernel: IPVS: Creating netns size=1328 id=5 May 7 08:06:18 docker kern.info kernel: eth0: renamed from vethc9f5370 May 7 08:06:18 docker kern.info kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth6b7d5f7: link becomes ready May 7 08:06:18 docker kern.info kernel: docker0: port 1(veth6b7d5f7) entered forwarding state May 7 08:06:18 docker kern.info kernel: docker0: port 1(veth6b7d5f7) entered forwarding state[/quote]

Mounting started working after I’ve changed my user password. Before the change it contained some unicode characters (russian letters). Seems that changing it to plain English fixed this problem for me.

1 Like

Changing my domain password fixed it! Yay, I’m back in business.

I can get a volume mounted in the container, but none of the files in the host directory show up–it’s empty.

Suggestions?

how about from inside the container, cd to the mount point, and if you were to create a file, say

# cd to the mount point, then
touch thisIsANewFile.txt

does the file appear in the host directory.?

If not, perhaps doing a docker inspect on the container to review the mounts points.

After doing quite a few tests, I have come to the conclusion that my docker containers are writing changes into persistent storage on the hyper-v VM instead of a share with windows. Files/folders will persist between different vm sessions but in no way show up on my windows hard drive.

Try this out and see if anyone experiences the same as me:

docker run --rm -v C:/:/data alpine ls /data/
docker run --rm -v C:/:/data alpine touch /data/foo.bar
docker run --rm -v C:/:/data alpine ls /data/
    foo.bar

Also of interest (after reset to defaults and re-share C):

docker run --rm -v /home/..:/data alpine ls /data/
    C
    Mac
    bin
    c
    dev
    etc
    home
    init
    lib
    linuxrc
    media
    port
    proc
    root
    run
    sbin
    sys
    tmp
    usr
    var
docker run --rm -v /home/..:/data alpine ls /data/C
docker run --rm -v /home/..:/data alpine ls /data/c
3 Likes

Nope, nothing appears in the host directory. BTW, when I tried this again
today, the first couple of times it appeared to work, and the host files
were visible from within the container. As soon as I tried to copy one of
them to another directory in the container, however, I got a "host is down"
error, and it’s back to where it was (or worse, since these "host is down"
errors now seem to be popping up more often).

On Windows, you can try:

  • Create a local user named “dockeruser” (or anything else)
  • Add this user to a group with sufficient rights on the drive to be shared (for instance, administrators)
  • Use the docker “Manage shared drives” option and
    ** If you have any credentials there, reset them first and un-share the previously shared drives
    ** Re-share your drive(s) –
    ** When prompted for the credentials, use

10.0.75.1\dockeruser

  • Run the container using

docker run -it -v C:/:/data alpine sh

  • Inside the container, verify if the host files are acessible under /data using

cd /data
ls

How to debug:

  • Inside the container, use the command “mount” and verify that you have a line such as:

//10.0.75.1/C on /app type cifs (rw,relatime,vers=1.0,cache=strict,username=dockeruser,domain=10.0.75.1,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.75.1,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,noperm,rsize=61440,wsize=65536,actimeo=1)

  • On the Windows host, right click on the drive being shared and double check if the user “dockeruser” has full access on the share, by using “Sharing tab/Advanced Sharing/Permissions”
  • On the Windows host, double check if the user “dockeruser” has permissions to access the files on the shared drive (for instance, login as that user, or use “runas /user:dockeruser explorer.exe” and try to browse the drive)
  • For more information, read the blog post http://docker-saigon.github.io/post/Docker-Beta/

This solution is working on
Windows 10.0.10586 Build 10586
Docker version 1.11.1, build 5604cbe

1 Like

WOOT! This has been fixed with the latest update!

PS C:\Users> docker run --rm -v c:/:/data alpine ls /data/
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine

d0ca440e8637: Pull complete
Digest: sha256:f655166f57d91bdfc8b3bc75a20391b7516de9f48ca761249c185fcb022124d2
Status: Downloaded newer image for alpine:latest
$RECYCLE.BIN
$SysReset
Documents and Settings
HashiCorp
Intel
OneDriveTemp
PerfLogs
Program Files
Program Files (x86)
ProgramData
Recovery
Recovery.txt
System Volume Information
Users
Windows
hiberfil.sys
pagefile.sys
swapfile.sys
tools
windows-version.txt

What version did you have for testing? Still now output for me with 1.11.1.

Right click on your docker icon in the tray and click “About Docker…”

The version that I am showing is:

Version 1.11.1-beta11 (build: 2789) b0bc231

You could also try doing the same thing and clicking “Check for Updates…”

Same build for me, but no output with

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

Same here, still no access to my files…

Mapping somehow works, but the behavior looks strange;

  1. Start Docker for Windows.
  • Make sure C: is mapped/checked
  • docker run --rm -v c:/:/data alpine ls -R /data/ (nothing)
  • Start some container with mapping under Kitematic; I used hadleyverse, but others did similarly
  • Map home/rstudio to some folder in Users from Kitematic
  • You can immediately stop the container after that
  • Use the above from 3.) : You can see the full path of the (stopped!) hadleyverse

(After reading your comment): No active directory involved, just stand-alone laptop

Added later: 2.) is not necessary. Same sequence with C: unchecked. Looks like kitematic does the mapping old style, but why is the mapping conserved after shutdown of one container? Make me think of a serious security issue.

Have we made some progress? I have the same strange behaviour. and still can’t access the files in fact, I can only list the directory which was shared

After update to Beta 12: no change on the subject of volumes; it’s not mentioned in the readme, so probably nothing has changed here.

Containers start, but no connection to web-based service possible (tested with hadleyverse, nginx, and my own containers) that had worked under VM and partially, without the mapping, on Beta 11

This is what I am seeing. I have upgraded to Beta 12. I also shared C drive from docker settings as described here

Now I am able to see “Users” folder, but nothing else. This is very weird. Here is my session log
PS C:> dir data

Directory: C:\data

Mode LastWriteTime Length Name


-a---- 5/19/2016 11:49 AM 18 testfile.txt

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

I have the same issue here. As far as I can tell :

Running these commands:
docker run --rm -v /E/m:/test ubuntu ls /test
[no output]
docker run -ti -v /F/Python:/test ubuntu ls /test
[no output]

Note that the “m” directory does not exist on my Windows 10 machine

Then:
docker run --rm -v /E:/test:rw ubuntu ls /test
m
docker run --rm -v /F:/test:rw ubuntu ls /test
Python

This is a strange behavior.

I tried disable then enable again the drives, no effect
My password has no foreign characters
I tried to change the credentials to docker-host-hostname\user, no effect.

for everyone’s benefit, I was able to resolve this partially ( I see all files, but only root has write permissions)
My admins had created a userid with space in it. I was getting very strange behavior, I tried changing password, at which point share drive authorization started failing completely.

  1. I created a brand new user (with no spaces or special characters) with alpha numeric password
  2. I restarted the machine.
  3. start docker
  4. using docker icon in taskbar, share C drive
  5. Use following command

C:>docker run --rm -v c:/data:/data alpine ls -lart /data
total 5
-rwxr-xr-x 1 root root 18 May 19 18:49 testfile.txt
drwxr-xr-x 2 root root 0 May 19 19:38 .
drwxr-xr-x 24 root root 4096 May 23 19:49 …