Warum erstellt Immich fehlende Dateien mit dem falschen Besitzer neu?

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 Does Immich Recreate Missing Files With the Wrong Owner? - Zima Store Online

Immich sollte ein fehlendes Original nicht stillschweigend als allgemeine Wiederherstellungsfunktion neu erstellen. Wenn ein gelöschtes Objekt wieder auftaucht, ermitteln Sie zunächst, ob es sich um ein generiertes Vorschaubild, ein codiertes Video, ein Profilartefakt, eine XMP-Sidecar-Datei oder eine andere beschreibbare Datei handelt. Diese können von verschiedenen Prozessen neu erstellt oder geändert werden und dabei einen anderen Besitzer erhalten.

Verwenden Sie ein einzelnes, entbehrliches neu generiertes Objekt und dessen übergeordnetes Verzeichnis. Vergleichen Sie die numerischen UID/GID sowie die ACLs auf dem Host mit dem effektiven Schreiber innerhalb des Containers. Ermitteln Sie anschließend, ob Immich, eine Funktion zum Schreiben von Sidecar-Dateien, ein NAS-Protokoll oder ein anderer Host-Prozess die Datei tatsächlich erstellt hat. Vermeiden Sie rekursives chown oder chmod 777, bis dieser Schreiber bekannt ist.

Vergleichen Sie die neu erstellte Datei mit ihrem übergeordneten Verzeichnis und einer fehlerfreien Vergleichsdatei

Dokumentieren Sie Besitzer, Gruppe, Berechtigungen, gegebenenfalls erweiterte Attribute sowie die numerische UID/GID der neu erstellten Datei, ihres übergeordneten Verzeichnisses und einer älteren Datei, die korrekt funktioniert. Namen können über ein NAS und innerhalb eines Containers irreführend sein; numerische IDs zeigen, ob „immich“ auf einem System derselben Identität entspricht wie auf einem anderen.

Der ZimaSpace-Berechtigungsablauf für Dateien, die auf ein NAS verschoben wurden, ist direkt anwendbar: Neue Objekte werden durch die ACL des Zielorts, die Containeridentität, die Protokollzuordnung und die Erstellungsregeln bestimmt. Eine Ersatzdatei kann daher lesbar sein und dennoch einen Besitzer erhalten, der den Arbeitsablauf eines anderen Tools beeinträchtigt. Wenn die neu erstellte Datei der Vererbung des übergeordneten Verzeichnisses entspricht und nur der angezeigte Name ungewohnt aussieht, ordnen Sie zunächst die numerische ID zu, bevor Sie etwas ändern. Wenn sie sich sowohl von den Dateien im übergeordneten Verzeichnis als auch von den fehlerfreien Vergleichsdateien unterscheidet, untersuchen Sie weiter die Identität des Schreibers; das Problem kann innerhalb der Containerkonfiguration und nicht in der Dateisystem-ACL liegen.

Ermitteln Sie den Prozess und die effektive UID/GID, die den Ersatz schreibt

Lösen Sie eine sichere Neugenerierung aus, während Sie die relevanten Protokolle und das Dateisystem überwachen. Prüfen Sie den effektiven Benutzer und die Gruppen innerhalb des Containers, der den Schreibvorgang ausführt. Wenn stattdessen ein Sidecar-, Metadaten- oder Backup-Tool oder ein Host-Skript die Datei erstellt, untersuchen Sie diesen Dienst, anstatt die Laufzeitidentität von Immich zu ändern.

Der Besitz von Dateien in Containern wird numerisch und nicht anhand von Namen bestimmt. Eine Erklärung zum Dateibesitz in Docker zeigt, warum dieselbe eingebundene Datei auf dem Host und im Container unterschiedliche Benutzernamen anzeigen kann, wenn die UID/GID-Zuordnungen nicht übereinstimmen. Verwenden Sie numerische IDs als gemeinsame Referenz.

