Compose: docker-compose Issue with Volumes based on Docker Machine Root (`/`)

[jamiejackson]

• Windows 7 host
• Boot2Docker version 1.10.3, build master : 625117e - Thu Mar 10 22:09:02 UTC 2016
• Docker version 1.10.3, build 20f81dd
• docker-compose version 1.6.2, build e80fc83
• docker-machine version 0.6.0, build e27fb87

I'm running docker-compose up -d with the following:

cadvisor:
  image: google/cadvisor
  ports:
    - "8080:8080"
  volumes:
    - "/:/rootfs:ro"
    - "/var/run:/var/run:rw"
    - "/sys:/sys:ro"
    - "/var/lib/docker/:/var/lib/docker:ro"

This yields:

C:\www\nmc_docker>docker-compose up -d
Recreating d3a4e7a0de45_d3a4e7a0de45_d3a4e7a0de45_d3a4e7a0de45_d3a4e7a0de45_d3a4e7a0de45_nmcdocker_cadvisor_1
←[31mERROR←[0m: Invalid volume spec "ro": volumeabs: Invalid volume destination path: 'ro' mount path must be absolute.

The equivalent docker run works from both Windows and in an SSH session in the docker machine.

I'm brand-new to docker-machine & docker-compose, so I might be doing something wrong.

[dnephin]

I think what's happening is that "/:/rootfs:ro" if confusing our parsing of windows paths.

If you're using docker-compose on windows, you should use host paths that contain c:\ or the appropriate drive. Can you try c:\:/rootfs:ro and see if that works?

If you're trying to point VM paths, I think you might need to run Compose from the VM.

[jamiejackson]

If you're using docker-compose on windows, you should use host paths that contain c:\ or the appropriate drive. Can you try c::/rootfs:ro and see if that works?

I think that's incorrect. On Windows and Mac hosts, I don't believe you are ever to specify actual host paths, but rather paths on the docker machine (VM). I know that there are implicit vbox shares, /c/Users and /Users/<username> for Windows and OSX, respectively, but these paths are only available to containers by virtue of their existence (mounts) on the docker machine.

If you're trying to point VM paths, I think you might need to run Compose from the VM.

Compose doesn't run in boot2docker, as far as I know.

I have limited experience with docker-machine, but I do know that when I've specified these volume mounts for other containers in docker-compose.yml, the first path is on the _docker machine_, not the Windows host.

For example, in the following, /nmc/src is not a path on the _host_; rather, it's a path on the _docker machine_ (VM), and it works as expected.

php:
  image: nmcteam/php56
  volumes:
    - /nmc/src/php-fpm.conf:/etc/php5/fpm/php-fpm.conf
    - /nmc/src:/var/www
  expose:
    - 9000
  links:
    - db

[jamiejackson]

Sorry, I think I'm wrong about at least part of my reply. I'll come back to this after I get to the office.

[jamiejackson]

I think what's happening is that "/:/rootfs:ro" is confusing our parsing of windows paths.

I think you're right. I think it thinks the first / is to interpreted as a Windows path. I _think_ that should be considered a bug, as it makes / behave differently than all other paths. It seems to make it impossible to create a volume from the docker machine root (as cadvisor seems to want).

To clarify the current behavior with some examples:

| Argument | Shows/Works in Container? | Resulting Source | Resulting Target | Notes |
| --- | --- | --- | --- | --- |
| "c:/:/tmp/c_colon_slash" | true | docker_machine:/c | docker_container:/tmp/c_colon_slash | Of course since the real mount is from host:c:\Users to docker_machine:/c/Users, so no siblings directories of Users are available, but the mechanism still makes sense to me. |
| "/:/tmp/slash" | false | N/A | N/A | This doesn't seem to make sense. How else would one mount the docker machine's root to the docker container (as cadvisor seems to want)? |
| "/c/:/tmp/slash_c_slash" | true | docker_machine:/c | docker_container:/tmp/slash_c_slash | The behavior is the same as that of "c:/:/tmp/c_colon_slash". This makes sense. |
| "/tmp:/tmp/slash_tmp" | true | docker_machine:/tmp | docker_container: /tmp/slash_tmp | This is straightforward and expected. |

If you're trying to point VM paths, I think you might need to run Compose from the VM.

Compose doesn't run in boot2docker, as far as I know. (I'm sticking with this assertion.)

[jamiejackson]

If you're using docker-compose on windows, you should use host paths that contain c:\ or the appropriate drive. Can you try c:\:/rootfs:ro and see if that works?

The backslash has to be escaped, so c:\\:/rootfs:ro does yield a docker container volume (at /rootfs), but of course I don't want the host's root as the source; instead, I want the docker machine's (VM's) root.

[jamiejackson]

I think I have a workaround hack. If I specify /../ instead of /, I seem to get the behavior I want.

This works:

cadvisor:
  image: google/cadvisor
  ports:
    - "8081:8080"
  volumes:
    - "/../:/rootfs:ro"
    - "/var/run:/var/run:rw"
    - "/sys:/sys:ro"
    - "/var/lib/docker/:/var/lib/docker:ro"

However, I think that / _ought_ to work.

[dnephin]

