Boot2docker: Unable to mount host volume to externalize data using Windows

[mpas]

I am trying to mount a host volume to a Docker container for MongoDB. The Dockerfile contains the following.

# Create the MongoDB data directory
RUN mkdir -p /data/db
# Identify mount point
VOLUME /data/db

--> The docker image has a name called mongo.

But when i try to start the image and mount a local Windows folder using:

docker run -d -v /c/Users/310145787/Desktop/mongo:/data/db mongo

I get an error message saying:

invalid value "c:\Users\310145787\Desktop\mongo;C:\Program Files (x86)\Git\data\db" for flag -v: \Users\310145787\Desktop\mongo;C:\Program Files (x86)\Git\data\db is not an absolute path

I checked with boot2docker ssh if the path is accessible and it seems ok.
docker@boot2docker:/c/Users/310145787/Desktop/mongo

Using Boot2Docker 1.6.0

[imwithye]

I have the same problem. I guess the root directory / does not actually exist in the Git bash environment. Insead, it refers to the Git Home directory which has usr, etc and bin so on. So if any path start with the root path /, it will be translated to the relative path to the Git Home.

But still have no idea how to fix it.

[kdemarest]

The current work-around seems to be to create a docker volume, and then share that between docker and your native OS. Here is where I found that solution:
https://github.com/boot2docker/boot2docker/blob/master/README.md

Having said that, I'd really like to just be able to -v /c/path:/someplace

[imwithye]

That's ture. I can also use boot2docker ssh to login the VM and then mount the disk to docker. But, eh, I also like to just be able to -v /c/path:/someplace.

It seems it is a bug of Git Bash. Does anyone tried boot2docker under cygwin? Is that possible to mount the disk? Git Bash will translate all / path to it's installation path so that all unix tool can be used inside the env. Eh, but it is really...not that good.

[mpas]

I was pointed out to a work around in issue https://github.com/docker/docker/issues/12590 using a double slash seems to work. I checked it locally and it works.

docker run -d -v //c/Users/marco/Desktop/data:/data <image name>

Using the double slash the host volume is mounted correctly

[imwithye]

@mpas Nice! it also works with docker run -v /$(pwd):/data

[dmenne]

@imwithye $pwd: Even better! Thanks for sharing, having to use a static name was another nuisance in the syntax.

[exhuma]

This does not seem to work for an interactive session (using winpty). Any ideas?

[vinaydate]

//c/Users/... worked in my case as well.
OS: Window 10

[sunhaolin]

docker run -p 88:80 -it -v //g/test.conf:/etc/nginx/conf.d/test.conf --name nginxtest nginx
it is not work, because "conf.d" , i dont known how to fix it, help!
OS:windows 10

[thaJeztah]

@sunhaolin note that by default, only the c:\users directory is shared with the boot2docker virtual machine, any other directory is not shared with the VM by default, so doesn't exist inside the VM. See the README.md for more information

[danielo515]

Hello @thaJeztah

I'm not sure I understand what you mean. So, only subdirectories of C:\Users are shared with boot2docker? Despite what you specify using -v? For example, if I run:

docker run -v //h:/data -w /data --rm -it node bash

I can only see directories under the path from where I have launched that command, and no files inside it. This means that, inside the docker container I can navigate to /data/some/folder if I have launched the command from /h/some/folder. Is that the intended behavior?

Regards

[thaJeztah]

@danielo515 correct; you need to understand that the -v /some/path:/container/path option mounts /some/path from the host that the docker _daemon_ runs on. When using boot2docker, that host is the Virtual Machine. Your c:\ and h:\ drive are on your Windows host, not in the Virtual Machine, so when mounting those, the docker daemon creates an empty directory (because the path you're mounting doesn't exist), and mounts that inside the container; as a result, you get an empty directory mounted in the container.

Because you sometimes want to mount files from the Windows host inside a container, boot2docker uses a "trick"; the c:\Users directory is mounted inside the Virtual Machine (at the /c/Users directory) using "VirtualBox guest additions". So when you use -v c:\Users\something:/container/path, you're actually bind-mounting /c/Users/something from the Virtual Machine. That path happens to be mounted from the Windows machine into the Virtual Machine, so you'll see your Windows files there.

It's a bit complicated, so, hope it's clear what's happening :smile:

[danielo515]

Hello @thaJeztah
Thank you very much for your promt and detailed response

It sounds a bit twisted, but hey, every workaround is. From your description I understand that theorically I could use virtual box addons to make another folder visible to the virtual machine and be able to mount them. But I'm not sure if that will work with the -v parameter.

[thaJeztah]

@danielo515 yes, you can add additional paths, but that has to be done manually, some instructions can be found here; https://github.com/boot2docker/boot2docker/#virtualbox-guest-additions

Also, you may be interested in the Docker for Windows beta; https://beta.docker.com

[yuval-mntr]

https://forums.docker.com/t/volume-mounts-in-windows-does-not-work/10693/71

[loudermilk]

@thaJeztah thanks for explanation. Interesting - while running Windows 10, it appears that mounting a directory this way actually creates a copy of the directory and contents. After running a container, if I change the contents of a file or directory on my local machine it is not reflected in the container. Is this correct, expected behavior?

[thaJeztah]

If, for some reason, you're mounting a volume, not a bind-mounted directory, then the contents of the container image is copied to the volume on first use (if the volume is empty). If you're running boot2docker / Docker ToolBox, syncing should be handled by VirtualBox sharing (if properly configured); not sure what could case syncing to not work with the current information.