So verhindern Sie Berechtigungsabweichungen in Immich-Datenordnern

Das Verhindern von Berechtigungsabweichungen in Immich bedeutet, Dateibesitz und Zugriffsregeln vorhersehbar zu gestalten, bevor verschiedene Container, NAS-Protokolle, Aktualisierungen oder Wartungsaufgaben neue Dateien mit unterschiedlichen Identitäten erstellen.

Die dauerhafte Lösung ist kein regelmäßiges rekursives Zurücksetzen von Berechtigungen. Erfassen Sie die numerischen UID/GID-Werte und den Zugriff, den jeder Workflow tatsächlich benötigt, halten Sie den Besitz von Einhängepunkten und die ACL-Vererbung bewusst fest, trennen Sie schreibgeschützte von beschreibbaren Pfaden und testen Sie den Erstellungspfad nach jeder Änderung. Berechtigungsabweichungen werden verhindert, wenn die neue Datei von morgen korrekt erstellt wird, ohne dass ein Notfall-chown erforderlich ist – nicht wenn die Bibliothek von heute zufällig lesbar ist.

Erfassen Sie die Identitäten, die jeden Immich-Pfad lesen und beschreiben

Listen Sie die in Immich eingebundenen Host-Pfade auf und ermitteln Sie, welche Prozesse in jedem Pfad Dateien lesen, erstellen, umbenennen oder löschen sollen. Erfassen Sie für jeden Schreibprozess seine numerische UID und GID auf dem Host und innerhalb des Containers. Numerische IDs sind wichtiger als übereinstimmende Benutzernamen, da Dateien den Besitz als Zahlen speichern.

Nehmen Sie auch Schreibprozesse außerhalb von Immich in das Verzeichnis auf. SMB-Uploads, NFS-Clients, Sicherungswerkzeuge, Importskripte, Container zur Medienverwaltung und eine Administratorshell können alle Dateien im selben Verzeichnisbaum erstellen. Wenn sie dies als unterschiedliche Identitäten tun, kann die Bibliothek langsam Besitzer und Modi ansammeln, die für einen Pfad funktionieren, für einen anderen jedoch fehlschlagen.

Bewahren Sie diese Identitätsübersicht zusammen mit der Compose-Konfiguration auf. Ein künftiges Image-Update, eine Servermigration oder ein wiederhergestelltes NAS-Konto kann dann mit einer bekannten funktionierenden Ausgangsbasis verglichen werden, statt die Abweichung erst zu entdecken, wenn neue Uploads fehlschlagen.

Verwenden Sie ein bewusst festgelegtes Modell aus Besitzer, gemeinsamer Gruppe und minimalem Zugriff

Legen Sie fest, welche Identität Daten im Besitz der Anwendung besitzen soll und welche gemeinsame Gruppe gegebenenfalls Zugriff benötigt. Geben Sie jedem Workflow nur die erforderlichen Lese- oder Schreibrechte. Vermeiden Sie es, den gesamten Immich-Verzeichnisbaum für jeden beschreibbar zu machen, nur weil ein Container kein Vorschaubild erstellen oder eine importierte Datei verschieben kann.

UID/GID-Abweichungen und zu weit gefasste Modi sind häufige Ursachen für Fehler bei gemeinsam genutzten Volumes. Das sicherere Muster besteht darin, Container- und Volume-Berechtigungen abzugleichen, statt uneingeschränkten Zugriff zu gewähren. Das ist auf einem Heimserver wichtig, auf dem mehrere Dienste auf denselben Speicherpool zugreifen können.

Wenn mehrere Dienste Schreibzugriff benötigen, verwenden Sie eine gemeinsame Gruppe und einheitliche Gruppenberechtigungen oder ACLs, statt den Besitz abwechselnd rekursiv den einzelnen Anwendungen zuzuweisen. Überprüfen Sie zuerst ein repräsentatives Verzeichnis. Umfassende rekursive Änderungen an der gesamten Fotobibliothek sollten mit einer aktuellen Sicherung nur als letzte Maßnahme erfolgen, nicht als routinemäßige Wartung.

Sorgen Sie für vorhersehbare Berechtigungen neuer Dateien

