Permission denied on accessing host directory in Docker

I am trying to mount a host directory in Docker, but then I cannot access it from within the container, even if the access permissions look good.

I am doing

sudo docker run -i -v /data1/Downloads:/Downloads ubuntu bash

and then

ls -al

It gives me:

total 8892
drwxr-xr-x.  23 root root    4096 Jun 18 14:34 .
drwxr-xr-x.  23 root root    4096 Jun 18 14:34 ..
-rwxr-xr-x.   1 root root       0 Jun 18 14:34 .dockerenv
-rwx------.   1 root root 9014486 Jun 17 22:09 .dockerinit
drwxrwxr-x.  18 1000 1000   12288 Jun 16 11:40 Downloads
drwxr-xr-x.   2 root root    4096 Jan 29 18:10 bin
drwxr-xr-x.   2 root root    4096 Apr 19  2012 boot
drwxr-xr-x.   4 root root     340 Jun 18 14:34 dev
drwxr-xr-x.  56 root root    4096 Jun 18 14:34 etc
drwxr-xr-x.   2 root root    4096 Apr 19  2012 home

and a lot more lines like that (I think this is the relevant portion).

If I do

cd /Downloads
ls

the result is

ls: cannot open directory .: Permission denied

The host is Fedora 20, with Docker 1.0.0 and go1.2.2.

What is going wrong?

See this Project Atomic blog post about Volumes and SELinux for the full story.

Specifically:

> This got easier recently since Docker finally merged a patch which > will be showing up in docker-1.7 (We have been carrying the patch in > docker-1.6 on RHEL, CentOS, and Fedora). > > This patch adds support for "z" and "Z" as options on the volume > mounts (-v). > > For example: > > docker run -v /var/db:/var/db:z rhel7 /bin/sh > > Will automatically do the chcon -Rt svirt_sandbox_file_t /var/db > described in the man page. > > Even better, you can use Z. > > docker run -v /var/db:/var/db:Z rhel7 /bin/sh > > This will label the content inside the container with the exact MCS > label that the container will run with, basically it runs chcon -Rt > svirt_sandbox_file_t -l s0:c1,c2 /var/db where s0:c1,c2 differs for > each container.

It is an SELinux issue.

You can temporarily issue

su -c "setenforce 0"

on the host to access or else add an SELinux rule by running

chcon -Rt svirt_sandbox_file_t /path/to/volume

WARNING: This solution has security risks.

Try running the container as privileged:

sudo docker run --privileged=true -i -v /data1/Downloads:/Downloads ubuntu bash

Another option (that I have not tried) would be to create a privileged container and then create non-privileged containers inside of it.

Typically, permissions issues with a host volume mount are because the UID/GID inside the container does not have access to the file according to the UID/GID permissions of the file on the host. However, this specific case is different.

The dot at the end of the permission string, drwxr-xr-x., indicates SELinux is configured. When using a host mount with SELinux, you need to pass an extra option to the end of the volume definition:

> - The z option indicates that the bind mount content is shared among multiple containers. > - The Z option indicates that the bind mount content is private and unshared.

Your volume mount command would then look like:

sudo docker run -i -v /data1/Downloads:/Downloads:z ubuntu bash

See more about host mounts with SELinux at Configure the selinux label.

---

For others that see this issue with containers running as a different user, you need to ensure the UID/GID of the user inside the container has permissions to the file on the host. On production servers, this is often done by controlling the UID/GID in the image build process to match a UID/GID on the host that has access to the files (or even better, do not use host mounts in production).

A named volume is often preferred to host mounts because it will initialize the volume directory from the image directory, including any file ownership and permissions. This happens when the volume is empty and the container is created with the named volume.

macOS users now have OSXFS which handles UID/GIDs automatically between the Mac host and containers. One place it doesn't help with are files from inside the embedded VM that get mounted into the container, like /var/lib/docker.sock.

For development environments where the host UID/GID may change per developer, my preferred solution is to start the container with an entrypoint running as root, fix the UID/GID of the user inside the container to match the host volume UID/GID, and then use gosu to drop from root to the container user to run the application inside the container. The important script for this is fix-perms in my base image scripts, which can be found at: Docker Base Images from Brandon Mitchell

The important bit from the fix-perms script is:

