Permission denied on accessing host directory in Docker

Question

Summary I am trying to mount a host directory in Docker  but then I can not access it from within the container  even if the access permissions look good  Details 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

User · Answer

sudo -s did the trick for me on MAC

User · Answer

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

User · Answer

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 https   docs docker com engine reference commandline volume create

User · Answer

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

User · Answer

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 quot   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

User · Answer

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 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  lt path to Dockerfile gt  -t  lt tag name gt  --build-arg UID  UID   After that  running the container and commands as per the OP gave me the expected result

User · Answer

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  https   docs docker com storage bind-mounts  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 gid s 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  https   github com sudo-bmitch docker-base The important bit from the fix-perms script is    update the uid if   -n  quot  opt u quot     then   OLD UID   getent passwd  quot   opt u  quot    cut -f3 -d     NEW UID   stat -c  quot  u quot   quot  1 quot     if    quot  OLD UID quot      quot  NEW UID quot     then     echo  quot Changing UID of  opt u from  OLD UID to  NEW UID quot      usermod -u  quot  NEW UID quot  -o  quot  opt u quot      if   -n  quot  opt r quot     then       find   -xdev -user  quot  OLD UID quot  -exec chown -h  quot  opt u quot            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 uid s  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 exist in advance  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 gid s of the containers are shifted  In that scenario  it s probably easiest to avoid host volumes and only use named volumes

User · Answer

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

User · Answer

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  lt container-data-name gt  ubuntu   This tutorial provides a good explanation on the use of data containers

User · Answer

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

User · Answer

In my situation the problem was different  I don t know why  but even if directory on host had chmod 777 run on it  inside docker it was visible as 755   Running inside container sudo chmod 777 my volume dir fixed it

[docker] Permission denied on accessing host directory in Docker

Examples related to docker

Examples related to file-permissions

Examples related to fedora

Examples related to mount

Examples related to permission-denied