So beheben Sie einen Docker-Bind-Mount, der plötzlich schreibgeschützt ist

Ein Docker-Bind-Mount wird schreibgeschützt, wenn Docker einen schreibgeschützten Pfad erhält oder das Host-Dateisystem keine Schreibvorgänge mehr akzeptiert.

Da ein Bind-Mount einen Host-Pfad direkt im Container bereitstellt, kann der Container einen zugrunde liegenden Datenträger, ein Dateisystem, ein Mount-Flag oder eine Sicherheitsrichtlinie nicht selbst reparieren. Am sichersten ist es, zunächst Schreibvorgänge zu stoppen, den Container-Mount mit dem Host-Mount zu vergleichen, festzustellen, ob das schreibgeschützte Verhalten konfiguriert wurde oder durch einen Fehler ausgelöst wurde, und den Speicherzustand wiederherzustellen, bevor die Anwendung neu gestartet wird.

Bestätigen, welcher Pfad schreibgeschützt ist

Testen Sie einen unkritischen Schreibvorgang innerhalb des Containers am Bind-Ziel und einen weiteren Schreibvorgang auf dem Host im Quellpfad. Notieren Sie den genauen Fehler, statt anzunehmen, dass jeder Berechtigungsfehler auf ein schreibgeschütztes Dateisystem hinweist.

Ein Fall im Docker-Forum zeigt, dass ein schreibgeschützter übergeordneter Bind-Mount Docker daran hindern kann, einen verschachtelten Mount-Punkt zu erstellen, weil das erforderliche Verzeichnis auf dem schreibgeschützten übergeordneten Dateisystem nicht erstellt werden kann.

Wenn der Host schreiben kann, der Container jedoch nicht, überprüfen Sie die Docker-Mount-Optionen und Sicherheitskontrollen. Wenn beide mit einem Fehler wegen eines schreibgeschützten Dateisystems fehlschlagen, ändern Sie nicht länger die Container-Benutzer, sondern verlagern Sie die Diagnose auf den Host-Mount und das Speichergerät.

Die tatsächlich verwendeten Docker-Mount-Flags prüfen

Überprüfen Sie die Konfiguration des laufenden Containers und nicht nur die aktuelle Compose-Datei. Bestätigen Sie Quelle, Ziel, Weitergabemodus und ob der Mount über :ro, die Langsyntax, eine Überschreibungsdatei oder ein Bereitstellungstool als schreibgeschützt markiert ist.

Ein Problem im Docker-Client dokumentiert Fälle, in denen eingehängte Pfade schreibgeschützt erschienen, weil die Laufzeitkonfiguration von der beabsichtigten Lese-Schreib-Konfiguration abwich. Der wichtigste Nachweis ist der tatsächliche Mount-Modus des laufenden Containers.

Wenn der Mount absichtlich schreibgeschützt ist, entfernen Sie dieses Flag nur, wenn die Anwendung tatsächlich Schreibzugriff benötigt. Erstellen Sie den Container nach der Änderung der Deklaration neu, da eine Bearbeitung der Compose-Datei einen bestehenden Mount nicht nachträglich ändert.

Feststellen, ob der Host das Dateisystem schreibgeschützt erneut eingebunden hat

Prüfen Sie die Mount-Tabelle des Hosts, das Kernel- und Speicherprotokoll sowie den Dateisystemzustand auf E/A-Fehler, Journal-Fehler, Prüfsummenfehler, Geräte-Resets oder ein schützendes erneutes Einbinden als schreibgeschützt. Erzwingen Sie kein erneutes Einbinden mit Schreibzugriff, bevor Sie verstanden haben, warum der Schutz aktiviert wurde.

Ein Support-Fall zu Unraid beschreibt, wie Docker-Appdata fehlschlug, nachdem ein Dateisystem schreibgeschützt geworden war, einschließlich Fehlern beim Erstellen von Plex-Verzeichnissen. Dieses Muster weist eher auf einen Fehler im Host-Dateisystem als auf eine Container-Berechtigungseinstellung hin.

