Yeah, this is putting me back!

Does it work after you fig kill and fig rm? I have a suspicion it's a Docker bug with VolumesFrom: https://github.com/docker/fig/issues/328#issuecomment-50926263

Does it work after you fig kill and fig rm? I have a suspicion it's a Docker bug with VolumesFrom: https://github.com/docker/fig/issues/328#issuecomment-50926263

no, not really,

Same error here while trying to use volumes with a file...

Doesn't work on a VFS here:

Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
Execution Driver: native-0.2
Kernel Version: 3.10.42-xenU-12-e888729-x86_64
Operating System: Ubuntu 14.04 LTS

But works it works fine on my personal computer:

$ docker info
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
Execution Driver: native-0.2
Kernel Version: 3.13.0-35-generic
Operating System: Ubuntu 14.04.1 LTS

For the records, the docker version output is the same, but I'm pretty sure it's not so important as I recall it was perfectly working also in 1.2...

Client version: 1.3.0
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): c78088f
OS/Arch (client): linux/amd64
Server version: 1.3.0
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): c78088f

So the only difference that I can spot is the kernel version. The first (that don't work) is a VFS, the second is my computer. Does that help to understand what's happening ?

Humm, sorry for the pollution. Simple typo. It doesn't seem I'm the first one being caught by this.

If "-v" is called upon an unexistent location on the host side (because of a typo), it'll create an empty directory and all the parents directory if necessary. Then when it tries to mount this empty directory on the container and that a file is already in the target location, then it throws this message.

I don't think docker should be allowed to create directories on the host side. Should I delete my previous comment (and this one ?) to avoid polluting this thread ?

I'll add my two cents / bump this thread. It'd be super helpful to be able to add single files in docker-compose. Right now I have to have a separate directory for each of my containers but most of them only have 1 or 2 files in them. It'd be great to put them all in the same folder and then just reference them individually.

I think there was a bug at some point around doing volumes-from which included bind-mounted files.
I don't think this is an issue today.

This appears to be a recurring issue.

As per @md5's reference and other comments, I can faithfully reproduce this behaviour under the following conditions:

• CentOS 7
• Docker 1.5.0 (yum package docker-1.5.0-28.el7.centos)
• docker-compose 1.1.0

This behaviour did not present in yum package docker-1.5.0-1.el7.

Example:

Using a simple service declaration:

test:
  image: nginx
  ports:
    - "80:80"
  volumes:
    - sites/test.conf:/etc/nginx/conf.d/default.conf

In attempting to bind mount a file rather than a directory, docker-compose produces the following:

docker create_container <- (name=u'webcluster_test_1', image=u'nginx:latest', environment={}, volumes={u'/etc/nginx/conf.d/default.conf': {}}, detach=True, ports=[u'80'])
file exists at %!s(MISSING), can't create volume there

Yet, the equivalent docker run command will succeed:

docker run --name test -d -p "80:80" \
  -v ${PWD}/sites/test.conf:/etc/nginx/conf.d/default.conf \
  nginx

@dayglojesus You seem to be using a development version of Docker.
Can you provide the output of docker version?
The error message you have here is from this commit: https://github.com/docker/docker/commit/b0ed2da4418d62d2d7b940b49e0e89bdcd264569

This commit is not in a released version of Docker and has a fix in master, and is part of the 1.6 RC series.

@cpuguy83 It reports this is version 1.5.0, not 1.6 RC:

Docker version 1.5.0-dev, build fc0329b/1.5.0

This is the "official" build made available in the CentOS 7 yum repos, no tweaks for dev repos.

Why is that docker-compose exhibits this behaviour and docker run does not? Is this a bug in Docker or docker-compose?

Let me know if you need more info.

@dayglojesus Yes, this is not a released version of docker 1.5.0-dev was built sometime after docker 1.5.0 was cut.
The bug does not exist in a released version of docker.

@cpuguy83 I see. Weird, I wonder how this package made it into the repo? Do you happen to know which yum package correlates to the actual Docker 1.5.0 release for CentOS 7?

I'm not sure... ping @lsm5

@dayglojesus so the one that you installed is the RHEL-recompiled docker which has some redhat patches on top of the upstream docker. If that's something you don't care about and only want an rpm with upstream docker, please see: http://wiki.centos.org/Cloud/Docker . This mentions an additional repo which contains an rpm that I build separately as part of the CentOS virt SIG.

If you do care about the rhel stuff in there, please file a bug on https://bugzilla.redhat.com . HTH

Filed a RHEL ticket for this issue. https://bugzilla.redhat.com/show_bug.cgi?id=1209625
Thanks, @lsm5.

Mmm, got the same thing on ubuntu 14.04lts with docker 1.5

happens to me on linux mint/ubuntu, the files are not mounted at all (they are supposed to overwrite the container but they dont)

I have the same issue with etc-localtime on

• Linux guest.vm 3.13.0-49-generic #81-Ubuntu
• x86_64 x86_64 x86_64 GNU/Linux
• Description: Ubuntu 14.04.2 LTS
• Release: 14.04
• Codename: trusty
• docker version 1.5

If you're having a problem, +1's won't help, especially since they are most likely not at all related to the OP's issue.

Please include what docker comand you are running, what you expect to see, and what you are actually seeing.
Also include output of docker info and docker version.
Thanks.

@cpuguy83 ok, here's about my case:

command:

docker run -d --name webserver -p 80:80 -v ~/www/:/home/site/www/ -v ~/docker/share/apache_logs/:/home/site/logs -v ~/.gitconfig:/home/site/.gitconfig ...

situation: ~/.gitconfig not present on the host before executing that command

what happens: ~/.gitconfig gets created as a dir, owned by root (instead of current user), and the container does not run, stopping with a message about not being able to mount ~/.gitconfig (using full path in its text, not the tilde shorthand)

what I expect to see: either docker should create ~/.gitconfig as an empty file, owned by current user, and start the container succesfully, or refuse to start with a better error message and without having created ~/.gitconfig at all

docker info:

user@ubuntu14server:~$ docker info
Containers: 5
Images: 153
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 163
Execution Driver: native-0.2
Kernel Version: 3.16.0-30-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 1
Total Memory: 3.847 GiB
Name: ubuntu14server
ID: D52N:QLNG:UE33:N7F3:LZJP:NCF4:6OUS:COOJ:ISL3:2CRK:ZX3U:L3DW
WARNING: No swap limit support
user@ubuntu14server:~$ docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.4.1
Git commit (client): a8a31ef
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.4.1
Git commit (server): a8a31ef

@gggeek The issue here is there is no way for us to detect that you want a file (this has been discussed before).
In your start script I would recommend adding a touch ~/.gitconfig before your docker run command.

:-D that's what I ended up doing.
What about taking route 2 then and not creating the folder?

@gggeek That ship has sailed and would be a breaking change, unfortunately.

;-( oh, well

I have this bug with Docker version 1.6.0, build 4749651

Related issue: https://github.com/docker/docker-py/issues/546

I think I found one thing related to solve this issue. I use latest docker-compose (1.20)/docker (1.6.0) on AWS. And was getting this error every time I tried to start nginx:

Cannot start container e9586e9e936c9b3991283c676bd071abb92a7b6b3bc0b667cf77a68fa4cc9222: [8] System error: mounting into / is prohibited

Out of desperation I looked in to nginx Dockerfile and saw that it expose one volume. So I added this volume to the list that I mounted and suddenly everything worked!

So the difference between docker-compose and docker seams to be what default value for volumes are.

The issue has been closed but what is the solution?
We've got the same problem that we can't mount files to a docker container.
Latest Docker Toolbox Version (docker 1.9) on Windows
Starting the container ends up in

Cannot start container XXX: [8] System error: not a directory

Same as sascha-egerer, a solution ?

The issue you're reporting is not the same as this issue. This issue was a bug in earlier version of Docker, which was fixed a long time ago.

Your issue sounds related to #2268 maybe? If you could post in that issue with the complete output of docker-compose version, docker info, the contents of your docker-compose.yml, and the commands you ran, we might be able to further debug the issue.

I finally resolve my problem using Git Bash and the command "docker-machine ssh [MACHINE]" to work with Docker.
The new shell of Docker Quickstart Terminal (1.9d) on Windows really bad works.

I'm having the same issue.
Docker-compose: 1.5.1
Docker: 1.9.1

nginx:
  image: nginx
  links:
   - web
  volumes:
   - .:/code
   - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf <------
  ports:
   - "80:80"

@jordi12100 If you are getting a directory, then it couldn't find the file.

Reproduced in docker 1.9.1 trying to mount with server.conf:/etc/server.conf where file /etc/server.conf exists in an image.

Using an relative path seems make docker consider the host file as a name of a folder. Since it's a file in container and we cannot mount a folder to existing file /etc/server.conf, it fails.

Using an absolute path to server.conf fixes the problem for me docker run -v /absolute/path/to/server.conf:/etc/server.conf ... and docker treats server.conf as an usual file.

Relative paths must start with a ., so try ./server.config.

Without it, it's considered a named volume.

I have the same issue and can't mount file even with a .. Docker (or docker-compose?) considers the file as folder unless I provide an absolute file path.

Docker: 1.9.1
Docker-compose: 1.5.2

Use ./server.conf:/etc/server.conf with docker-compose works. But docker CLI's -v option complains about illegal path, accepts only absolute path to the file to be mounted.

@kirisetsz correct; docker-compose accepts relative paths (which are relative to the docker-compose.yml file); Compose will take care of the conversion of a relative path to an absolute path. When using docker (not compose), you must specify an absolute path. You can use -v $(pwd)/server.conf:/etc/server.conf if you don't want to type the whole path

I confirm, I have the same issue with:
Mac OS X.10.11.3
Docker version 1.9.1, build a34a1d5
docker-compose version 1.5.2, build 7240ff3
Even if I specify an absolute or a relative host path, I have the same response:
ERROR: Cannot start container a9ed08a3ee639f61ff2720745011c940a5fff5b9b98bda6a45156a80381c5328: [8] System error: not a directory
FYI:

nginx:
  image: nginx
  ports:
    - 8080:80
    - 8443:443
  volumes_from:
    - application
  volumes:
    - ./SCM/Data/Etc/Configuration/nginx.conf:/etc/nginx/conf.d/default.conf:ro
    - ./LOGS/nginx:/var/log/nginx:rw
  links:
    - fpm

I am also having this issue

composer:
    image: php7-composer:latest
    working_dir: /data/application
    volumes:
      - ./.composer/cache:/var/composer/cache:rw
      - ./.composer/auth.json:/var/composer/auth.json:rw

In this example auth.json is created as a directory on the host machine and it should be a file. If I first put auth.json on the host machine than it complains that it is not a directory.

For me as well when I try :

volumes:
- ./docker/default.conf:/etc/nginx/conf.d/default.conf

I get error: ERROR: Cannot start container 9f......f1e: [9] System error: not a directory

If i change conf.d to something else it works but it mount default.conf as directory instead of file

Windows 10
docker Version: 1.10.1
docker-compose version 1.6.0, build cdb920a

Can this bug be reopened, please, since it was closed without a resolution? It's still happening. My case is the same as many others, trying to mount an nginx.conf file into the nginx image under /etc/nginx/nginx.conf.

In docker-compose.yml:

nginx:
  image: "nginx:1.9.7"
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - "./config/nginx.conf:/etc/nginx/nginx.conf:ro"
    - "./config/development-cert.pem:/etc/nginx/cert.pem:ro"
    - "./config/development-key.pem:/etc/nginx/key.pem:ro"

Output:

$ docker-compose up -d nginx
Starting example_nginx_1
ERROR: Cannot start container 81f4237f3f0e962d8861ca30744bfd78c3b61b4ea5891a19c712c682ecc5142c: [9] System error: not a directory

I'm running Docker on OS X (10.11.3) using a Vagrant VM with the VMware Fusion plugin (VMware Fusion 8.1.0) and a CoreOS host. Relevant version information:

$ vagrant -v
Vagrant 1.8.1

$ vagrant plugin list
vagrant-vmware-fusion (4.0.8)

$ docker-compose -v
docker-compose version 1.6.0, build unknown

$ docker info
Containers: 6
 Running: 5
 Paused: 0
 Stopped: 1
Images: 6
Server Version: 1.10.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.4.1-coreos
Operating System: CoreOS 970.1.0 (Coeur Rouge)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 2.391 GiB
Name: localhost
ID: 73NW:JIK2:PTGX:3JVG:JZM4:NON4:DXOD:NAUU:UN7Q:T3F5:ZMZG:UWGR
Username: redacted
Registry: https://index.docker.io/v1/

$ docker version
Client:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   9e83765
 Built:        Fri Feb 12 22:11:40 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.4.3
 Git commit:   88b8b3a
 Built:
 OS/Arch:      linux/amd64

Please see my comment here: https://github.com/docker/compose/issues/424#issuecomment-157751229

The error may appear the same, but it's most likely caused by a different issue.

Also see https://github.com/docker/docker/issues/13670 and https://github.com/docker/docker/issues/19304.

I've also heard reports that you can get this if the workdir you've set doesn't exist as a directory. I believe you are hitting one of these issues.

Try using https://github.com/brikis98/docker-osx-dev

I encountered this issue and after pulling all my hair out discovered the folder was a symlink to a root-owned folder.

Moved all contents to (my) user-owned folder and works fine.

Docker-1.12.0-rc2
Docker-machine 0.8.0-rc1
Docker-compose 1.8.0-rc1

Found this thread via Google. I'm having this issue, too. I can't bind to single files, OSX.

Docker version 1.12.0-rc4, build e4a0dbc, experimental
docker-compose version 1.8.0-rc2, build c72c966

Docker was just updated today.

Update: Screenshot showing it attempting to mount as directory, not file.

I have same issue :-( can't mount single file

Client:
 Version:      1.12.0-rc4
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   e4a0dbc
 Built:        Wed Jul 13 03:28:51 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc4
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   e4a0dbc
 Built:        Wed Jul 13 03:28:51 2016
 OS/Arch:      linux/amd64
 Experimental: true

also confirming the issue

Today's update on OSX has fixed it. I was able to successfully mount a single file using docker-compose.

Docker version 1.12.0, build 8eab29e, experimental
docker-compose version 1.8.0, build f3628c7

Tryed to mount a file with docker-compose

// docker-compose.yml
version: '2'
services:
  web:
    build: .
    privileged: true
    volumes:
      - "/usr/src/app/app.conf:/etc/app.conf"
    entrypoint: /run.sh

On the host machine

ls /usr/src/app/ -la
total 12
drwxr-xr-x   3 root root 4096 Aug  9 11:08 .
drwxr-xr-x 101 root root 4096 Aug  8 14:16 ..
drwxr-xr-x   2 root root 4096 Aug  9 11:08 app.conf

Docker-compose created a dir : drwxr-xr-x app.conf
instead of a file.

Is this a normal behaviour? I supposed the file to be created and mounted.

I will be very gratefull if someone gives me a clarification.

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Docker version 1.12.0, build 8eab29e
docker-compose version 1.8.0, build f3628c7

@bogulean if the file or directory you're trying to bind-mount does not exist, docker has no way to determine if you're expecting a _file_ or a _directory_, in that case (if /usr/src/app/app.conf doesn't exist), the docker daemon creates a directory on that location, and bind-mounts it in the container.

Note that we tried to deprecate/remove the automatic creation of the path (and produce an error instead), but this was too much of a backward incompatible change (some people rely on this behavior), so we had to keep this behavior in.

@thaJeztah Thanks for quick reply!
I tryed to create a file "/usr/src/app/app.conf" manually before starting docker-compose and the result is below:

ERROR: for web  Cannot start service web: oci runtime error: rootfs_linux.go:53: mounting "/var/lib/docker/aufs/mnt/dc65b60b56bae344412f8c23a35f6a19d897b0cad0673bcb9316267ed02a44fe/etc/app.conf" to rootfs "/var/lib/docker/aufs/mnt/dc65b60b56bae344412f8c23a35f6a19d897b0cad0673bcb9316267ed02a44fe" caused "not a directory"
ERROR: Encountered errors while bringing up the project.

@bogulean what is your setup? Are both the daemon and client running on the same computer, or are you working with a remote daemon (or a daemon running in a virtual machine?)

@thaJeztah I'm using DO host, Ubuntu 16.04 LTS,
docker-compose and docker installed on it, please find versions below:

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Docker version 1.12.0, build 8eab29e
docker-compose version 1.8.0, build f3628c7

everything is running on this machine to there I'm connected using ssh

Trying to take docker compose out of the equation, can you try to reproduce with;

docker run --rm -v /usr/src/app/app.conf:/test/app.conf alpine cat /test/app.conf

which should bind-mount the configuration file and print its contents

docker run -it --rm -v /usr/src/app/app.conf:/test/app.conf alpine sh -c 'cat /test/app.conf'
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
e110a4a17941: Pull complete
Digest: sha256:3dcdb92d7432d56604d4545cbd324b14e647b313626d99b889d0626de158f73a
Status: Downloaded newer image for alpine:latest
Hello from /usr/src/app/app.conf

@thaJeztah I could also run some docker-compose.yml if you'll give it to me for testing purposes

@bogulean right, so looks to be an issue with docker-compose, or with the image you're building/running. This would be the equivalent to the previous test, but then through docker-compose;

version: '2'
services:
  web:
    image: "alpine:latest"
    volumes:
      - "/usr/src/app/app.conf:/test/app.conf"
    command: "cat /test/app.conf"

And to try if it works;

docker-compose run web

(which should also print Hello from /usr/src/app/app.conf)

@thaJeztah, Thanks a lot! Your docker-compose.yml returned Hello from /usr/src/app/app.conf
So that made me realize that I'm doing something wrong in another place and I found that there was a line in my Dockerfile:
VOLUME ["/usr/src/app.conf"]
removed it and file started to bind as expected.

Thanks for your time.

Good to hear, and happy to help out!

The problem in your case, is that VOLUME also expects a directory, so created a volume, and tried to mount that at /usr/src/app.conf. The best way to work with single files from the host is usually to take this situation into account, for example, by having a /usr/src/config/ directory; you'd then bind-mount (or use a volume) for that directory, instead of the file. Obviously, not always possible

@thaJeztah, I have the same problem when running this:

docker run -v $(pwd)/filebeat.yml:/filebeat.yml prima/filebeat:1.2 cat filebeat.yml
cat: filebeat.yml: Is a directory

/ definitely exists within the image/container:

docker run -v $(pwd)/filebeat.yml:/filebeat.yml prima/filebeat:1.2 ls -al
drwxr-xr-x   2 root root   40 Aug  9 20:46 filebeat.yml

Seems to be a Docker bug in general, not related to Docker Compose.
Not sure why Docker would create a directory in this case.

Any ideas? Thanks a lot!

I've also tried your example with the alpine image. Same. cat: read error: Is a directory

@thasmo You are getting this error because filebeat.yml is a directory, not a file.
You must make sure that the file exists on the host prior to trying to mount it into the container, otherwise docker will create a directory for you.

@cpuguy83, I think I just found the problem. I'm using Docker on Windows via Docker Machine and VirtualBox and it probably can't mount the local file through VirtualBox into the container.
https://docs.docker.com/docker-for-windows/troubleshoot/#/host-filesystem-sharing

I have found that problem on clean install docker on windows 10 anniversary Update.
In fact, this problem is very simple solution

Needs share drives in docker options http://www.awesomescreenshot.com/image/1510321/0f1a81d7a8883df5a61bcdf04b3994cf
Looks find and solves problem.

Still having the issue on ubuntu 16.10

➜  gi_proxy git:(master) ✗ docker -v
Docker version 1.12.3, build 6b644ec

docker run --name hap ... -v /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf:/etc/resolv.conf

docker: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:359: container init caused \\\"rootfs_linux.go:53: mounting \\\\\\\"/home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf\\\\\\\" to rootfs \\\\\\\"/mnt/sda1/var/lib/docker/aufs/mnt/34ee49dcff906310df08b5a0bdf02ebafd302c1c7bf8b81ecd2778757fdb5713\\\\\\\" at \\\\\\\"/mnt/sda1/var/lib/docker/aufs/mnt/34ee49dcff906310df08b5a0bdf02ebafd302c1c7bf8b81ecd2778757fdb5713/etc/resolv.conf\\\\\\\" caused \\\\\\\"not a directory\\\\\\\"\\\"\"\n".

If I changed the docker run to mount to a file that doesnt exists like /tmp/foo it works but mounts a directory.

@djpate is your docker daemon running on the same host (and not in a virtual machine?). If /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf does not exist on the machine that the docker daemon is running on, then the daemon will create a _directory_ with that name, and try to bind-mount it at /etc/resolv.conf inside the container. Since /etc/resolv.conf is a _file_, bind-mounting a directory on top of a file will fail.

Having said that, I would strongly discourage overriding /etc/resolv.conf with a local file; /etc/resolv.conf is managed by docker to set the correct DNS server to use. Docker has an embedded DNS server for service discovery, so overriding that file will result in service discovery not working.

If you want to set DNS options, use the --dns, --dns-opt and --dns-search options on docker run;

--dns value                   Set custom DNS servers (default [])
--dns-opt value               Set DNS options (default [])
--dns-search value            Set custom DNS search domains (default [])

This will set those options without causing unexpected results. Note that the DNS inside the container will always be 127.0.0.11 (the embedded DNS server), but that server automatically forwards requests to the DNS server you specified with --dns

@thaJeztah I'm new to docker but I would think that it's running on my machine. I basically installed docker-engine and docker-machine on a regular ubuntu local machine. This is my company's dev env and seems to work for everyone on a mac docker.

I will change it to the DNS option like you mentioned, I was unaware of this. Thank you! But the bug is still there I think.

This is not working for me either on docker-compose v1.6.2 and docker v1.10.2 :(

Using absolute paths works, but unfortunately for my use case absolute paths absolutely won't work :(. I've tried every combination of ./ and ../ that I can think of.

EDIT: Also I'm running on Linux with no VMs, so @thaJeztah solution doesn't work for me

OS is Ubuntu 14.04

Docker is up to 1.13.1 now. Please upgrade your Docker. It been working, since 1.12.x.

Ah, thank you. Will upgrade docker & update if/when fixed :)

EDIT: Worked! Thanks @guice

@thaJeztah

If the file or directory you're trying to bind-mount does not exist, docker has no way to determine if you're expecting a file or a directory, in that case (if /usr/src/app/app.conf doesn't exist), the docker daemon creates a directory on that location, and bind-mounts it in the container.
Note that we tried to deprecate/remove the automatic creation of the path (and produce an error instead), but this was too much of a backward incompatible change (some people rely on this behavior), so we had to keep this behavior in.

I'm quite frustrated after six hours of trying exactly this use-case and now finding out it's impossible.
Why not add something like "file flag" to volume declaration, considering we can specify additional mounting options like :ro and :rw?

volumes:
  - "./config.json:/app/config.json:rwf"

When I'm mapping container file to host file, I expect that host file will be created (copied from container) on container initialization.
Unfortunately it's quite common to find containers having configuration files put directly into application root directory, and obviously you don't want to "volumize" whole root. In that case it would be especially useful if this was working.

@malyzeli you may want to look at secrets as a way to inject config like this, or templating on startup.
Volumes are really designed for persistence, not configuration.
Really docker should not be auto-creating host paths at all, and this behavior has been removed on newer APIs.

@cpuguy83

I don't get your point, so please explain or correct my assumptions, because I'm quite new to Docker ecosystem.

You may want to look at secrets as a way to inject config like this, or templating on startup.

What if I don't know how the config file will look like, because it's created by some installation wizard directly from the application (and which eventually changes from version to version)?
Many applications have this kind of first-time setup, for example Limesurvey and NodeBB.

Volumes are really designed for persistence, not configuration.

Are you implying that configuration of existing container should not be persistent?
Then what if I want to back-up some part of my multi-container infrastructure?
I want to have both data and configuration in volumes so I can restore it quickly if something wrong happens.

Really docker should not be auto-creating host paths at all, and this behavior has been removed on newer APIs.

Actually I don't need it to create host paths, but to initialize given volume with existing image data (for example "externalize" some html templates, which I want to have editable from host system and/or other container), and it still works exactly as stated in Dockerfile reference:

The docker run command initializes the newly created volume with any data that exists at the specified location within the base image.

What if I don't know how the config file will look like, because it's created by some installation wizard directly from the application (and which eventually changes from version to version)?

Let it get created, extract it from the image/container, make a secret out of it

I want to have both data and configuration in volumes so I can restore it quickly if something wrong happens.

Use secrets. We're also looking at a dedicated config object that is similar to secrets, just not so restricted... but today secrets are what's available.

Actually I don't need it to create host paths, but to initialize given volume with existing image data (for example "externalize" some html templates, which I want to have editable from host system and/or other container), and it still works exactly as stated in Dockerfile reference:

Bind mounts are not volumes. The Dockerfile reference is talking about volumes. It's unfortunate that docker run -v is used for both.

I'm definitely not saying to not use volumes for storing configuration, I'm saying you should evaluate if there's a better solution (and IMO secrets is much better for this).

Host binds are a bad solution for anything other than taking something that's pre-existing on the host and getting it into the container... and even then is not generally workable when you are talking about clustered environments.

@cpuguy83

Let it get created, extract it from the image/container, make a secret out of it

Yeah, that's what I do, but it seems annoyingly complicated anyway.. :-)

Use secrets. We're also looking at a dedicated config object that is similar to secrets, just not so restricted... but today secrets are what's available.

I will look into it, didn't know about secrets, thanks!

Bind mounts are not volumes. The Dockerfile reference is talking about volumes. It's unfortunate that docker run -v is used for both.

Okay, that seems to be an explanation of why it didn't work as I expected. I thought that binds and volumes are just different naming for the same thing, considering it's done through the same -v param.

For those who see this bug in Windows... even if you have Drives Shared...

There's an issue where if you use Docker Windows (with docker-compose) and use certain credentials to "Share Drive" such as C:\ or D:\ etc., you may have to unshare, share the drive again, re-enter credentials, otherwise it gives you an error related like:

"ERROR: for ... Cannot start service yourservice: oci runtime error: container_linux.go:262: starting container process caused "process_linux.go:339: container" caused \"rootfs_linux.go:57: mounting \

"\\" caused \\"not a directory\\"""
: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type"

BaranOrnarli how to be the one who has DockerToolbox?

Same issue here as most of the folks on here. But I got it working again simply by restarting the VM.

Windows 10 Education
Docker Toolbox, 17.10.0-ce
VirtualBox 5.2.2

Running this via docker CLI works:
docker run -d -p 8080:80 -v $(pwd)/src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf tutorial/nginx

Running the same via docker-compose, didn't:
snip
volumes: - ./src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf
That is, until I shutdown the VM via the VirtualBox GUI and started the Docker Quickstart Terminal again.

Since then, repeatedly destroying the containers and docker-compose up didn't make error come back.

Hope this helps someone.

I have the same problem. In the mean time I'm using the real volumes docker folder in docker-compose.yml. This is /var/lib/docker/volumes..../file.ext as temporal workaround
(Docker version 17.12.0-ce, build c97c6d6)

If you have such issue also check if you shared your directory on Windows.

Im on ubuntu 14.04. When I run the docker-compose up -d command, I've the follow error:

ERROR: for frontend Cannot start service frontend: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused \"rootfs_linux.go:58: mounting \\\"/home/curso-docker/email-worker-compose/nginx/default.conf\\\" to rootfs \\\"/var/lib/docker/aufs/mnt/ffc214cd493c376554125473ba95e8cd918cd3ad73b6aa8292f51ce84beca8a6\\\" at \\\"/var/lib/docker/aufs/mnt/ffc214cd493c376554125473ba95e8cd918cd3ad73b6aa8292f51ce84beca8a6/etc/nginx/conf.d/default.conf\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

I'm using the absolute path for map the volume /home/curso-docker/email-worker-compose/nginx/default.conf from my host.

Someone have idea about this problem ?

@AzeredoGabriel for me, doing what @BaranOrnarli mentioned before worked like a charm. Reset the credentials for your shared drive, share it again, and it should work. No idea why it suddenly stopped working in the first place, but now it is again.

any news on this? It still seems impossible to mount a single file

@Karlheinzniebuhr This was never a problem. Docker allows mounting files into a container, but you can't mount a file to a directory or vice-versa.

any news on this? It still seems impossible to mount a single file

try to map the file with existing directory. Docker tries to create directory always if not exists.

@cpuguy83 Of course it's a problem. We're not trying to mount files to a directory. We're trying to mount a single file created by the container to the host as a file.

Can we re-open this issue? Still not working as of 2019. On latest Docker and latest docker-compose running on latest Debian.

You can't mount from the container to the host, only the other way.
This is the same behavior for both directories and files.

Same issue, using docker 19.03.1 and docker-compose 1.24.1, while trying to override a config file in store/elastic/filebeat:7.3.0 image with volume binding in docker-compose.yml:

    volumes:
      - ${PWD}/filebeat.yml:/usr/share/filebeat/filebeat.yml:ro

ERROR: for docker_filebeat_1 Cannot start service filebeat: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:58: mounting \\\"/filebeat.yml\\\" to rootfs \\\"/var/lib/docker/overlay2/f49a0ae0ec6646c818dcf05dbcbbdd79fc7c42561f3684fbb1fc5d2b9d3ad192/merged\\\" at \\\"/var/lib/docker/overlay2/f49a0ae0ec6646c818dcf05dbcbbdd79fc7c42561f3684fbb1fc5d2b9d3ad192/merged/usr/share/filebeat/filebeat.yml\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

Initially I tried using "configs" but found out this feature is for swarm only.
I'm trying to find a way to supply a configuration file to default image without creating a custom one with COPY config files.

Same issue

$ ls -l logstash.conf
-rw-r--r--  1 lubumbax  staff  164 Apr 30 18:01 logstash.conf
$ pwd
/Users/lubumbax/Src/Java/elk

$ docker run -it --name logstash -p 5000:5000 \
             -v "$(pwd)/logstash.conf:/usr/share/logstash/pipeline/logstash.conf" \
             docker.elastic.co/logstash/logstash:7.6.2

Result:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/Users/lubumbax/Src/Java/elk/logstash.conf\\\" to rootfs \\\"/var/lib/docker/overlay2/bad85f1a2984bed23619fdf401cc9655573bb1799a8b681d371f5964201b9a82/merged\\\" at \\\"/var/lib/docker/overlay2/bad85f1a2984bed23619fdf401cc9655573bb1799a8b681d371f5964201b9a82/merged/usr/share/logstash/pipeline/logstash.conf\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

$ docker version
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.14
 Git commit:        afacb8b
 Built:             Thu Mar 12 02:45:41 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b7f0
  Built:            Wed Mar 11 01:30:32 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Any chance to get this fixed?

Annoying issue.

Colleagues, check the mount direction in docker-compose.
I got the same problems until I realized that I was wrong, should be like that:

...
    volumes:
      - /host/file:/docker/file:ro
...