☰

Eine NFS-Einbindung auf dem Host sichtbar und lesbar/schreibbar im Docker-Container machen

tag-icon • tag-icon linux docker nfs
Eine NFS-Einbindung auf dem Host sichtbar und lesbar/schreibbar im Docker-Container machen

Ich bin neu bei Docker und möchte es verwenden, um eine kontrollierte Kompilierungsumgebung für meinen Code zu erhalten.

Ich habe bereits ein Docker-Image mit allen benötigten Tools. Mein Problem ist derzeit folgendes:

  • Ich habe meinen Code auf dem Hostcomputer, in meinem Home-Ordner, der von einem NFS-Server gemountet ist
  • Ich möchte diesen Ordner im Docker-Container mit r+w-Berechtigungen sichtbar machen

Folgendes habe ich zuerst versucht (Ausführen des Containers mit dem Quellordner als Volume) und der Fehler, den ich erhalte:

[mbrandalero@machine ~]$ docker run -it --cap-add sys_admin -v "/homes/mbrandalero/src:/usr/local/src/" mbrandalero/my-image bash
/usr/bin/docker-current: Error response from daemon: error while creating mount source path '/homes/mbrandalero/src': mkdir /homes/mbrandalero/src: permission denied.

(offenbar wird versucht, das Verzeichnis auf der Hostseite zu erstellen, aber es ist bereits da)

Kurioserweise funktioniert es, wenn ich versuche, den Container mit dem gesamten Home-Ordner als Volume auszuführen, es tritt jedoch ein anderer Fehler auf (keine Schreibberechtigung für den Ordner):

[mbrandalero@machine ~]$ docker run -it --cap-add sys_admin -v "/homes/mbrandalero/:/usr/local/src/home" mbrandalero/my_image bash
root@46712ad936f2:/usr/local/src# cd home/
bash: cd: home/: Permission denied
root@46712ad936f2:/usr/local/src# ls -lah | grep "\(\.\|home\)"
total 4.0K
drwxr-xr-x  1 root  root    18 May 20 14:50 .
drwxr-xr-x  1 root  root    17 May 15 14:06 ..
drwxr-x--- 30 10031 10031 4.0K May 20 15:03 home

Mache ich es richtig? Was übersehe ich?

Weitere Informationen:

  • Betriebssystem: CentOS Linux 7.6
  • Docker-Version: 1.13.1

UPDATE (1):

Das Festlegen einer Benutzer-ID beim Ausführen docker runbehebt das Problem anscheinend, aber ist das die richtige Vorgehensweise? Wenn ich es auf diese Weise ausführe, ist das Problem zwar einigermaßen behoben, sieht aber seltsam aus (ich erhalte „Ich habe keinen Namen!“ als Benutzernamen):

[mbrandalero@machine ~]$ docker run -it --cap-add sys_admin -v "/homes/mbrandalero/:/usr/local/src/home" --user $(id -u) mbrandalero/my_image bash
I have no name!@2efec822e572:/usr/local/src$ cd home/
I have no name!@2efec822e572:/usr/local/src/home$

Antwort1

Wie Sie in Ihrem Update bemerkt haben, wird die UID der Dateien nicht in Bind-Mounts abgebildet, so macht Linux Bind-Mounts. Sie können den Container mit einer anderen UID starten, aber das führt dazu, dass /etc/passwd innerhalb des Containers einem anderen oder (in Ihrem Fall) gar keinem Benutzer zugeordnet wird. Es gibt verschiedene Optionen, aber ich bevorzuge es, die UID des Containers mit einem usermod-Befehl zu ändern, der innerhalb eines Einstiegspunkts für das Image mit meinem ausgeführt wird.Fix-Perms-Skript. Dies muss als Root ausgeführt werden, aber Sie können dann verwenden, gosuum beim Ausführen Ihrer Befehle wieder auf den Benutzer zurückzugreifen. Ich habe darüber in meinemDockercon-Präsentationen.

Beachten Sie, dass Sie statt einer Bind-Mount-Operation in das NFS-Verzeichnis des Hosts auch eine Volume-Mount-Operation direkt auf dem NFS-Server durchführen können. Hier sind einige Beispiele dafür:

  # create a reusable volume
  $ docker volume create --driver local \
      --opt type=nfs \
      --opt o=nfsvers=4,addr=nfs.example.com,rw \
      --opt device=:/path/to/dir \
      foo

  # or from the docker run command
  $ docker run -it --rm \
    --mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=nfs.example.com\",volume-opt=device=:/host/path \
    foo

  # or to create a service
  $ docker service create \
    --mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=nfs.example.com\",volume-opt=device=:/host/path \
    foo

  # inside a docker-compose file
  ...
  volumes:
    nfs-data:
      driver: local
      driver_opts:
        type: nfs
        o: nfsvers=4,addr=nfs.example.com,rw
        device: ":/path/to/dir"
  ...

Antwort2

Falls Sie Ihren Container als ausführen root, wird die Meldung möglicherweise angezeigt error while creating mount source path ... permission denied, weil der NFS-Host alle Remote-Root-UIDs neu zuordnet (auch als Root-Squash bezeichnet).

https://en.wikipedia.org/wiki/Unix_security#Root_squash

Dies ist eine sicherheitsorientierte Funktion, die verhindert, dass ein böswilliger Akteur Ihre Freigabe als sein eigener rootBenutzer mountet und dann schädliche Dinge mit den Daten anstellt. Daher ist diese root_squashOption bei NFS-Mounts normalerweise standardmäßig eingestellt, um diese Art von Problemen zu verhindern. Für den Fall, dass Ihr Container als ausgeführt werden muss , können Sie dies überschreiben, indem Sie die Option in der Datei Ihres NFS-Hosts rootverwenden .no_root_squash/etc/exports

/srv/nfs/shared_folder <hostname>(rw,sync,no_subtree_check,no_root_squash)

http://nfs.sourceforge.net/nfs-howto/ar01s03.html

https://www.thegeekdiary.com/understanding-the-etc-exports-file/

Antwort3

Das hat bei mir funktioniert – ich habe den Host-NFS-Pfad als Volume für den Container deklariert. Und der Host-NFS-Pfad ist ein Nicht-Home-Verzeichnispfad, es ist kein Home-Verzeichnis.

Mein Host-NFS-Einhängepunkt:/mnt/abc

Mein docker-compose.yml-Dateiausschnitt.

   ...
   volumes:
  - /mnt/abc/:/abc
   ...

verwandte Informationen