Ich hatte ein ähnliches Problem, als ich einen NFS-Einhängepunkt als Volume mit docker-compose freigab. Ich konnte das Problem lösen mit:
docker-compose up --force-recreate
Auch wenn Sie das Problem gefunden haben, kann dies jemand anderem helfen.
Eine Verweigerung der Berechtigung innerhalb eines Containers für ein freigegebenes Verzeichnis könnte daran liegen, dass dieses freigegebene Verzeichnis auf einem Gerät gespeichert ist. Standardmäßig können Container nicht auf Geräte zugreifen. Hinzufügen der Option $docker run --privileged ermöglicht dem Container den Zugriff auf alle Geräte und führt Kernel-Aufrufe durch. Dies gilt nicht als sicher.
Eine sauberere Methode zum Freigeben von Geräten ist die Verwendung der Option docker run --device=/dev/sdb (wenn /dev/sdb ist das Gerät, 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.
Ich habe eine Antwort von einem Kommentar unter:Why does docker container prompt Permission denied?
erhalten
man docker-run gibt die richtige Antwort:
Kennzeichnungssysteme wie SELinux erfordern, dass ordnungsgemäße Kennzeichnungen auf Volume-Inhalten angebracht werden, die in einem Container montiert sind. Ohne eine Bezeichnung könnte das Sicherheitssystem verhindern, dass die im Container ausgeführten Prozesse den Inhalt verwenden. Standardmäßig ändert Docker die vom Betriebssystem festgelegten Labels nicht.
Um eine Bezeichnung im Containerkontext zu ändern, können Sie dem Volume-Mount eines der beiden Suffixe :z oder :Z hinzufügen. Diese Suffixe weisen Docker an, Dateiobjekte auf den freigegebenen Volumes umzubenennen. Die Option z teilt Docker mit, dass zwei Container den Inhalt des Volumes gemeinsam nutzen. Infolgedessen kennzeichnet Docker den Inhalt mit einem gemeinsamen Inhaltslabel. Gemeinsam genutzte Volume-Labels ermöglichen allen Containern das Lesen/Schreiben von Inhalten. Die Z-Option weist Docker an, den Inhalt mit einem privaten, nicht freigegebenen Label zu kennzeichnen. Nur der aktuelle Container kann ein privates Volume verwenden.
Zum Beispiel:
docker run -it --name oracle_install -v /root/database:/tmp/install/database:z ...
Ein weiterer Grund ist eine Nichtübereinstimmung mit der UID/GID. Dies zeigt sich oft so, dass ein Mount als Root geändert werden kann, aber nicht als Container-Benutzer
Sie können die UID festlegen, sodass Sie für einen Ubuntu-Container, der als Ubuntu ausgeführt wird, möglicherweise :uid=1000 anhängen müssen (Überprüfen Sie mit id -u ) oder legen Sie die UID je nach Anwendungsfall lokal fest.
uid=Wert und gid=Wert
Setze den Eigentümer und die Gruppe der Dateien im Dateisystem (Standard:uid=gid=0)
Hier gibt es einen guten Blog 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/