I guess we should check if the first character is a valid drive letter, which should fix /:/foo

[jamiejackson]

@dnephin: Again, I'm very new to this, so take this with a grain of salt:

I'd like to take a step back and ask: When is it ever useful, on a Windows host, to be able to reference Windows host paths (directly)? What's the utility in this?

I'm not sure why you wouldn't just refer directly to the automagic mount in the _docker machine_; e.g., /c/Users/15037/my_docker_project_src:/path/in/docker/container.

The only justification I can even think of--using the current working directory as the source (a trick I've seen done on OSX-specific documentation)--doesn't work on Windows:

docker run --rm -it ^
 -v "%cd%:/tmp/auto" ^
 --entrypoint ls ^
 busybox ^
 -al /tmp/auto

docker: Error response from daemon: Invalid bind mount spec "c:\\Users\\15037\\garbage:/tmp/auto": volumeinvalidmode: invalid mode: "/tmp/auto".

So why bother parsing/manipulating Windows paths at all? Why not just be strict and treat _everything_ as a path in the _docker machine_? I think it's really confusing to allow <drive>: paths at all, since it makes it seem like the Windows file system gets _directly_ mounted in the container, which isn't true. The conclusion might then be that one should be able to use something like e:/foo (or even c:/foo, which is a slightly different issue), which won't work.

If strict _docker machine_ paths were required, then the documentation for volume definitions could be something like:

On OSX, the host's /Users directory is automatically mounted as /Users in the docker machine. On Windows, the hosts's C:\Users directory is automatically mounted as /c/Users in the docker machine. This allows you to easily share files with the docker machine, and in turn, with docker containers.

When specifying volumes which leverage this automatic mount, be sure to preface the source location with /Users on OSX hosts or /c/Users on Windows hosts. Windows note: Neither sibling directories (e.g., /c/Program Files) nor the drive root (i.e., /c/) are really available in the docker machine, since the mount is specifically at the C:\Users directory.

This kind of documentation would have helped me a couple days ago.

[dnephin]

When is it ever useful, on a Windows host, to be able to reference Windows host paths (directly)? What's the utility in this?

The primary use case is that you are developing a piece of software on windows, and you're going to want to share some files from the host with the container, instead of rebuilding the image. If you're on windows it's expected that all of your files are going to be on the host.

If you wanted to work in a VM, you could just run everything (including docker-compose) from the VM, and you'd never need to read files from the host.

I'm not sure why you wouldn't just refer directly to the automagic mount in the docker machine

Because the VM is just an implementation detail. The developer shouldn't need to even know it's there. Some day it might not even need to exist. It's not part of the public interface, so it shouldn't really be exposed. Unfortunately it is at this point, and it needs to be to debug problems with it, but it shouldn't be considered part of the "supported experience".

So why bother parsing/manipulating Windows paths at all?

The goal is to try and make it a good experience for windows developers. So being able to use host paths as they would anywhere else. Not to have to know about the VM and the path that happens to be mounted at this time.

---

It seems to me like you might be happier just running a normal VM and doing all your development in the VM. Then you don't have to worry about windows paths at all.

[jamiejackson]

Some day [the VM] might not even need to exist.

Okay, that's the explanation I needed, thanks. I was going to propose that the only useful drive letter to watch for in parsing is c, but in making your API decisions, I guess you're looking ahead to the day that Windows can act as docker machine.

[jamiejackson]

Hmm, now might be the time to dig into a related issue:

In some of the OSX documentation (might be official, might be third party), I remember seen volumes defined with things like $(pwd) or pwd. Is there a similar trick on Windows that I'm missing?

As I mentioned earlier, this sort of thing throws an error:

docker run --rm -it ^
 -v "%cd%:/tmp/auto" ^
 --entrypoint ls ^
 busybox ^
 -al /tmp/auto

...however, if I'm on the right _track_ with that, might it be appropriate for docker run/docker-compose to allow the resulting path, or something like it?

[adeelahmadch]

Error: Invalid volume specification
Info:
Docker 1.12.5
docker-compose version 1.9.0
docker-machine.exe version 0.8.2
Terminal: git bash
OS: Windows 10

Description:
I just want to share my experience here for windows users who use git bash and ran into volume mount issue. i had a similar problem but unlike other people i was facing issue with "docker-compose up" command. In my .yml file i was trying to mount volume like;

volumes:
    - "/e/orchestration-workshop/dockercoins/webui/files/:files/"

i tried everything from // to ' but nothing worked for me. at the end i tried this workaround to make it work.

volumes:
    - "/e/orchestration-workshop/dockercoins/webui/files/"

So when you don't specify volume it use the same name as of your source directory and it worked. now i can see my folder mounted under /files on my docker container.

:-)

[Artnforces]

I had an issue like this where I was unable to mount a volume thru the docker-compose.yml/
As I have reading another one ( https://github.com/docker/compose/issues/4240 ) , I have found a solution that has fix it.
I have just create a .ENV file in my _docker-compose folder_ with COMPOSE_CONVERT_WINDOWS_PATHS=1 in it.
Then run my compose up -d [...] command with the setting : volumes : ../:/var/www/ in my docker-compose.yml file and I have no more issues about invalid bound mount.