Docker.github.io: Empty Folder after "docker run -v"

Created on 21 Apr 2017  路  3Comments  路  Source: docker/docker.github.io

Hi,

i have on my Raspberry Pi docker.

Now i create a Dockerfile:

FROM resin/rpi-raspbian:jessie-20160831
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol

After run the Container with:

docker run -d -v </emptyDir>:/myvol <image>

the Directory was created, but empty. (outside of the Container in .)

is /home/pi/myvol on my RPI...

What i make wrong???

Most helpful comment

This is super interesting, and some snippets in the docs are misleading about this.
Basically when you do docker run -v <host>:<container> you're mounting a directory in the container (duhhhh), but here's the catch: by mounting a directory you are hiding the files that were there and can't access them anymore. If you mount an empty directory on top of a directory that has files, you won't be able to see those files any more.

Now... in most cases, when you do docker run -v, Docker copies the files to the new filesystem and then mounts it in the container. This makes it seem that you're seeing the original files, but you're seeing a copy.

In 99% of the cases, this is the behavior that you expect, but 1% of times, if you don't understand what's going on behind the scenes, you see "strange" behaviors.
In your case, what's happening is that you're mounting a directory from your filesystem into the container, and in those cases Docker doesn't copy the files to the mount.

There are two workarounds for this. If you don't care about where the files are in your machine, you can use named volumes.

docker volume create myvol
docker run -d -v myvol:/myvol <image>

This creates in your machine /var/lib/docker/volumes/myvol/_data and you'll be able to see the file that was created in the container.
If you really care about specifying a directory in your local machine, you'll have to mount your local directory in a directory that's not /myvol, and at run time, move the files to the mount point.

docker run -d -v </local-path>:/myvol2 <image>

And then inside the container

cp /myvol/* /myvol2

@thunder1902 I've created #2992 so that we can improve the docs, but I'm closing this issue. In the future you can use forums.docker.com to ask for help.

All 3 comments

This is super interesting, and some snippets in the docs are misleading about this.
Basically when you do docker run -v <host>:<container> you're mounting a directory in the container (duhhhh), but here's the catch: by mounting a directory you are hiding the files that were there and can't access them anymore. If you mount an empty directory on top of a directory that has files, you won't be able to see those files any more.

Now... in most cases, when you do docker run -v, Docker copies the files to the new filesystem and then mounts it in the container. This makes it seem that you're seeing the original files, but you're seeing a copy.

In 99% of the cases, this is the behavior that you expect, but 1% of times, if you don't understand what's going on behind the scenes, you see "strange" behaviors.
In your case, what's happening is that you're mounting a directory from your filesystem into the container, and in those cases Docker doesn't copy the files to the mount.

There are two workarounds for this. If you don't care about where the files are in your machine, you can use named volumes.

docker volume create myvol
docker run -d -v myvol:/myvol <image>

This creates in your machine /var/lib/docker/volumes/myvol/_data and you'll be able to see the file that was created in the container.
If you really care about specifying a directory in your local machine, you'll have to mount your local directory in a directory that's not /myvol, and at run time, move the files to the mount point.

docker run -d -v </local-path>:/myvol2 <image>

And then inside the container

cp /myvol/* /myvol2

@thunder1902 I've created #2992 so that we can improve the docs, but I'm closing this issue. In the future you can use forums.docker.com to ask for help.

Pardon me dear community,

But how does this will be replicable and running on a Windows environment ?. I followed several blogs and threads about this but I do not see a shine in here... following up the above mentioned commands also fail in a Windows 10 Enterprise environment.

Directories displayed but none files... still
c:\test>docker run --privileged -it -v //c/:/data alpine ls -R /data
/data:
Users
/data/Users:
c:\test>

Pardon me dear community,

But how does this will be replicable and running on a Windows environment ?. I followed several blogs and threads about this but I do not see a shine in here... following up the above mentioned commands also fail in a Windows 10 Enterprise environment.

Directories displayed but none files... still
c:\test>docker run --privileged -it -v //c/:/data alpine ls -R /data
/data:
Users
/data/Users:
c:\test>

UPDATE: Nevermind, just did this and worked for me :)

  1. Give "Full Control" to the folder I am using as local/source mounting directory and adding it to the sharing group "Everyone" (right click on folder> Properties> Sharing> Advanced Settings)
  2. Verify the docker-daemon C drive sharing is activated (with Linux mounting system, so I need to use -v //c/my/local/folder:/home/container to access my drive and properly mount it on the container)
  3. Set the docker-daemon Network DNS Server to Automatic (I wrongly set it up to fixed '8.8.8.8', do not use that one please)

Greets then,
Alan

Was this page helpful?
0 / 5 - 0 ratings