Kann Ihre Docker-App in ihre Daten schreiben? Eine Checkliste zu Volume-Berechtigungen

Warum ein laufender Container trotzdem nicht schreiben kann

Ein Container kann normal starten, während seine Anwendung keine Dateien im eingebundenen Datenverzeichnis erstellen oder ändern kann. Der Start belegt nicht, dass der Anwendungsprozess dort schreiben darf.

Entscheidend sind die effektive Identität des Prozesses und die Berechtigungen des eingebundenen Dateisystems. Auch ein schreibgeschützter Mount, ACLs, SELinux oder eine User-Namespace-Zuordnung können den Zugriff verhindern. Ermitteln Sie zuerst den betroffenen Pfad und Vorgang, bevor Sie Berechtigungen ändern.

• Notieren Sie die Fehlermeldung und den betroffenen Pfad.
• Klären Sie, welcher Zugriff fehlschlägt, bevor Sie Eigentümerschaft oder Berechtigungen ändern.

Prozessidentität und eingebundenen Pfad ermitteln

Prüfen Sie die Container-Konfiguration und die von Docker gemeldeten Mounts. Für einen Container namens myapp lautet der Befehl:

docker inspect --format '{{json .Mounts}}' myapp

Prüfen Sie Quelle, Ziel und Mount-Einstellungen. Ein Bind Mount verweist auf einen Host-Pfad; ein benanntes Volume hat eine von Docker verwaltete Quelle. Stellen Sie sicher, dass das Ziel dem Pfad entspricht, den die Anwendung tatsächlich nutzt.

Mit docker exec myapp id können Sie die Identität des Containers prüfen. Das ist jedoch nicht zwingend die Identität des Anwendungsprozesses: Ein Entrypoint kann vor dem Start der Anwendung Rechte abgeben. Vergleichen Sie daher nach Möglichkeit die tatsächliche Laufzeitidentität der Anwendung.

Vergleichen Sie numerische Benutzer- und Gruppen-IDs, nicht nur Benutzernamen. Bei einem gewöhnlichen Linux-Bind-Mount ohne Benutzer-Neuzuordnung gelten Eigentümerschaftsangaben auf Host und im Container numerisch. Gleichlautende Benutzernamen können unterschiedlichen IDs entsprechen.

• Halten Sie Mount-Ziel und Quelle fest.
• Ermitteln Sie die effektive Identität der Anwendung und berücksichtigen Sie mögliche Rechteabgabe beim Start.

Eigentümerschaft und Zugriffskontrollen prüfen

Bei einem Bind Mount prüfen Sie die Eigentümerschaft und Berechtigungen des Host-Pfads. Vergleichen Sie sie mit den numerischen IDs des Anwendungsprozesses.

Wenn sich der Zugriff dadurch nicht erklären lässt, prüfen Sie, ob ACLs oder SELinux eine Rolle spielen. Rootless Docker und User-Namespace-Mapping können außerdem dazu führen, dass die IDs auf dem Host von den im Container sichtbaren IDs abweichen. Welche Zuordnungen relevant sind, hängt von der Bereitstellung ab.

• Vergleichen Sie Prozess-IDs und numerische Eigentümerschaft.
• Prüfen Sie ACLs, SELinux sowie User-Namespace- oder Rootless-Zuordnungen, falls die Ursache unklar bleibt.

Die tatsächlich benötigten Vorgänge testen

Prüfen Sie, ob Docker den Pfad schreibgeschützt eingebunden hat. Ein solcher Mount kann das Speichern absichtlich verhindern, auch wenn die Anwendung ansonsten läuft.

Testen Sie den benötigten Zugriff im eingebundenen Verzeichnis mit der effektiven Identität der Anwendung. Verwenden Sie für einen Schreibtest eine temporäre Datei, die keine Anwendungsdaten überschreibt, und entfernen Sie sie anschließend.

Ein erfolgreicher Test mit einer Shell ist ein hilfreicher Hinweis, aber kein Beleg dafür, dass jeder Vorgang der Anwendung funktioniert. Prüfen Sie bei weiter bestehenden Fehlern, ob Anwendung und Test denselben Pfad und dieselbe Identität verwenden.

• Testen Sie nur die Vorgänge, die Ihre Anwendung benötigt.
• Wenn der Test erfolgreich ist, die Anwendung aber scheitert, prüfen Sie Pfad, Identität und Fehlermeldung erneut.

Abweichungen bei UID und GID gezielt beheben

Wenn die numerische Eigentümerschaft nicht zur Identität der Anwendung passt, wählen Sie eine Änderung, die dem vorgesehenen Zugriffsmodell entspricht. Bestätigen Sie die Laufzeitidentität, bevor Sie Eigentümerschaft ändern.

