Die Quelle identifiziert die tatsächliche Besitzebene korrekt: Wenn ein Container ein Verzeichnis innerhalb eines eingebundenen ZimaOS-Ordners erstellt, übernimmt das neue Verzeichnis normalerweise die Identität und das Umask-Verhalten des Prozesses, der innerhalb des Containers ausgeführt wird – nicht automatisch die Berechtigungen, die der übergeordnete Ordner erzwingen sollte.
Deshalb kann ein für alle Benutzer beschreibbarer übergeordneter Ordner dennoch zu neu erstellten root:root-Unterordnern mit den Berechtigungen 0755 führen. Wenn die Anwendung als Root ausgeführt wird und eine Standard-Umask verwendet, sind Root-eigene Unterordner zu erwarten, sofern das Image nicht PUID/PGID, einen bestimmten Container-Benutzer, die Vererbung der setgid-Gruppe, Standard-ACLs oder ein anderes Berechtigungsmodell unterstützt.
Das Beispiel aus der Quelle war ein eingebundener Backup-Ordner
Der Benutzer beschrieb einen Pfad wie:
/media/Daten/Backupin dem neu erstellte Unterordner folgende Eigenschaften erhielten:
root:root
drwxr-xr-xEin Benutzer ohne Root-Rechte, beispielsweise mit der UID 999, konnte dann zwar lesen, aber in diesen neuen Unterordnern keine Dateien erstellen.
Ein übergeordneter Ordner mit 0777 erzwingt keinen Besitz der Unterordner
Die Schreibberechtigung des übergeordneten Ordners erlaubt dem Container-Prozess, einen Unterordner zu erstellen. Sie sorgt jedoch nicht automatisch dafür, dass der neue Ordner den Besitzer oder die Gruppe des übergeordneten Ordners übernimmt, sofern die Dateisystem- oder Gruppenregeln nicht entsprechend konfiguriert sind.
Die normale Zuordnung wird durch die UID/GID des Erstellers und die Umask des Prozesses bestimmt.
Verwende PUID/PGID nur, wenn das Container-Image dies unterstützt
Viele Images im LinuxServer-Stil stellen die Umgebungsvariablen PUID und PGID bereit. Andere Images ignorieren diese Variablen vollständig und benötigen das Docker-Feld user: oder anwendungsspezifische Einstellungen.
Die aktuelle Syncthing-Dokumentation von IceWhale weist Benutzer ausdrücklich an, die tatsächlichen ZimaOS-Benutzer-IDs mit folgenden Befehlen abzufragen:
id -u username
id -g usernameund diese Werte anschließend in die PUID/PGID-Felder der App einzutragen.
Siehe das aktuelle ZimaOS-PUID/PGID-Beispiel.
umask legt fest, welche Berechtigungsbits bei der Erstellung entfernt werden
Eine App, die Verzeichnisse mit einem Ausgangsmodus von 0777 erstellt, erzeugt bei einer typischen Umask von 022 Verzeichnisse mit den Berechtigungen 0755. Für die Zusammenarbeit innerhalb einer Gruppe kann eine andere Umask verwendet werden, sofern die Anwendung dies unterstützt.
Lege nicht global eine extrem freizügige Umask fest, nur um eine einzelne App zu reparieren.
setgid kann dabei helfen, eine gemeinsame Gruppe auf neuen Unterordnern beizubehalten
Auf nativen Linux-Dateisystemen kann das Setzen des setgid-Bits auf einem gemeinsam genutzten Ordner dafür sorgen, dass neu erstellte Unterordner die Gruppe des Ordners übernehmen. Das ist nützlich, wenn mehrere Dienste oder Benutzer absichtlich über eine gemeinsame Gruppe zusammenarbeiten.
Dadurch wird die Benutzer-ID des erstellenden Prozesses nicht geändert. Außerdem funktioniert dieses Verhalten bei NTFS-/exFAT-Einhängungen, die Unix-Besitzverhältnisse über Mount-Optionen simulieren, möglicherweise nicht identisch.
Standard-ACLs ermöglichen eine gezieltere Vererbung
Auf Dateisystemen, die POSIX-ACLs unterstützen, können Standard-ACL-Einträge festlegen, welche Berechtigungen neu erstellte Objekte erhalten. Das ist oft sauberer, als nach jedem Backup-Job wiederholt rekursiv chmod auszuführen.
Ob die aktuelle ZimaOS-Oberfläche für einen bestimmten Speicherpfad einen vollständigen ACL-Workflow bereitstellt, sollte überprüft werden, bevor man sich auf eine reine Shell-Konfiguration verlässt.
Die Quelle war ein Feature-Wunsch und keine vorhandene ZimaOS-Einstellung
Der Autor forderte eine globale PUID/PGID-Steuerung, einen Schalter für die Vererbung, die Verarbeitung der Umask, setgid-Unterstützung und eine grafische Oberfläche zur rekursiven Korrektur. Im Thread gibt es keine Antwort von IceWhale, die bestätigt, dass diese Funktionen umgesetzt wurden.
Stelle die Liste der Wünsche nicht als aktuelle Optionen in den Einstellungen dar.
Korrigiere zuerst die Identität der App, bevor du die gesamte Festplatte rekursiv änderst
Wenn eine Backup-App wiederholt Root-eigene Ordner erstellt, behandelt die Ausführung von chown -R nach jedem Job nur das Symptom. Konfiguriere zuerst die Identität, Gruppe und Umask des Containers korrekt und repariere anschließend nur den betroffenen Verzeichnisbaum.
Die aktuellen ZimaOS-App-Einstellungen ermöglichen es Benutzern, Volume-Zuordnungen und die App-Konfiguration zu überprüfen. Welche Berechtigungsvariablen verfügbar sind, hängt jedoch vom jeweiligen Image ab.
FAQ zum Besitz eingebundener Ordner
Warum kann ein Unterordner unter einem beschreibbaren übergeordneten Ordner zu root:root werden?
Weil der Prozess innerhalb des Containers ihn als Root erstellt hat und der übergeordnete Ordner die Identität des Erstellers nicht automatisch überschreibt.
Funktionieren PUID und PGID bei jedem Docker-Image?
Nein. Sie sind imagespezifische Konventionen für Umgebungsvariablen und keine universellen Docker-Variablen.
Hat IceWhale in der Quelle einen globalen Schalter für die Berechtigungsvererbung bestätigt?
Nein. Der Thread enthält einen Feature-Wunsch, aber keine Bestätigung der Umsetzung.
