Immich zeigt nach einer Änderung des Speicherpfads veraltete Daten an

Veraltete Immich-Daten nach einer Änderung des Speicherpfads können drei unterschiedliche Ursachen haben, die nicht miteinander vermischt werden sollten: eine Verschiebung des verwalteten Medien-Stammverzeichnisses, eine Änderung des Importpfads einer externen Bibliothek oder ein Client, der weiterhin einen zwischengespeicherten Zustand anzeigt. Moderne Immich-Versionen können einen verschobenen Speicherort für verwaltete Medien abgleichen, wenn der konfigurierte Medienspeicherort und der Volume-Mount konsistent bleiben. Verschiebungen externer Bibliotheken können dagegen weiterhin als neue Asset-Identitäten behandelt werden.

Bewahre den alten Pfad und die Datenbank auf, bevor du einen erneuten Scan durchführst. Prüfe zunächst, welchen Pfad der laufende Container tatsächlich sieht, und ermittle dann, ob der serverseitige Immich-Eintrag fehlerhaft ist oder nur ein einzelner Client veraltete Daten anzeigt. Diese Unterscheidung entscheidet darüber, ob du einen Mount reparieren, einen stabilen, für den Container sichtbaren Pfad wiederherstellen, eine Test-Teilmenge neu scannen oder nur den Client-Cache leeren solltest.

Eine Verschiebung des verwalteten Medienstammverzeichnisses von einer Verschiebung einer externen Bibliothek unterscheiden

Wenn du den Speicherort für von Immich verwaltete Uploads auf dem Host geändert hast, überprüfe, ob die effektive Einstellung für den Medienspeicherort und der Mount vom Host in den Container gemeinsam geändert wurden. Eine moderne Verschiebung verwalteter Medien sollte nicht auf dieselbe Weise diagnostiziert werden wie die Umbenennung eines Importpfads einer externen Bibliothek.

Die Übersicht zum persistenten Immich-Zustand von ZimaSpace ist hier hilfreich, da Datenbank und Dateisystempfade eine gemeinsame Wiederherstellungsgrenze bilden. Die richtigen Dateien auf dem Host reichen nicht aus, wenn der Container an einer anderen Stelle eingebunden ist.

Wenn das Stammverzeichnis der verwalteten Medien nicht übereinstimmt, korrigiere zuerst die Umgebung und die Volume-Zuordnung und starte den Dienst neu, bevor du Bibliotheksaufträge ausführst. Wenn der geänderte Pfad zu einer externen Bibliothek gehört, lasse die Datenbank unverändert und teste diesen Fall separat.

Den für den Container sichtbaren Pfad der externen Bibliothek möglichst stabil halten

Bei einer externen Bibliothek ist eine Verschiebung des Speichers auf dem Host am sichersten, wenn der für den Container sichtbare Importpfad unverändert bleiben kann. Wenn sich der für Immich sichtbare Pfad ändert, notiere vor einem Scan eine kleine Auswahl von Asset-IDs, Alben, Personen und alten Pfaden, damit du feststellen kannst, ob vorhandene Assets neu verknüpft oder neu erstellt wurden.

Ein Bericht zur Pfadänderung einer externen Bibliothek in Immich beschrieb, dass verschobene Dateien als neue Assets behandelt wurden und die erneute Verarbeitung sowie der Verlust ausschließlich in Immich gespeicherter Beziehungen die Folge waren. Es handelt sich um einen versionsabhängigen Fall, der jedoch die vorsichtige Regel bestätigt, dass ein geänderter Pfad einer externen Bibliothek nicht automatisch als transparente Umbenennung gilt.

Wenn eine Test-Teilmenge als neue Assets erscheint, während die alten Einträge als fehlend oder gelöscht markiert werden, beende den vollständigen erneuten Scan. Stelle nach Möglichkeit den alten, für den Container sichtbaren Pfad wieder her oder verwende einen für deine Version geeigneten Migrationsansatz. Produktionsdatenbankpfade solltest du nicht ohne getestete Sicherung manuell umschreiben.

Verwechsle diesen Fall nicht mit einer Migration der Speichervorlage für von Immich verwaltete Dateien. Das Symptom kann in der Zeitleiste ähnlich aussehen, aber die Eigentumsverhältnisse der Dateien und der unterstützte Migrationsweg unterscheiden sich.

Gespeicherte Serverpfade vom Client-Cache unterscheiden

Öffne dasselbe bekannte Asset im Webclient und in einem weiteren authentifizierten Client und vergleiche dies mit den Serverprotokollen oder dem für den Server sichtbaren Pfad. Wenn serverseitige Aufträge weiterhin den alten Pfad nennen, kann das Leeren des Browser-Caches den zugrunde liegenden Eintrag nicht reparieren.

Ein späterer Bericht zu einem veralteten Pfad in Immich zeigte, dass die Verarbeitung nach einer Umbenennung weiterhin auf einen früheren Pfad der externen Bibliothek verwies. Das ist ein deutlicher Hinweis darauf, zunächst die pfadbezogenen Aufträge zu prüfen, bevor die mobile oder Weboberfläche verantwortlich gemacht wird.

Wenn der Serverpfad korrekt ist, aber nur eine Webansicht veraltete Daten zeigt, aktualisiere diese Ansicht oder leere den Cache des betreffenden Clients und teste die ursprüngliche Datei erneut. Zwischengespeicherte Vorschaubilder und ein veralteter Client-Zustand können einen reparierten Server fehlerhaft erscheinen lassen, während eine zwischengespeicherte Vorschau einen fehlerhaften Serverpfad auch korrekt aussehen lassen kann.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Die kleinste Pfadgrenze reparieren und einen kontrollierten erneuten Scan validieren

Nimm eine einzige reversible Korrektur vor: Synchronisiere die Einstellung für verwaltete Medien mit dem Mount, stelle den früheren Pfad der externen Bibliothek im Container wieder her, korrigiere einen Importpfad oder leere den Cache eines einzelnen Clients. Erstelle vor jeder Maßnahme, durch die eine große Bibliothek erneut erkannt werden könnte, eine Datenbanksicherung.

Führe den kleinstmöglichen praktikablen erneuten Scan durch und beobachte, ob die vorhandenen Einträge weiterhin zugeordnet bleiben, Fehler mit alten Pfaden aufhören und keine Duplikate aus alten und neuen Assets entstehen. Öffne anschließend stichprobenartig die Originale, überprüfe die Beziehungen zu Alben und Personen, führe eine Suche aus und starte den Stack neu.

Leite den Fall weiter, wenn Einträge für alte und neue Pfade weiterhin gleichzeitig aktiv sind, eine große externe Bibliothek unerwartet erneut verarbeitet wird oder Beziehungen verschwinden, obwohl die Originale weiterhin lesbar sind. Bewahre die genaue Mount-Zuordnung vor und nach der Änderung, die Immich-Version, die betroffenen Asset-IDs, das Verhalten der Groß- und Kleinschreibung im Dateisystem sowie den Zeitstempel der Datenbanksicherung auf.