wake-up-neo.com

Warum fragt der Docker-Container "Permission denied" ab?

Ich benutze folgenden Befehl, um einen Docker-Container auszuführen, und ordne ein Verzeichnis von Host (/root/database) zu container (/tmp/install/database) zu: 

# docker run -it --name Oracle_install -v /root/database:/tmp/install/database bofm/Oracle12c:preinstall bash

Aber in Container finde ich, dass ich ls nicht verwenden kann, um Inhalte in /tmp/install/database/ aufzulisten, obwohl ich root bin und alle Rechte hat: 

[[email protected] /]# cd /tmp/install/database/
[[email protected] database]# ls
ls: cannot open directory .: Permission denied
[[email protected] database]# id
uid=0(root) gid=0(root) groups=0(root)
[[email protected] database]# cd ..
[[email protected] install]# ls -alt
......
drwxr-xr-x. 7 root root  4096 Jul  7  2014 database

Ich überprüfe /root/database in Host und alles scheint OK zu sein: 

[[email protected] ~]# ls -lt
......
drwxr-xr-x.  7 root root       4096 Jul  7  2014 database

Warum fragt der Docker-Container "Permission denied" ab? 

Update:
Die Hauptursache hängt mit SELinux zusammen. Eigentlich habe ich letztes Jahr eine ähnliche Ausgabe getroffen.

linuxdockerpermissionspermission-denieduser-permissions
7
Nan Xiao

Eine in einem Container für ein freigegebenes Verzeichnis verweigerte Berechtigung könnte darauf zurückzuführen sein, dass dieses freigegebene Verzeichnis auf einem Gerät gespeichert ist. Standardmäßig können Container nicht auf Geräte zugreifen. Durch Hinzufügen der Option $docker run --privileged kann der Container auf all devices zugreifen und Kernel-Aufrufe ausführen. Dies wird nicht als sicher angesehen.

Eine einfachere Methode zum Freigeben von Geräten bietet die Option docker run --device=/dev/sdb (wenn /dev/sdb das Gerät ist, das Sie freigeben möchten).

Aus der Manpage:

  --device=[]
      Add a Host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm)

  --privileged=true|false
      Give extended privileges to this container. The default is false.

      By default, Docker containers are “unprivileged” (=false) and cannot, for example, run a Docker daemon inside the Docker container. This is because by default  a  container is not allowed to access any devices. A “privileged” container is given access to all devices.

      When  the  operator  executes  docker run --privileged, Docker will enable access to all devices on the Host as well as set some configuration in AppArmor to allow the container nearly all the same access to the Host as processes running outside of a container on the Host.
4
Auzias

Ich hatte ein ähnliches Problem, wenn ich einen nfs-Mountpunkt als Volume mit Docker-Compose freigeben wollte. Ich konnte das Problem beheben mit:

    docker-compose up --force-recreate

Wenn Sie das Problem gefunden haben, kann dies anderen helfen.

0
d g

Ein weiterer Grund ist eine Nichtübereinstimmung mit der UID/GID. Dies zeigt sich häufig als Möglichkeit, einen Mount als Root zu ändern, nicht jedoch als Containerbenutzer

Sie können die UID festlegen. Für einen Ubuntu-Container, der als Ubuntu ausgeführt wird, müssen Sie möglicherweise :uid=1000 anhängen (mit id -u überprüfen) oder die UID abhängig von Ihrem Anwendungsfall lokal festlegen.

uID = Wert und GID = Wert

Legen Sie den Besitzer und die Gruppe der Dateien im Dateisystem fest (Standard: uid = gid = 0).

Es gibt einen guten Blog darüber mit diesem tmpfs-Beispiel

docker run \
       --rm \
       --read-only \
       --tmpfs=/var/run/prosody:uid=100 \
       -it learning/tmpfs

http://www.dendeer.com/post/docker-tmpfs/

0
KCD