Docker Community Forums

Share and learn in the Docker community.

Unable to mount directories/files from `docker-compose` (oci runtime error … not a directory)


(Luke Hatcher) #1

Update: Appears to have been fixed in beta10. Thanks!


Expected behavior

Docker compose file located inside the host user’s $HOME with following volume configuration:

myimage:
  volumes:
    - ./local/dir:/home/myuser/somefolder
    - ./local/file:/home/myuser/somefile

Specified paths already exist in base image (somefolder/ and somefile).
Running docker-compose up should start the container and mount our local directory and file on top of the specified paths.

Actual behavior

Running docker-compose up with Docker for Mac (1.11.0-beta9, build: 6388) fails to start the container and displays the following message: ERROR: for myimage rpc error: code = 2 desc = "oci runtime error: could not synchronise with container process: not a directory"

Despite pointing to files under /Users/, the relative paths aren’t being treated as being in a path that is mountable and are instead being searched for on the container host VM and when they aren’t found empty directories are created and a mount is attempted.

In the case of somefile, docker is now trying to mount a directory as a file (hence the error).

Information

Also might affect Docker for Windows, as the same error message has shown up on the forums for it.

Steps to reproduce the behavior

  1. Configure docker-compose to mount a directory or file with a relative path, though still under $HOME
  2. Path is searched on the container host VM instead of local machine, directory is created and mounted into the running image

Bind mounts from docker-compose not working
(Luke Hatcher) #3

Ok, this looks to be caused by some confusion on my part and (possibly) a bug along the way.

I’m mounting volumes with a relative path. This is ultimately in $HOME/dev/myapp, but because of the relative path, docker is mounting the “files” by looking for that path on the OS that’s running the containers. When it doesn’t find them, it creates the path as a directory and mounts that instead (explains issues when a directory is attempting to be mounted on top of a file).

Previous compose file, working with docker-machine and docker-compose:

myimage:
  volumes:
    - ./some/file:/home/user/somefile

I can run the image manually, specifying the volume as the following:

docker run -v `pwd`/some/file:/home/user/somefile myimage

When specified with the full path, it works as before. Unfortunately, I’m not aware of being able to do that in the compose file.

I’ll update the bug report now that I understand what’s happening.


(Dave Tucker) #4

@lukeman I don’t seem to be able to replicate the issue on my machine, but I’m using a development build.

Here’s my test case:

I’ve created a directory called compose-test in my $HOME

$ ls -la
total 8
drwxr-xr-x   4 dave  staff   136  4 May 13:49 .
drwxr-xr-x  69 dave  staff  2346  4 May 13:47 ..
-rw-r--r--   1 dave  staff    98  4 May 13:49 docker-compose.yml
drwxr-xr-x   3 dave  staff   102  4 May 13:47 foo

$ cat docker-compose.yml
myimage:
  image: alpine
  volumes:
    - ./foo:/home/myuser/foo
  tty: true
  command: "/bin/sh"
 
$ docker-compose run myimage
/ # ls /home/myuser/
foo
/ # ls /home/myuser/foo/
bar
/ # exit

Can you update to the latest beta release and try again? Hopefully it’s fixed :smiley:


(Luke Hatcher) #5

Confirmed on my end. Looks like beta10 fixed this!

Pretty amazing turnaround time. :wink:


(Elboletaire) #6

I just had this issue on Docker for Windows v. 1.12.0 beta21 but due to be using cygwin instead of CMD or PowerShell. Using cmd / powershell works as expected.