Sollen mehrere Prozesse auf ein Verzeichnis schreiben, stimmen Sie Gruppenmitgliedschaft und Gruppenzugriff ab. Das setgid-Bit, die umask der Anwendung und Standard-ACLs können beeinflussen, ob neu erstellte Dateien für die Gruppe zugänglich bleiben. Gruppen-Schreibrechte auf vorhandenen Dateien allein garantieren das nicht.

Ein pauschales chmod 777 gewährt weitreichenden Zugriff und ist keine verlässliche Lösung. Es behebt beispielsweise weder einen schreibgeschützten Mount noch eine SELinux-Einschränkung. Nehmen Sie stattdessen die engste Änderung an Eigentümerschaft, Gruppe, ACL oder Mount vor, die zur bestätigten Ursache passt.

• Bei gemeinsam genutzten Daten: Gruppe, Mitgliedschaften, setgid-Verhalten, umask und Standard-ACLs berücksichtigen.
• Einen schreibgeschützten Mount nur dann ändern, wenn die Anwendung dort schreiben soll.
• chmod 777 nicht als allgemeine Fehlerbehebung verwenden.

Nach Image- oder Bereitstellungsänderungen erneut prüfen

Eine zuvor funktionierende Bereitstellung kann nach einem Image- oder Hostwechsel scheitern. Ein Image kann die Anwendung unter einer anderen numerischen Identität ausführen, auch wenn der Kontoname gleich aussieht. Auch Eigentümerschaft oder Zugriffskontrollen des Host-Verzeichnisses können sich ändern.

Bei benannten Volumes gilt: Ein leeres Volume wird beim Einbinden in ein Image-Verzeichnis normalerweise mit dessen Inhalt befüllt, sofern Copy-up nicht deaktiviert ist. Ein vorhandenes Volume erhält bei jedem Start nicht erneut die Eigentümerschaft des Image-Verzeichnisses. Volume-Treiber und Mount-Optionen können das Verhalten beeinflussen.

Berücksichtigen Sie bei Rootless Docker und User-Namespace-Mapping die Identitätszuordnung, bevor Sie die Eigentümerschaft auf dem Host ändern.

• Nach einem Image- oder Hostwechsel Laufzeitidentität und Mount-Konfiguration erneut prüfen.
• Bei benannten Volumes zwischen neu erstellten und vorhandenen Volumes unterscheiden.
• Vor Änderungen an Host-Eigentümerschaft die Identitätszuordnung klären.

Erwartete Zugriffe dokumentieren

Halten Sie Datenpfad, Volume-Typ, Anwendungs-UID und -Gruppen sowie die benötigten Lese- und Schreibvorgänge fest. Notieren Sie auch bewusst eingerichtete ACLs, Host-Sicherheitseinstellungen und Identitätszuordnungen.

Wiederholen Sie Prüfung und Schreibtest nach einer Migration, einem Image-Update oder einer Bereitstellungsänderung. Bewahren Sie eine wiederherstellbare Kopie wichtiger Daten auf, bevor Sie Eigentümerschaften oder Zugriffskontrollen ändern.

Eine verwaltete Bereitstellung kann den Infrastrukturaufwand reduzieren, ersetzt aber nicht die Verantwortung für Daten, Zugriff und Wiederherstellung. Airbip bietet verwaltete Bereitstellung für Kataloganwendungen, die als Docker-Workloads auf Airbip-Cloud-Servern ausgeführt werden, einschließlich Dienstlebenszyklusverwaltung und konfigurierbarer täglicher, wöchentlicher und monatlicher Backups. Aktuelle Tarife und Bedingungen finden Sie auf der Airbip-Website.

Quellenhinweise: Die Hinweise zu Mounts, Identitäten, numerischer Eigentümerschaft, Gruppen und benannten Volumes stützen sich auf „Manage permissions on shared Docker volumes“ von Guance (https://guance.com/learn/articles/question-387-docker?lang=en&gc_source=learn_log-management-hk). Ein Beispiel für einen absichtlich schreibgeschützten Mount enthält die Troubleshooting-Dokumentation des Dashy-Projekts (https://raw.githubusercontent.com/lissy93/dashy/HEAD/docs/troubleshooting.md).

• Dokumentieren Sie Identitäten, Mount-Details und erwartete Vorgänge.
• Wiederholen Sie den Zugriffstest nach Änderungen und klären Sie, wer für Dateneigentümerschaft und Wiederherstellung verantwortlich ist.