permission denied in containers after moving docker home

Question

Initially docker files system was located in /var/lib/docker Everything was working fine,But due to some space constrain ,We had to move to /Proj/docker & docker service is running.

Active: active (running) since Thu 2019-03-28 09:36:59 UTC; 22h ago Docs: https://docs.docker.com Main PID: 27007 (dockerd) Tasks: 27 Memory: 726.5M CGroup: /system.slice/docker.service └─27007 /usr/bin/dockerd --selinux-enabled -g /Proj/docker

But after that , I am getting permission denied

  [user@host]# sudo docker run  -it oraclelinux:7-slim bash
 bash-4.2# ls
  ls: cannot open directory : Permission denied

**unless I am running  with privilage flag set to true** 

  [user@host]# sudo docker run  -it --privileged=true  oraclelinux:7-slim bash
 bash-4.2# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Can you please help to resolve this

please find additional info

[user@host ~]$ systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/docker.service.d
           └─docker-sysconfig.conf, https-proxy.conf
   Active: active (running) since Thu 2019-03-28 09:36:59 UTC; 1 day 2h ago
     Docs: https://docs.docker.com
 Main PID: 27007 (dockerd)
    Tasks: 27
   Memory: 726.9M
   CGroup: /system.slice/docker.service
           └─27007 /usr/bin/dockerd --selinux-enabled -g /Proj/docker

     


[user@host ~]$ cat /etc/systemd/system/docker.service.d/docker-sysconfig.conf
[Service]
ExecStart=
EnvironmentFile=-/etc/sysconfig/docker
EnvironmentFile=-/etc/sysconfig/docker-storage
EnvironmentFile=-/etc/sysconfig/docker-network
ExecStart=/usr/bin/dockerd \
          $OPTIONS \
          $DOCKER_STORAGE_OPTIONS \
          $DOCKER_NETWORK_OPTIONS \
          $INSECURE_REGISTRY \
          -g /Proj/docker
    
    
[user@host ~]$ cat /etc/systemd/system/docker.service.d/https-proxy.conf
[Service]
Environment="HTTPS_PROXY=http://proxyip:port"



[user@host~]# ls -lrth /Proj/docker
total 56K
drwx------.  4 root root 4.0K Mar 22 07:42 plugins
drwx------.  3 root root 4.0K Mar 22 07:42 image
drwx------.  2 root root 4.0K Mar 22 07:42 volumes
drwx------.  2 root root 4.0K Mar 22 07:42 trust
drwxr-x---.  3 root root 4.0K Mar 22 07:42 network
drwx------.  2 root root 4.0K Mar 22 07:42 swarm
drwx------.  2 root root 4.0K Mar 22 07:42 builder
drwx------.  4 root root 4.0K Mar 22 07:42 buildkit
drwx------.  2 root root 4.0K Mar 28 09:36 runtimes
drwx------.  2 root root 4.0K Mar 28 13:02 tmp
drwx------. 33 root root  12K Mar 29 07:45 overlay2
drwx------.  6 root root 4.0K Mar 29 07:45 containers

could you provide additional information?, did you apply the necessary changes to daemon.json for changes on path for docker? like "graph":"/YourNewPath/Storage", can you provide systemctl status docker is the new path owned by root and is your user part of docker group? — Colin Moreno Burgess, Mar 29 '19 at 09:23
Thanks BMitch disabling SELinux solved the problem ,but I don't think dat will be a permanent solution being a production environment — Raja, Mar 30 '19 at 10:31
@Raja agreed, it's not a solution, but at least you know where the problem is to fix. There is a SELinux package to set policies, not sure if that is designed to support different locations. Leave SELinux in a permissive/logging state and work through the list of logged violations, or get the policies designed for /var/lib/docker and apply them to the new location. — BMitch, Mar 30 '19 at 22:23

Xiang · Answer 1 · 2021-04-01T06:12:24.337

1

When doing copy, do use "-p" option to preserve attributes. This fixed the issue on my side.
Make sure your destination partition has not set "nosuid" option. Check /etc/fstab. Otherwise, you'll meet other permission issues. https://github.com/wodby/docker4drupal/issues/388

All permission issues are gone now.

edited Apr 01 '21 at 06:12

answered Mar 31 '21 at 14:16

Xiang

11
2

score 0 · Accepted Answer · answered Mar 29 '19 at 16:04

We did change the docker graph too so what we did was de following on RedHat 7.6:

Stop dockerd
Move everything from /var/lib/docker to /Docker/Storage
Change configuration on /etc/docker/daemon.json:

{

"graph":"/Docker/Storage"

}

And:

/usr/lib/systemd/system/docker.service:

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
BindsTo=containerd.service
After=network-online.target firewalld.service
Wants=network-online.target
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd://
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3

# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s

# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity

# Comment TasksMax if your systemd version does not supports it.
# Only systemd 226 and above support this option.
TasksMax=infinity

# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes

# kill only the docker process, not all processes in the cgroup
KillMode=process

Then systemctl daemon-reload
Finally systemctl start dockerd

Hope this helps

score 0 · Answer 3 · answered May 12 '20 at 09:12

As you've noted in the comments, this can happen when SELinux rules end up creating the container folders (what would be in /Proj/docker/containers in your case) with the wrong permissions.

Following the suggestion outlined in this answer, a workaround could be to run

chcon -Rt svirt_sandbox_file_t /Proj/docker

permission denied in containers after moving docker home

3 Answers3