In einer Diskussion zum Besitz externer Bibliotheken bei Immich wurde dokumentiert, dass XMP-Sidecar-Dateien in einer Bereitstellung als root geschrieben wurden. Dies ist ein Beleg dafür, die effektive Identität des Schreibers und die unterstützte Laufzeitidentität zu prüfen, nicht die Behauptung, dass jede aktuelle Immich-Installation jede neu generierte Datei als root schreibt.

Wenn der Container absichtlich als nicht privilegierter Benutzer ausgeführt wird, stellen Sie sicher, dass die UID/GID tatsächlich auf dem Host oder NAS vorhanden ist und über die erforderlichen Zugriffsrechte auf den eingebundenen Pfad verfügt. Ein symbolischer Benutzername innerhalb eines Containers entspricht nicht automatisch einem Hostkonto mit demselben Namen.

Beheben Sie die Erstellungsregel, statt vorhandene Dateien wiederholt zu reparieren

Korrigieren Sie die kleinste bestätigte Grenze: Stimmen Sie, sofern unterstützt, die Dienst-UID/GID ab, reparieren Sie die Gruppen- oder ACL-Vererbung des übergeordneten Verzeichnisses, legen Sie eine geeignete umask fest oder ändern Sie die NAS-Freigabezuordnung, die die falsche Identität liefert. Erhalten Sie die Möglichkeit von Immich und allen anderen legitimen Lesern, auf Originale und generierte Dateien zuzugreifen.

Verwenden Sie weltweit beschreibbare Berechtigungen nicht als Standardreparatur. Dadurch wird die Identitätsabweichung verschleiert und der Schreibzugriff unnötig ausgeweitet. Ändern Sie außerdem nicht per einem einzigen Befehl rekursiv den Besitz von PostgreSQL, Modell-Cache, Uploads und externen Bibliotheken; diese Pfade können absichtlich unterschiedliche Dienstidentitäten verwenden.

Wenn eine externe Bibliothek unveränderlich sein soll, sollten Sie den Einhängepunkt schreibgeschützt bereitstellen und den von der Anwendung verwalteten beschreibbaren Zustand an anderer Stelle speichern, jedoch nur, wenn die von Ihnen verwendeten Funktionen dort keine Sidecar-Dateien schreiben müssen. Die Entscheidung betrifft den gewünschten Besitz und das Schreibverhalten, nicht den Zwang, dass jede Datei im Fotoarchiv demselben Konto gehören muss.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Erstellen Sie eine Datei erneut und überprüfen Sie sie nach einem Neustart

Entfernen Sie nur ein entbehrliches generiertes Objekt oder eine Test-Sidecar-Datei, die sicher neu erstellt werden kann, und lösen Sie anschließend exakt denselben Immich-Vorgang erneut aus. Prüfen Sie den neuen Besitzer, die Gruppe, die ACL und die Lesbarkeit sowohl in Immich als auch im zuvor fehlschlagenden anderen Programm. Lassen Sie die Originalmedien während dieses Tests unverändert.

Starten Sie den Container neu und führen Sie anschließend einmal einen Neustart des Hosts durch, um sicherzustellen, dass die korrigierte Identität und die Einbindungen Änderungen am Lebenszyklus überstehen. Eine erfolgreiche Reparatur erstellt die nächste Testdatei automatisch mit dem erwarteten Besitz; sie ist nicht von einem chown-Skript nach dem Start abhängig, das mit Schreibvorgängen von Immich konkurriert.

Beenden Sie den Dienst und stellen Sie die gesicherte Konfiguration wieder her, wenn sich Besitzänderungen unerwartet auf die Datenbank oder Originale ausweiten oder der Dienst nach dem Neustart den Lese-/Schreibzugriff verliert. Eskalieren Sie den Fall mit numerischen IDs, der ACL-Ausgabe, Einhängeoptionen, dem effektiven Containerbenutzer, dem Compose-Ausschnitt und dem genauen Dateityp, den Immich neu erstellt hat.