Compose: Relative host volume mounts do not work

Given the following docker-compose.yml file:

example:
  image: alpine:latest
  volumes:
    - .:/data
  command: ls -al /data

and the following directory foo:

.
├── docker-compose.yml
└── bar

1 directory, 1 file

Expected behavior (works with Docker toolbox)

C:\Users\tvollstaedt\foo>docker-compose up
Starting c1c307b241e4_foo_example_1
Attaching to c1c307b241e4_foo_example_1
c1c307b241e4_foo_example_1 | total 9
c1c307b241e4_foo_example_1 | drwxrwxrwx    1 1000     50            4096 May 28 02:14 .
c1c307b241e4_foo_example_1 | drwxr-xr-x   24 root     root          4096 May 28 02:34 ..
c1c307b241e4_foo_example_1 | drwxrwxrwx    1 1000     50               0 May 28 01:45 bar
c1c307b241e4_foo_example_1 | -rwxrwxrwx    1 1000     50              82 May 28 02:34 docker-compose.yml
c1c307b241e4_foo_example_1 exited with code 0    

Actual behavior (Docker for Windows)

C:\Users\tvollstaedt\foo>docker-compose up
Creating foo_example_1
Attaching to foo_example_1
example_1  | total 4
example_1  | drwxr-xr-x    2 root     root            40 May 28 01:36 .
example_1  | drwxr-xr-x   24 root     root          4096 May 28 02:35 ..
foo_example_1 exited with code 0

Information

Drive C is shared through Docker settings, absolute mounts work as expected.

No relevant entries in log, first lines:

[00:53:29.805][Program        ][Info   ] Version 1.11.1-beta13 (build: 3441)
[00:53:29.810][Program        ][Info   ] Starting on: 5/28/2016 12:53:29 AM
[00:53:29.813][Program        ][Info   ] Resources: C:\Program Files\Docker\Docker\Resources
[00:53:29.818][Program        ][Info   ] OS: Windows 10 Pro
[00:53:29.821][Program        ][Info   ] Edition: Professional
[00:53:29.825][Program        ][Info   ] Id: 1511
[00:53:29.828][Program        ][Info   ] Build: 10586
[00:53:29.830][Program        ][Info   ] BuildLabName: 10586.306.amd64fre.th2_release_sec.160422-1850
[00:53:29.837][Program        ][Info   ] Mixpanel Id: 83FC98B0-B2EA-4D2F-9952-6FC4C92E228E
[00:53:29.850][Program        ][Info   ] Sha1: 5307146e79f6a634960d05da93adc33cf602d1f1

are you solved that problem? i have same. and try to get solution

No, it’s still not wirking with the latest beta18 (build 5226). Unfortunately, I’m unable to use Docker for Windows for development environments until this is fixed.

Bump. Please fix this.

Works fine on initial startup. However, on computer restart, containers path is not saved correctly and containers starts without the proper volume binding

Are you sure this works with docker-compose? Did you used the example file I posted, or do you have another example? It’s not working for me at all, relative paths are just not mounted.

I can now confirm that the latest docker for windows (stable) fixes this issue.

I still have the same problem with Docker Toolbox on Windows 7. I create a folder called compose-test, and used the example docker-compose.yml file. I then ran touch DELETEME in the same folder. Here is the content of the folder:

$ ls
DELETEME  docker-compose.yml

This is the output of docker-compose up:

$ docker-compose down && docker-compose up
Pulling example (alpine:latest)...
latest: Pulling from library/alpine
88286f41530e: Pull complete
Digest: sha256:f006ecbb824d87947d0b51ab8488634bf69fe4094959d935c0c103f4820a417d
Status: Downloaded newer image for alpine:latest
Creating composetest_example_1 ...
Creating composetest_example_1 ... done
Attaching to composetest_example_1
example_1  | total 4
example_1  | drwxr-xr-x    2 root     root            40 Oct 18 08:54 .
example_1  | drwxr-xr-x    1 root     root          4096 Oct 18 08:54 ..
composetest_example_1 exited with code 0

As you can see, the DELETEME file does not exist in the container.

I updated both VirtualBox and Docker Toolbox today. I’m running VirtualBox version 5.1.28 r117968 (Qt5.6.2), and this is the output of docker version:

$ docker version
Client:
 Version:      17.07.0-ce
 API version:  1.31
 Go version:   go1.8.3
 Git commit:   8784753
 Built:        Tue Aug 29 17:41:05 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:45:38 2017
 OS/Arch:      linux/amd64
 Experimental: false

Any ideas?

It seems this is not only related to Docker Compose:

$ docker run -v $(pwd):/data alpine:latest ls -al /data
total 4
drwxr-xr-x    2 root     root            40 Oct 18 08:54 .
drwxr-xr-x    1 root     root          4096 Oct 18 10:30 ..

Still no DELETEME or docker-compose.yml file…

So this is embarrassing. Reading this answer, I had forgotten to add the working directory as a shared folder in VirtualBox. Most of my stuff is under C:\dev, so I mounted all of C:\dev as c/dev/ - with all the boxes ticked (“Read-only”, “Auto-mount” and “Make permanent”).

Essentially, the Docker VM now contains everything under /c/dev/ (as read-only), which uses the same folder structure as my MinGW shell (Docker Quickstart Terminal). This is essential if you use the $(pwd) command (or the ./ path in docker-compose.yml) when mounting.

After I did that, both the docker run and docker-compose up commands work:

$ docker run -v $(pwd):/data:ro alpine:latest ls -al /data
total 5
drwxrwxrwx    1 1000     50               0 Oct 18 06:10 .
drwxr-xr-x    1 root     root          4096 Oct 18 13:27 ..
-rwxrwxrwx    1 1000     50               0 Oct 18 06:10 DELETEME
-rwxrwxrwx    1 1000     50              86 Oct 18 06:09 docker-compose.yml

…and with Docker Compose:

$ docker-compose down && docker-compose up
Removing composetest_example_1 ... done
Creating composetest_example_1 ...
Creating composetest_example_1 ... done
Attaching to composetest_example_1
example_1  | total 5
example_1  | drwxrwxrwx    1 1000     50               0 Oct 18 06:10 .
example_1  | drwxr-xr-x    1 root     root          4096 Oct 18 13:29 ..
example_1  | -rwxrwxrwx    1 1000     50               0 Oct 18 06:10 DELETEME
example_1  | -rwxrwxrwx    1 1000     50              86 Oct 18 06:09 docker-compose.yml
composetest_example_1 exited with code 0

So now it works! It was just my own inexperience with Docker Toolbox which stopped me :innocent: