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;
- 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/rstudioto some folder inUsersfrom 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.
- I created a brand new user (with no spaces or special characters) with alpha numeric password
- I restarted the machine.
- start docker
- using docker icon in taskbar, share C drive
- 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 …
I also had a bad time to get sharing to work.
In my case I wanted to get VS2015 to be able to set breakpoints into ASP.NET code running in a container (which requires volume sharing). Took some time to reach the conclusion that the reason why VS2015 was failing to start the contained in debug mode was due to volume sharing problems.
I have observed all kinds of weird behavior:
.Being able to see just directories inside the container (the entire tree) but no files
.Being able to touch a file inside the container but not being able to see it in the host
The credentials that I was using included a password with a special character.
Eliminating the special character from the password solved all volume sharing problems.
1 Like
In case any of the posters should have resolved the issue, it would be nice if you could put some feedback in here.
For me and others, the current state is (please correct/confirm)
- Directories on the host can sometimes be seen, but under strange circumstances
- Files cannot be seen
(for me: no special characters in password, no domain)
+1
I can’t mount directories with a docker compose
I had the same Problem, but after changing my password the error disappeared. It’s seems there is a problem when password contains a dollar sign ‘$’.