Stoppen Sie betroffene Container und sichern Sie die Diagnoseinformationen. Reparieren Sie Datenträger, Pool, Kabel, Dateisystem oder Journal über den unterstützten Wartungsablauf der Plattform. Bestätigen Sie anschließend, dass der Host-Pfad fehlerfrei ist, bevor Datenbank- oder Mediencontainer wieder Schreibvorgänge ausführen dürfen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verschachtelte und überlappende Mounts prüfen

Listen Sie alle Bind-Mounts und benannten Volumes auf, deren Ziel innerhalb eines anderen eingehängten Verzeichnisses liegt. Überlappende Mounts können Verzeichnisse verdecken, unerwartetes Zugriffsverhalten übernehmen oder Docker dazu zwingen, einen Mount-Punkt unter einem schreibgeschützten übergeordneten Pfad zu erstellen.

Eine Diskussion auf Server Fault erklärt, dass die Überlagerung eines Lese-Schreib-Mounts und eines umfassenderen schreibgeschützten Mounts an verwandten Container-Pfaden zu verwirrenden Ergebnissen führen kann. Da dieser Themenbereich bereits an anderer Stelle in diesem Paket verwendet wird, gilt hier als praktische Regel: Erfassen Sie die vollständige Zielstruktur, bevor Sie Berechtigungen ändern.

Erstellen Sie erforderliche Host-Verzeichnisse vor dem Start des Containers, vermeiden Sie einen beschreibbaren untergeordneten Mount unter einem schreibgeschützten übergeordneten Mount, wenn die Laufzeit diesen erstellen muss, und halten Sie persistente Pfade in Compose eindeutig fest. Erstellen Sie den Container neu, nachdem Sie die Mount-Struktur vereinfacht haben.

Schreibgeschützten Zustand von Berechtigungen und Sicherheitsrichtlinien unterscheiden

Vergleichen Sie den Fehler des Schreibtests mit Eigentümer, Modus, ACL, SELinux-Label, AppArmor-Profil und Container-Benutzer-ID des Quellverzeichnisses. „Berechtigung verweigert“ und „Dateisystem schreibgeschützt“ sind unterschiedliche Fehler und erfordern unterschiedliche Reparaturen.

Ein Leitfaden zur Speicherfehlerbehebung unterteilt Vorfälle mit schreibgeschützten Volumes in Mount-Flags, Dateisystemfehler, Sicherheitskontexte und Probleme mit dem Storage-Treiber. Diese Einteilung verhindert eine unüberlegte Reaktion mit chmod 777 auf einen schreibgeschützten Zustand auf Speicherebene.

Wenn die Berechtigungen falsch sind, korrigieren Sie Eigentümer oder ACLs auf dem Host mit der für den Container vorgesehenen UID und GID. Wenn das Dateisystem selbst schreibgeschützt ist, werden Berechtigungsänderungen fehlschlagen und dürfen nicht als Ersatz für eine Dateisystemreparatur dienen.

Die Anwendung erst neu starten, wenn ein Schreibtest auf dem Host erfolgreich ist

Schreiben, synchronisieren, lesen und löschen Sie eine temporäre Datei im Host-Pfad. Wiederholen Sie den Test anschließend mit einem kurzlebigen Testcontainer, der dieselbe Mount-Deklaration und denselben Benutzer verwendet. Bestätigen Sie, dass das erwartete Dateisystem auch nach einem Neustart weiterhin eingehängt ist.

Der ZimaSpace-Leitfaden zum Ermitteln einer Container-Neustartabhängigkeit ist der nächste Prüfschritt, wenn die Anwendung weiterhin in einer Neustartschleife läuft, nachdem der Speicher wieder beschreibbar ist.

Die Reparatur ist erst abgeschlossen, wenn das Host-Dateisystem fehlerfrei ist, der tatsächlich verwendete Docker-Mount absichtlich mit Lese-Schreib-Zugriff eingerichtet ist, die Anwendung ihre persistenten Dateien aktualisieren kann und bei anhaltender Nutzung keine neuen E/A- oder Dateisystemfehler auftreten.