2017-02-13 5 views
4

In unserer internen Testumgebung stellen wir CentOS-VMs von einem vSphere-basierten Server bereit. Die Bilder sind Vanille 7.1 mit Paketen und der zugehörigen Konfiguration, um die Authentifizierung über LDAP zu unterstützen. Ich habe Docker 1.13.1 mit OverlayFS-Treiber auf einem xfs-Dateisystem installiert.Docker Host-montierte Volume-Berechtigungen

FROM centos:7 
RUN useradd dockeruser 
USER dockeruser 
VOLUME /data 

auf dem Host:

mkdir data 
echo "hello from host" > data/host-msg.txt 
docker run -ti --rm -v $(pwd)/data:/data testimage bash 

Im Inneren des Behälters:

echo "hello from container" > /data/container-msg.txt 
bash: /data/container-msg.txt: Permission denied 

den Verzeichnisinhalt im Inneren des Behälters Eintrag:

drwxr-xr-x 2 12345 13000 25 Feb 12 21:36 data 
drwxr-xr-x 5 root root 360 Feb 12 21:36 dev 
drwxr-xr-x 1 root root  62 Feb 12 21:36 etc 

Die data Verzeichnis zeigt die Eigentümerschaft im UID/GID-Format anstelle von Benutzername/Gruppenname.

Ich habe viele Artikel und Fragen zu diesem Verhalten und variousstrategies bis workaround gelesen.

Aber. Auf meinem lokalen Fedora 25 Entwicklungssystem bekomme ich nichts von diesem Verhalten. Ich führe die obige Prozedur aus, bin in der Lage, in den host-mounted/data mount zu schreiben, und die Verzeichnisliste zeigt Benutzername/Gruppenname an.

/ 
    drwxrwxr-x 2 dockeruser dockeruser 4096 Feb 12 04:36 data 
    drwxr-xr-x 5 root  root   360 Feb 12 22:00 dev 
    drwxr-xr-x 1 root  root  4096 Feb 12 22:00 etc 

/data 
    -rw-rw-r-- 1 dockeruser dockeruser 21 Feb 12 22:04 container-msg.txt 

Um alles so ähnlich wie möglich in das Labor Konfiguration macht ich ein CentOS 7.1 VM auf meinem dev System über libvirt stand auf und bekam wieder die gleichen Ergebnisse - nicht mit uid/gid-Mapping durcheinander, Benutzernamespaces, nichts. Schreiben in das Host-gemountete Volume aus dem Container Just Worked, out of the box.

Was könnte möglicherweise für dieses Verhalten verantwortlich sein? Führt das LDAP auf der Labor-VM irgendwie zu Berechtigungsproblemen auf Dateisystemebene? Gibt es etwas Spezifisches, das ich von unserem Ops-Team entweder inspizieren oder vorübergehend deaktivieren lassen könnte, um dieses Problem zu beheben?

Schließlich und vielleicht am wichtigsten, wenn Probleme mit Berechtigungen auf Host-gemounteten Volumes für mich auf einem sauberen CentOS oder Fedora Workstation überhaupt keine Probleme zu sein scheinen, warum ist es immer noch eine Sache im Docker Gemeinschaft? Gibt es Konfigurationen in diesen Setups, die sich grundlegend von denen anderer Benutzer unterscheiden (die VM-Teams meines Teams enthalten), dass die Dinge einfach funktionieren?

+0

Haben Sie eine Lösung gefunden? – Xplouder

Antwort

0

Das Datenverzeichnis zeigt die Eigentümerschaft im UID/GID-Format anstelle von Benutzername/Gruppenname.

Dies liegt daran, dass Ihr Container keine Zuordnung für diese UID/GUID aufweist (überprüfen Sie/etc/passwd). Tatsächlich haben die Dateien tatsächlich UID/GUID immer. Es ist nur eine Funktion der Anwendung, die Namen zurückzugeben. Versuchen Sie stat den Weg von innen/außen Container. Sie sollten die gleiche UID/GUID haben

stat /data 
stat /path/on/host 
Verwandte Themen