Warum ändern sich die Dateibesitzer von Containern nach dem Kopieren von App-Daten?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Why Do Container File Owners Change After Copying App Data?

Die Eigentümer von Containerdateien ändern sich nach dem Kopieren, wenn numerische UID-/GID-Werte nicht erhalten bleiben oder die Zielumgebung sie neu zuordnet oder überschreibt.

Auf einem Heim-NAS kann dieselbe Datei auf dem Host mit einem Benutzernamen und in einem Container mit einem anderen angezeigt werden, weil der Besitz als Zahlen gespeichert wird, während jede Umgebung diese Zahlen über eine andere Kontodatenbank auflöst. Kopien über eine grafische Oberfläche, eine SMB-Freigabe, ein Archiv, eine Root-Shell, ein Migrationstool oder einen Container-Entrypoint können den Besitz ebenfalls ersetzen. Ermitteln Sie zuerst die numerische Identität und unterscheiden Sie anschließend zwischen Kopierverhalten, Laufzeitbenutzereinstellungen, Startskripten, User-Namespaces und der Zuordnung von Netzwerkdateisystemen, bevor Sie die Berechtigungen im gesamten App-Datenbaum ändern.

Numerische UID und GID vergleichen, bevor Sie Benutzernamen vergleichen

Prüfen Sie Quelle und Ziel mit numerischen Besitzangaben, nicht nur anhand der Namen. Erfassen Sie für eine repräsentative Datei und ihr übergeordnetes Verzeichnis sowohl auf dem Host als auch im Container UID, GID, Modus, ACLs, erweitere Attribute und Dateisystem.

Docker-Bind-Mounts stellen Hostdateien Prozessen zur Verfügung, die möglicherweise eine andere Benutzerdatenbank verwenden. Eine Diskussion in der Docker-Community erklärt, warum zuverlässiger Zugriff von der Übereinstimmung numerischer UID/GID-Werte abhängt und nicht allein von übereinstimmenden Benutzernamen.

Wenn die Zahlen identisch sind, die angezeigten Namen sich aber unterscheiden, wurde der Besitz möglicherweise überhaupt nicht geändert. Korrigieren Sie dann die Dokumentation oder Kontozuordnung, anstatt die Daten rekursiv neu zu schreiben. Wenn die Zahlen abweichen, sichern Sie die bisherigen Informationen und fahren Sie mit den Kopier- und Laufzeitphasen fort.

Feststellen, ob der Kopiervorgang den Besitz beibehalten oder neu erstellt hat

Notieren Sie den genauen Kopierweg: Dateimanager des Hosts, cp, rsync, tar-Archiv, SMB-/NFS-Client, Backup-Wiederherstellung, Docker-Kopierbefehl oder temporärer Migrationscontainer. Jede Methode verwendet andere Standardeinstellungen für Besitzer, Gruppe, ACLs und erweiterte Attribute.

Ein als Root ausgeführter Kopiervorgang kann den numerischen Besitz beibehalten, wenn ausdrücklich Archivoptionen verwendet werden, während ein anderes Tool jede Zieldatei als das Konto anlegt, das den Kopiervorgang ausführt. Ein aktuelles Problem bei einer Containermigration zeigt, wie kopierte App-Daten unlesbar werden können, wenn sich die Ziel-UID von der Laufzeitidentität der Anwendung unterscheidet.

Wiederholen Sie den Vorgang mit einem kleinen Testverzeichnis und prüfen Sie den Besitz unmittelbar vor dem Start der Anwendung. Sind die Zahlen bereits falsch, korrigieren Sie die Kopiermethode oder die Wiederherstellungsoptionen. Ändern sie sich erst nach dem Start, lassen Sie die Kopie unverändert und untersuchen Sie den Entrypoint des Containers.

Den Benutzer der Containerlaufzeit an den Besitzer des Host-Speichers anpassen

Ermitteln Sie den effektiven Benutzer im laufenden Container sowie den numerischen Besitzer des per Bind-Mount eingebundenen App-Datenverzeichnisses. Prüfen Sie außerdem user: in Compose, zusätzliche Gruppen, PUID-/PGID-Variablen der Plattform und bildspezifische Kontoeinstellungen.

