Compose: Volume doesn't seem to mount on Windows 8.1

[denyeo]

OS: Windows 8.1
docker-compose (Win executable) version: 1.5.0rc1
Running through Docker Toolbox's Docker Quickstart Terminal (Shell: MINGW64).
Following tutorial at http://pothibo.com/2015/6/now-i-understand-a-little-bit-how-docker-works (though this should not matter)

Problem: When I do docker-compose up, I get the error "Could not locate Gemfile". It seems that the volume containing the app's code (including the Gemfile) isn't accessible / isn't being mounted.

Dockerfile:

FROM ruby:2.2
RUN apt-get update -qq && apt-get install -y build-essential
RUN apt-get install -y nodejs
WORKDIR /image_tagger

docker-compose.yml:

image_tagger:
  build: .
  command: bundle exec rails server -p 3000 -b 0.0.0.0
  environment:
    BUNDLE_PATH: /bundle
    RACK_ENV: development
    RAILS_ENV: development
  ports:
    - "3000:3000"
  volumes:
    - .bundle:/bundle
    - .:/image_tagger

(Note the 2 volumes specified - /image_tagger in particular)

Contents of current folder (D:#dev):

Dockerfile  Gemfile  README.md  Rakefile  app/  bin/  config/  config.ru  db/  docker-compose.yml  lib/  log/  public/  test/  vendor/

Steps to reproduce:

docker-compose build
docker-compose up

Result:

$ ../docker-compose.exe up
Creating test2_image_tagger_1
Attaching to test2_image_tagger_1
image_tagger_1 | Could not locate Gemfile
test2_image_tagger_1 exited with code 10
Gracefully stopping... (press Ctrl+C again to force)

I tried various commands in docker-compose.yml:

• pwd resulted in /image_tagger, which is the correct working folder
• ls Gem* resulted in no matching files/folders (i.e. the current folder is probably empty).

Doing docker inspect on the image shows:

$ docker inspect 1196e29ed94b
...
        "Volumes": null,
        "WorkingDir": "/image_tagger",

Conclusion: The current folder isn't being mounted at /image_tagger as specified in docker-compose.yml. Bug?

[dnephin]

We figured this out in IRC. The issue was that docker-machine only sets up C:/Users by default as a shared folder.

[denyeo]

Discussion with @dnephin pointed to docker-machine's ability to access/share only the /Users folder on OSX & Windows hosts. This limitation might be the root cause of the problem with mounting Volumes in this issue.

However, adding other folders to the shared folders in Virtualbox doesn't seem to be working for me. Still troubleshooting.

[orthagonal]

Same problem here. Project folder is in the c:/Users/ path and is visible from my docker VM, as well as shared inside of windows.

My docker-compose.yml looks like so, though I've also tried with relative path to no avail.

app:
  build: 'dev'
  volumes:
    - '/c/Users/orthagonal/my_app/app:/app'
  environment:
    PORT: 5000
  links:
    - 'mongo:mongo'
  ports:
    - '8080:5000'
mongo:
  image: 'mongo:3'
  command: 'mongod --smallfiles --quiet --logpath=/dev/null'

[cruelbob]

Same problem on Windows 10. Project folder is in "c:/Users".

[blaggacao]

I'm waiting for docker volume to be stable, this way we can change the paradigm and mount volumes via window's samba protocol, eventually...

[denyeo]

I got around the issue by

1. Installing the docker-compose Linux binaries into the VM.
2. ADDing the app folder to the image in the Dockerfile (and also ADDing the Gemfile and doing bundle install):

WORKDIR /image_tagger
ADD Gemfile /image_tagger/Gemfile
RUN bundle install
ADD . /image_tagger

(I had to do bundle install in the Dockerfile because it turns out that Ruby gems can't be installed in Virtualbox shared folders - you'll get the error "Gem::Ext::BuildError: ERROR: Failed to build gem native extension. Text file busy @ unlink_internal".)

Eventually I got the Rails app running in the VM. However, even then, I couldn't access the app from the host - the IP address of the VM was inaccessible. When I did docker-machine env default in the host terminal, docker-machine said it couldn't reach the VM. I gave up at that point.

edit: Today I started the VM and host terminal again, and now the VM and app are accessible. It's strange, but hurray.

[dnephin]

@denyeo Thanks for documenting the steps you took. I think unfortunately a few of these issues are outside of compose, but we're working on making the VM experience a lot better.

[denyeo]

No worries, @dnephin. I'm happy to report that the VM was accessible when I started it today. There are further issues to figure out, but this is a small victory.

[nathanleclaire]

@denyeo @cruelbob Can you paste the output of:

$ docker-machine ssh default ls /

please? It will confirm or deny that the C:Users directory is being mounted in the VM successfully. (Note that I'm assuming your machine is called "default" here)

[dnephin]

The output of docker inspect -f '{{ .Mounts }}' <container name> would also be really helpful for debugging.

[rwilliams]

I'm getting the same issue on windows 10

Results from $ docker-machine ssh default ls /
C/ dev/ init linuxrc proc/ sbin/ usr/
bin/ etc/ lib/ mnt/ root/ sys/ var/
c/ home/ lib64 opt/ run/ tmp

Results from docker inspect -f '{{ .Mounts }}' <container name>
[{ /C/Users/username/Documents/appname /myapp rw true}]

[dnephin]

@rwilliams I think in your case the problem is likely case sensitivity. I believe docker-machine requires a lower-case "c", where as we don't enforce that in compose, and you've used an upper-case "C" (for the driver letter).

Could you try changing your docker-compose.yml to use the lower case?

[rwilliams]

@dnephin Thanks, switching to hard paths works. I was trying to use relative paths.

[dnephin]

Ok, I think we need to lowercase paths to handle relative paths.