Vorhandene Dateien können einwandfrei aussehen, während neue Dateien sofort abweichen, weil die Regeln für ihre Erstellung falsch sind. Prüfen Sie die ACL des übergeordneten Verzeichnisses, Standard-ACL-Einträge, die Umask, die Dienstidentität sowie alle für den Pfad geltenden SMB- oder NFS-Einstellungen zur Dateierstellung. Ziel der Prävention ist die Vererbung, nicht die Bereinigung.

Bevor Sie Modi rekursiv ändern, vergleichen Sie den numerischen Besitz auf dem Host mit der UID/GID, unter der der Container tatsächlich läuft. Diese Prüfung von UID/GID bei Bind-Mounts trennt eine Identitätsabweichung schnell von einer tatsächlich fehlenden Berechtigung. Beheben Sie die Beziehung zwischen Besitzer und Gruppe, statt sie mit zu großzügigen Modi zu verschleiern.

Erstellen Sie über jeden normalen Schreibpfad eine kleine Testdatei: Immich-Upload, Import-Workflow, SMB/NFS-Übertragung, falls verwendet, und Wiederherstellung aus einer Sicherung. Prüfen Sie nach jedem Test Besitzer, Gruppe, Modus und ACL. Wenn zwei Erstellungspfade inkompatible Ergebnisse liefern, lösen Sie diesen Richtlinienkonflikt, bevor Sie weitere Daten importieren.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verhindern Sie, dass Mount- und Aktualisierungsänderungen den Besitz überschreiben

Behandeln Sie eine Compose-Änderung, ein Image-Update, ein erneutes NAS-Einhängen oder eine Migration als berechtigungsrelevante Änderung. Erfassen Sie vor der Anwendung die aktuelle Quelle und das Ziel des Mounts, ob der Pfad schreibgeschützt oder beschreibbar ist, den effektiven Benutzer des Containers sowie eine Stichprobe des numerischen Besitzes aus jedem wichtigen Verzeichnis.

Übertragungen und Netzwerkspeicher können andere SMB/NFS-Identitäten, numerische IDs, ACL-Vererbung und ein anderes Umask-Verhalten einführen. Verwenden Sie Fehlerquellen bei NAS-Berechtigungsänderungen als Checkliste vor Änderungen, wenn Immich-Daten zwischen Dateisystemen oder Zugriffsmethoden verschoben werden.

Vergleichen Sie nach der Änderung dieselben Stichproben, bevor Sie umfangreiche Aufgaben ausführen. Wenn sich der Besitz beim Start plötzlich ändert, stoppen Sie den Stack und ermitteln Sie, welcher Entrypoint, welche Wartungsaufgabe oder welche neu zugeordnete Identität die Änderung verursacht hat. Lassen Sie nicht zu, dass eine ungeklärte rekursive Besitzänderung eine große Bibliothek weiter erfasst.

Überprüfen Sie Abweichungen mit kleinen, wiederholbaren Tests

Führen Sie regelmäßig oder nach Aktualisierungen eine schlanke Berechtigungsprüfung durch: Prüfen Sie einige stabile Originale, einen aktuellen Upload, ein neu erzeugtes Derivat und alle eingebundenen externen Bibliotheken. Achten Sie auf unerwartete Besitzer, fehlenden Gruppenzugriff, schreibgeschützte Mounts, die beschreibbar geworden sind, oder ACLs, die nicht mehr wie erwartet vererbt werden.

Führen Sie anschließend einen End-to-End-Schreibtest durch. Laden Sie über den normalen Client ein entbehrliches Element hoch, lassen Sie Immich es verarbeiten, öffnen Sie es und löschen Sie es über die Anwendung. Wenn externe Bibliotheken oder Importpfade Teil Ihrer Einrichtung sind, fügen Sie über diese Pfade jeweils eine repräsentative Datei hinzu und bestätigen Sie, dass Immich sie lesen kann, ohne den Besitz unerwartet zu ändern.

Die Präventionsschleife ist erst abgeschlossen, wenn neue Dateien auch nach einem Neustart von Immich und einem Neustart des Hosts weiterhin die vorgesehene Identität und den vorgesehenen Zugriff erhalten. Wenn die Berechtigungen nach einem dieser Ereignisse manuell repariert werden müssen, weicht das System weiterhin ab. Beheben Sie die Regel für die Dateierstellung oder die Identitätszuordnung, bevor Sie den Zugriff ausweiten.