Single file volume mounted as directory in Docker

Docker documentation says that it's possible to mount a single file into a Docker container:

> The -v flag can also be used to mount a single file - instead of just directories - from the host machine. > > $ docker run --rm -it -v ~/.bash_history:/.bash_history ubuntu /bin/bash > > This will drop you into a bash shell in a new container, you will have your bash history from the host and when you exit the container, the host will have the history of the commands typed while in the container.

When I try that however the file mounts as a directory:

tom@u ~/project $ docker run --rm -it -v file.json:/file.json test
total 80K
drwxr-xr-x  9 root root 4.0K Dec  7 12:58 .
drwxr-xr-x 63 root root 4.0K Dec  7 12:58 ..
drwxr-xr-x  2 root root 4.0K Dec  4 16:10 file.json

My Dockerfile looks like this:

FROM ubuntu:14.04
MAINTAINER Tom
CMD ["ls", "-lah", "/test"]

Docker version is 1.9.1, build a34a1d5.

Is this a documentation issue, a misunderstanding on my side, or is there something else going on?

Maybe that's clear in the answers above... but it took me some time to figure it out in my case.

The underlying reason causing the file being shared with -v to appear as a directory instead of a file is that Docker could not find the file on the host. So Docker creates a new directory in the container with the name being the name of the non existing file on the host as docker thinks that the user just want to share a volume/directory that will be created in the future.

So in the problem reported above, if you used a relative directory in the -v command and docker does not understand relative directories, that means that the file was not found on the host and so docker created a directory. And the answer above which suggests to use $(pwd) will be the correct solution when the problem is due to a relative directory.

But for those reading this page who are not using a relative directory and are having the same problem... then try to understand why the file is missing on the host.

It could just be a stupid typo...

It could be that you're running the "docker run" command from a client which spawns the docker container on a different host and the file being shared does not exist on that different host. The file being shared with -v must exist on the host where the docker agent will spawn the container... not necessarily on the client where the "docker run -v ..." command is executed (although they will be the same in many cases).

There are other possible explanations above for Mac and Windows... that could be it too.

So the file missing from the host is the problem... troubleshoot the problem in your setup... using $(pwd) could be the solution but not always.

test is the name of your image that you have built with 'docker build -t test', not a /test folder.

Try a Dockerfile with:

CMD ["ls", "-lah", "/"]
or
CMD ["cat", "/file.json"]

And:

docker run --rm -it -v $(pwd)/file.json:/file.json test

Note the use of $(pwd) in order to mount a file with its full absolute path (relative paths are not supported)

By using $(pwd), you will get an absolute path which does exists, and respect the case, as opposed to a file name or path which might not exist.
An non-existing host path would be mounted as a folder in the container.

When running docker inside docker (by mounting /var/run/docker.sock for example), you need to be aware that if you do mounts inside docker, the filepaths that are used are always the one on your host.

So if on your host you do the following mount :

-v /tmp/foobar.txt:/my/path/foobar.txt

you should not do the following mount inside docker :

-v /my/path/foobar.txt:/my/other/path.txt

but instead, use the host filepath, eg :

-v /tmp/foobar.txt:/my/other/path.txt

I spent a bit fighting with and diagnosing this issue running docker on Windows. This could also effect people running on Mac OSX, so I add an answer here for people possibly having an issue in those environments as my search brought me to this place and to add an explanation of what appears to be happening in docker.

In Windows or Mac OSX your docker is actually running in a boot2docker VM and only the users directory is actually shared by default. On Windows, this user directory is shared as /c/Users/, however in the MinGW shell shipped with Docker Machine, the drive can be accessed as /C or /c, so this can drive you nuts if you forget the docker commands are actually running against the boot2docker VM and your file paths have to exist on the boot2docker VM and be specified in the manner that they exist there because what appears to be occurring in docker is that instead of giving a warning or error that the directory/file does not exist, docker silently creates the specified source as a directory in the boot2docker VM so there is no ready output to indicate that you are doing anything incorrectly.

So, as in the answer above, if your file is mounting as a directory, then check that you are providing an absolute path. For Windows and Mac OSX check that the absolute path that you are mounting exists in your boot2docker VM.

A case where Docker might not find the file, even though you're sure it exists

As edi9999 pointed out, if you tell the docker daemon to mount a file, it won't look into your current container's filesystem, it will look into the filesystem where the daemon is running.

You might have this problem if your docker daemon is running elsewhere for some reason.

❯ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock docker
/ # echo "bar" > /foo
/ # docker run --rm -v /foo:/foo ubuntu bash -c 'cat foo'
cat: foo: Is a directory

Docker can't find the /foo file on it's host, so it (helpfully?) creates a directory there so at least you've mounted something.

A Workaround

You can work around this by mounting a host directory into the outer container, and then using that directory for the volume you want to appear in the inner container:

❯ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock -v /dev/shm:/dev/shm docker
/ # echo "bar" > /dev/shm/foo
/ # docker run --rm -v /dev/shm/foo:/dev/shm/foo ubuntu bash -c 'cat /dev/shm/foo'
bar

This makes the path /dev/shm/foo refer to the same file in either context, so you can reference the file from the outer container, and the daemon will find it on the the host, which means it will show up as itself in the inner container, rather than as a directory.

For "Docker for Mac/Windows" users, make sure the volume you're trying to mount from your host is part of your "File sharing" preferences:

There is a simple solution for those who use the VirtualBox machine. By default, the C:/User folder is added. If your project is in C:/projects, add this folder to make it available in VB (with automount).

I had the same problem as being discussed here with Docker on my MacBook and none of the suggestions worked for me. Turns out that the issue was that I did not have permissions to the file I was trying to mount (it was owned by root). I copied it to my user path and changed ownership to myself and then the file mounted as a file and not a directory. I think, if you don't have permissions, Docker interprets this as the file simply not existing and then proceeds to mount it as a new directory

I will share my experience, I tend to change my passwords a lot. I had to "reset credentials" in Docker Desktop For Windows for files to be mounted correctly (of course, you should make sure that the files are in the shared paths)