Bekannte Probleme

Das Benutzer-Namespace-Feature (userns) des Linux-Kernels fügt Linux-Containern eine weitere Sicherheitsschicht hinzu. Damit kann ein Hostrechner Container außerhalb seines Benutzer-ID-(UID-) oder Gruppen-ID-(GID-)Namespace ausführen. Das bedeutet, dass alle Container einen Root-Account (UID 0) in ihrem eigenen Namespace haben und Prozesse ausführen können, ohne Root-Berechtigungen vom Hostrechner zu erhalten. Wenn userns erstellt wird, stellt der Linux-Kernel eine Zuordnung zwischen dem Container und dem Hostrechner bereit. Beispiel: Wenn Sie einen Container starten und einen Prozess mit UID 0 darin ausführen (in der Regel Root-Account im Container), ordnet der Linux-Kernel die UID 0 des Containers einer nicht privilegierten UID auf dem Hostrechner zu. Auf diese Weise kann der Container einen Prozess ausführen, als wäre er der Root-Benutzer, während er tatsächlich vom Benutzer nicht als Root-Benutzer auf dem Hostrechner ausgeführt wird.

Der Fehler wird bei der erneuten Zuordnung von userns verursacht. Wenn die Hostrechnerdateien mit einer gültigen UID oder GID für die erneute Zuordnung konfiguriert sind, muss die UID oder GID im Bereich von 0-65535 liegen. Wenn ein Job den Docker-Container startet, ruft Docker ein Image ab und extrahiert Layer aus diesem Image. Wenn ein Layer Dateien mit UID oder GID außerhalb des akzeptierten Bereichs enthält, kann Docker die Neuzuordnung nicht erfolgreich ausführen, sodass der Container nicht gestartet werden kann.

Beispiel: Eine Datei hat eine höhere UID und GID im zulässigen Bereich. Wenn Sie diese Datei in das Docker-Image kopieren, kann sie die hohe UID und GID beibehalten.

Wenn Sie das Containerimage ausführen und die Datei im Container verwendet werden muss, ist die Ausführung nicht erfolgreich.

Stellen Sie sicher, dass keine der Dateien, die in Ihrem Docker-Image verwendet werden, über eine hohe UID oder GID verfügen.

Wenn Sie nicht wissen, welche Datei eine hohe UID oder GID im Image hat, finden Sie diese wie folgt:

1. Geben Sie den Container mit diesem Befehl ein:

   docker run it <image-name> sh

2. Suchen Sie nach Dateien mit hoher UID/GID:

   • Benutzer suchen:

     find / \( -uid 1000000 \) -ls 2>/dev/null

   • Gruppen suchen:

     find / \( -gid 1000000 \) -ls 2>/dev/null

   Die Nummer 1000000 ist anders, weil sie den ID-Fehler darstellt.

3. Wenn Sie Dateien finden, stellen Sie sicher, dass die UID oder GID niedriger ist, entweder im Speicherort der Datei oder im Container.

Nachdem Sie die im Image benötigten Dateien kopiert haben, führen Sie in der Docker-Datei eine der folgenden Aktionen aus:

Am Ordner:

RUN chown -R root:root /root 

Direkt an der Datei:

RUN chown -R root:root job_logs.py

Dieser Fehler tritt auf, wenn Sie einen lokalen Dateisystemspeicher verwenden, der sich nicht im Speicherort /home/datascience befindet.

Bei Jobs können Sie die Größe des Blockspeichers angeben. Der Blockspeicher wird im lokalen Ordner /home/datascience gemountet, den Sie beim Joblauf verwenden können. Er hat eine Speichergröße, die der vor dem Joblauf festgelegten Größe des Block Storage entspricht. Wenn Sie ein Verzeichnis außerhalb dieses Speicherorts verwenden oder erstellen, kann der Speicherplatz schnell zur Neige gehen, sodass die Fehlermeldung angezeigt wird. Das hängt von der Größe des gespeicherten Inhalts ab.

Stellen Sie sicher, dass Sie immer im Hauptordner arbeiten, der über die volle Blockspeichergröße verfügt: (/home/datascience). Verwenden Sie diesen Speicherort zum Erstellen, Bearbeiten und Herunterladen aller Inhalte. Erstellen Sie Verzeichnisse unter diesem Speicherort.

Standardmäßig erstellt Docker auf einer M1 MacBook linux/arm64-Images, die nur auf den Rechnern funktionieren, die die ARM-Architektur verwenden. Intel-basierte Maschinen verwenden die AMD-Architektur. Daher funktionieren Docker-Images, die auf einer M1 MacBook basieren, möglicherweise nicht auf Intel-basierten Computern.