Wenn chown und chmod auf einem USB-Laufwerk scheinbar nichts bewirken, ermitteln Sie zunächst das Dateisystem. Die Antwort aus der Community vermutete NTFS oder exFAT. Das ist eine plausible Erklärung, da sich diese Dateisysteme bei nativen Unix-Eigentümern und -Berechtigungsbits nicht wie ext4/Btrfs verhalten.
Aus der Quelle geht nicht hervor, welches Dateisystem MikeFrizz tatsächlich verwendet hat, und der ursprüngliche Verfasser meldete kein bestätigtes Ergebnis zurück. Daher sollte dies als dateisystemspezifischer Leitfaden zur Fehlerbehebung verstanden werden und nicht als Aussage, dass jedes ZimaOS-USB-Laufwerk Berechtigungen ignoriert.
USB-Dateisystem vor dem Ändern von Berechtigungen ermitteln
Prüfen Sie das Datenträgerformat in ZimaOS unter „Speicher“ oder mit einem schreibgeschützten Befehl wie:
lsblk -fDas aktuelle ZimaOS unterstützt unter anderem Lese- und Schreibzugriff auf NTFS, exFAT, ext4 und Btrfs. „Lese-/Schreibzugriff unterstützt“ bedeutet jedoch nicht, dass alle Dateisysteme Unix-UID-/GID-/Berechtigungsmetadaten auf dieselbe Weise speichern.
Verwenden Sie die aktuelle Matrix der unterstützten Datenträgerformate.
NTFS und exFAT stellen Berechtigungen häufig über Einhängeoptionen bereit
Unter Linux stellen exFAT und viele NTFS-Einhängekonfigurationen Dateien mit Eigentümer- und Berechtigungswerten bereit, die aus Einhängeoptionen abgeleitet werden, anstatt gewöhnliche POSIX-Berechtigungsänderungen genau wie ext4 zu speichern. Daher kann chown oder chmod scheinbar wirkungslos sein oder nach dem erneuten Einhängen zurückgesetzt werden.
Das bedeutet nicht, dass das Laufwerk schreibgeschützt oder defekt ist.
Ein Linux-Dateisystem bietet Docker die berechenbarsten POSIX-Berechtigungen
Wenn das USB-Laufwerk ausschließlich für ZimaOS/Linux verwendet wird und Sie eine echte Kontrolle über UID/GID und Berechtigungen benötigen, sind ext4 oder Btrfs die naheliegendere Wahl. Eine Neuformatierung ist destruktiv. Kopieren Sie daher die Daten an einen anderen Ort, bevor Sie das Dateisystem ändern.
Host-Symlink nicht als primäre Migration des Docker-Speichers verwenden
Der Benutzer aus der Quelle kopierte Immich-Daten auf ein USB-Laufwerk und erstellte am alten Speicherort einen Symlink. Container folgen Host-Symlinks außerhalb ihres eingehängten Volume-Namensraums nicht automatisch. Der Symlink kann auf einen Pfad zeigen, den der Container nicht sehen kann.
Ein direktes Bind-Mount bzw. Volume ist übersichtlicher und leichter zu überprüfen.
USB-Ordner direkt in Immich einbinden
Statt einen alten Host-Pfad beizubehalten und ihn mit einem Symlink umzuleiten, bearbeiten Sie das Volume der Immich-App bzw. des Immich-Containers, sodass der tatsächliche USB-Ordner am von Immich erwarteten Container-Pfad eingebunden wird.
Die aktuelle Dokumentation von IceWhale erklärt, dass der Host-Pfad geändert werden kann, ohne den Pfad innerhalb des Containers zu ändern.
Verwenden Sie das aktuelle Modell der ZimaOS-Docker-Volume-Pfade.
Nicht blind jede Immich-Komponente auf beliebigen USB-Speicher verschieben
Für Immich-Medienbibliotheken und Upload-Speicher gelten andere Anforderungen als für die PostgreSQL-Datenbank und den Anwendungsstatus. Ermitteln Sie vor dem Verschieben von Verzeichnissen genau, welches Host-Volume verlagert wird, und befolgen Sie die aktuellen Anweisungen zur Bereitstellung und Migration von Immich.
Verschieben Sie kein aktives Datenbankverzeichnis per Symlink, während die Container ausgeführt werden.
Zuallererst die Zuordnung korrigieren, statt pauschal chmod 777 zu verwenden
Wenn der Container den richtigen Host-Ordner nicht sehen kann, lässt sich das Problem durch das Ändern von Berechtigungen nicht beheben. Überprüfen Sie zuerst die Einbindung und gewähren Sie dem Container anschließend nur den erforderlichen Benutzer-/Gruppenzugriff.
FAQ zu USB-Berechtigungen
Unterstützt ZimaOS Lese- und Schreibzugriff auf NTFS und exFAT?
Ja. In der aktuellen Dokumentation von IceWhale werden beide als mit Lese- und Schreibzugriff unterstützt aufgeführt.
Warum können sich chmod und chown trotzdem anders verhalten?
Diese Dateisysteme verwenden native Linux-POSIX-Semantiken für Eigentümer und Berechtigungen nicht auf dieselbe Weise wie ext4 oder Btrfs.
Wurde das Dateisystem des Benutzers aus der Quelle und die endgültige Lösung bestätigt?
Nein. Das Dateisystem wurde aus einer Antwort in der Community abgeleitet, und der ursprüngliche Verfasser meldete kein Ergebnis zurück.