Der Betrieb als unprivilegierter Containerbenutzer gewährt nicht automatisch Zugriff auf ein Hostverzeichnis, das einer anderen numerischen Identität gehört. Ein Fall im Docker-Forum löst diese Grenze, indem Containerbenutzer und Hostberechtigungen aufeinander abgestimmt werden, statt das Verzeichnis für alle beschreibbar zu machen.

Wählen Sie für die Anwendung ein stabiles Besitzmodell und dokumentieren Sie es in Compose. Fügen Sie nur die für den gemeinsamen Zugriff erforderlichen Gruppen hinzu. Vermeiden Sie chmod 777, da dies die Identitätsabweichung verdeckt, die Trennung schwächt und den vorgesehenen Besitzer künftiger Dateien nicht sicherstellt.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Prüfen, ob der Entrypoint beim Start den Besitz ändert

Viele Images starten kurzzeitig als Root, erstellen fehlende Verzeichnisse, wenden eine konfigurierte UID/GID an und ändern den Besitz rekursiv, bevor sie die Berechtigungen abgeben. Dadurch kann eine korrekte Kopie so wirken, als würde sie sich nach dem ersten Containerstart selbstständig ändern.

Containerlaufzeiten und Images können ebenfalls Funktionen zum Ändern des Besitzes bei Mounts anbieten. Ein Podman-Problem weist darauf hin, dass die Option :U den Besitz der Quelle überschreiben kann, während Entrypoint-Skripte eine ähnliche rekursive Änderung beim Start der Anwendung ausführen können.

Starten Sie den Container einmal mit sichtbaren Protokollen und überwachen Sie einen kleinen Test-Unterbaum. Durchsuchen Sie den Entrypoint und die Versionshinweise des Images nach chown, Benutzermigration, PUID/PGID und Schritten zur Berechtigungskorrektur. Deaktivieren oder begrenzen Sie dieses Verhalten nur, wenn das Image eine stabile Alternative unterstützt.

Rootless Docker, User-Namespaces und Netzwerkdateisysteme berücksichtigen

Rootless Docker und die Zuordnung von User-Namespaces übersetzen Container-IDs in einen anderen Bereich auf dem Host. NFS, CIFS und einige NAS-Mount-Optionen können Root unabhängig davon unterdrücken oder alle Dateien einer konfigurierten UID und GID zuweisen.

Ein Bericht zu Berechtigungen in Rootless Docker zeigt Dateien mit unerwartetem Besitz, weil die Containeridentität über einen untergeordneten Bereich auf dem Host abgebildet wird. Der diagnostische Hinweis ist die Besitzzuordnung des User-Namespaces und nicht ein herkömmlicher Kopierfehler.

Prüfen Sie, ob der Datenpfad lokal, NFS, CIFS, FUSE oder ein anderes eingebundenes Dateisystem verwendet, und erfassen Sie dessen UID-/GID-, Root-Squash- und ACL-Verhalten. Testen Sie das Erstellen von Dateien auf dem Host und im Container getrennt. Führen Sie auf einer Netzwerkfreigabe kein rekursives chown aus, bevor die Identitätsrichtlinie auf der Serverseite geklärt ist.

Den Besitz anhand einer bekannten Anwendungsidentität korrigieren

Stoppen Sie die Anwendung, sichern Sie die aktuellen Metadaten und legen Sie die exakte UID, GID, Verzeichnismodi, Dateimodi, ACLs und Sicherheitskennzeichnungen fest, die das Image erwartet. Korrigieren Sie ausschließlich die der Anwendung gehörenden Pfade und schließen Sie gemeinsam genutzte Medien oder unabhängige Datensätze aus.

Der ZimaSpace-Leitfaden zum Unterscheiden von Berechtigungsfehlern und schreibgeschützten Mounts ist der nächste Prüfschritt, wenn der korrekte Besitz weiterhin keine Schreibzugriffe ermöglicht.

Starten Sie den Container neu und erstellen, ändern und löschen Sie eine Testdatei als der tatsächliche Dienstbenutzer. Erstellen Sie anschließend den Container neu und wiederholen Sie den Test. Die Korrektur ist erst abgeschlossen, wenn der Besitz nach dem Kopieren, dem Start, einem Neustart und der Neuerstellung des Containers stabil bleibt und die Anwendung ohne weitreichende Berechtigungsausnahmen lesen und schreiben kann.