# Update the UID
if [ -n "$opt_u" ]; then
  OLD_UID=$(getent passwd "${opt_u}" | cut -f3 -d:)
  NEW_UID=$(stat -c "%u" "$1")
  if [ "$OLD_UID" != "$NEW_UID" ]; then
    echo "Changing UID of $opt_u from $OLD_UID to $NEW_UID"
    usermod -u "$NEW_UID" -o "$opt_u"
    if [ -n "$opt_r" ]; then
      find / -xdev -user "$OLD_UID" -exec chown -h "$opt_u" {} \;
    fi
  fi
fi

That gets the UID of the user inside the container, and the UID of the file, and if they do not match, calls usermod to adjust the UID. Lastly it does a recursive find to fix any files which have not changed UIDs. I like this better than running a container with a -u $(id -u):$(id -g) flag because the above entrypoint code doesn't require each developer to run a script to start the container, and any files outside of the volume that are owned by the user will have their permissions corrected.

---

You can also have Docker initialize a host directory from an image by using a named volume that performs a bind mount. This directory must already exist, and you need to provide an absolute path to the host directory, unlike host volumes in a compose file which can be relative paths. The directory must also be empty for Docker to initialize it. Three different options for defining a named volume to a bind mount look like:

  # create the volume in advance
  $ docker volume create --driver local \
      --opt type=none \
      --opt device=/home/user/test \
      --opt o=bind \
      test_vol

  # create on the fly with --mount
  $ docker run -it --rm \
    --mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=none,volume-opt=o=bind,volume-opt=device=/home/user/test \
    foo

  # inside a docker-compose file
  ...
  volumes:
    bind-test:
      driver: local
      driver_opts:
        type: none
        o: bind
        device: /home/user/test
  ...

---

Lastly, if you try using user namespaces, you'll find that host volumes have permission issues because UID/GIDs of the containers are shifted. In that scenario, it's probably easiest to avoid host volumes and only use named volumes.

From access.redhat.com:Sharing_Data_Across_Containers:

> Host volume settings are not portable, since they are host-dependent and might not work on any other machine. For this reason, there is no Dockerfile equivalent for mounting host directories to the container. Also, be aware that the host system has no knowledge of container SELinux policy. Therefore, if SELinux policy is enforced, the mounted host directory is not writable to the container, regardless of the rw setting. Currently, you can work around this by assigning the proper SELinux policy type to the host directory": > > chcon -Rt svirt_sandbox_file_t host_dir > >Where host_dir is a path to the directory on host system that is mounted to the container.

It's seems to be only a workaround, but I tried and it works.

I verified that chcon -Rt svirt_sandbox_file_t /path/to/volume does work and you don't have to run as a privileged container.

This is on:

• Docker version 0.11.1-dev, build 02d20af/0.11.1

• CentOS 7 as the host and container with SELinux enabled.

Try docker volume create.

mkdir -p /data1/Downloads
docker volume create --driver local --name hello --opt type=none --opt device=/data1/Downloads --opt o=uid=root,gid=root --opt o=bind
docker run -i -v hello:/Downloads ubuntu bash

Take a look at the document docker volume create.

I had a similar issue. Mine was caused by a mismatch between the UID of the host and the UID of the container's user. The fix was to pass the UID of the user as an argument to the docker build command and create the container's user with the same UID.

In the DockerFile:

ARG UID=1000
ENV USER="ubuntu"
RUN useradd -u $UID -ms /bin/bash $USER

In the build step:

docker build <path/to/Dockerfile> -t <tag/name> --build-arg UID=$UID

After that, running the container and commands as per the OP gave me the expected result.

This issue is because SELinux is enabled on your machine. Check the below and disabled it.

[root@nfs-server ~]# getenforce
Enforcing
[root@nfs-server ~]# setenforce 0
[root@nfs-server ~]# getenforce
Permissive

If you want to just disable SELinux you can do this by using the --security-opt label:disable flag.

docker run --security-opt label:disable -v /run/docker.sock:/run/docker.sock POWERFULLCONTAINER

I resolved that issue by using a data container. This also has the advantage of isolating the data from the application layer. You could run it like this:

docker run --volumes-from=<container-data-name> ubuntu

This tutorial provides a good explanation on the use of data containers.

In my situation the problem was different. I don't know why, but even if a directory on the host had chmod 777 run on it, inside the Docker container it was visible as 755.

Running inside container sudo chmod 777 my_volume_dir fixed it.