Kann Immich eine externe Bibliothek verwenden, ohne die Kontrolle über die Dateien zu übernehmen?

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.

Ja. Immich kann eine externe Bibliothek indizieren, während die Originaldateien außerhalb von Immich verwaltet werden. Binden Sie sie schreibgeschützt ein, wenn Immich die Quelle weder umbenennen noch löschen darf.

Das wird zu einer echten Kompatibilitätsfrage, wenn Familienfotos bereits in einer gepflegten NAS-Struktur liegen und Immich Suche und Browsing hinzufügen soll, ohne zum Manager der maßgeblichen Dateien zu werden. Beginnen Sie mit einem entbehrlichen Pfad oder Konto, halten Sie den zuvor funktionierenden Zustand verfügbar und beurteilen Sie das Design anhand der ursprünglichen Arbeitslast statt anhand eines einmaligen Verbindungstests.

Unterstützte Architektur und riskante Variante getrennt betrachten

Der unterstützte Zweig ist eine schreibgeschützte externe Bibliothek mit separaten beschreibbaren Uploads und eigenem Anwendungsstatus. Die konkurrierende Variante ist eine beschreibbare Quell-Einbindung, die mit von Immich verwaltetem Upload-Speicher verwechselt wird. Dokumentieren Sie Versionen, Identitäten, Adressen, Einbindungspfade, Berechtigungen und den aktuell beobachtbaren Zustand, bevor Sie einen der beiden Zweige ändern.

Die relevanten externen Immich-Bibliotheken definieren die erste Kompatibilitätsgrenze. Nutzen Sie sie, um die Aussage einzugrenzen, und überprüfen Sie anschließend dasselbe Verhalten auf genau diesem Heimserver, statt eine dokumentierte Funktion als Beweis dafür zu betrachten, dass das gesamte Design funktioniert.

Formulieren Sie die Entscheidungsregel vor dem Test: Der Erfolg muss darin bestehen, dass Assets indiziert und angezeigt werden, während die Originale ihre Pfade, Hashes, Eigentümer und ihren Löschschutz behalten. Ein Fehlschlag liegt vor, wenn beim Scan Berechtigungen fehlen, Bearbeitungen Schreibvorgänge an der Quelle voraussetzen oder eine Aktion das Original löschen oder umbenennen kann. So wird verhindert, dass eine teilweise Verbindung oder ein sauberer Befehlsabschluss fälschlich als Kompatibilität von Ende zu Ende gewertet wird.

Exakten Speicher- und Netzwerkpfad reproduzieren

Verwenden Sie einen kontrollierten Unterscheidungstest: Binden Sie einen kleinen repräsentativen Ordner schreibgeschützt ein, erstellen Sie die externe Bibliothek, führen Sie einen Scan durch, bearbeiten Sie Metadaten in Immich und testen Sie das Löschen sowie das Umbenennen im Dateisystem. Halten Sie Client, Arbeitslast, Dateisatz, Konto und Zeitplanung konstant, damit die geänderte Komponente die einzige plausible Erklärung bleibt.

Verwenden Sie schreibgeschützte Volume-Einbindungen, um die zweite für diesen Pfad relevante Beobachtung auszuwählen. Erfassen Sie beide Seiten der Transaktion: Resolver oder Route, ausgehandeltes Protokoll, Prozessidentität, Exit-Status, Latenz, übertragene Bytes und jedes Wiederherstellungsereignis.

Wiederholen Sie den Test nach dem im Titel genannten Lebenszyklusereignis – Neuerstellung, erneuter Verbindung, erneuter Einbindung, Neustart, Failover oder Client-Wechsel. Ein Design, das nur funktioniert, solange alte Sockets, Caches oder Anmeldedaten noch aktiv sind, hat den Test nicht bestanden.

mount /photos:/external:ro -> Pilotordner scannen -> Hashes vergleichen -> Verhalten bei Metadatenbearbeitung und Löschen testen

Ergebnisse zu Dauerhaftigkeit, Zeitüberschreitungen und Wiederherstellung interpretieren

BESTANDEN: Assets werden indiziert und angezeigt, während die Originale ihre Pfade, Hashes, Eigentümer und ihren Löschschutz behalten. Speichern Sie die genauen Versionen und die Topologie, unter denen dieser Zustand erreicht wurde, denn die Schlussfolgerung gilt für diese Bedingungen und nicht für jede Implementierung des Protokolls.

FEHLGESCHLAGEN: Beim Scan fehlen Berechtigungen, Bearbeitungen setzen Schreibvorgänge an der Quelle voraus oder eine Aktion kann das Original löschen oder umbenennen. Prüfen Sie gemeinsame Abhängigkeiten wie DNS, MTU, Identität, Firewall-Status, Speicherlatenz und zwischengespeicherte Sitzungen, bevor Sie einen der beiden Hauptzweige als Ursache festlegen.

AUSNAHME: Entfernen Sie die Bibliotheksdefinition, ohne Dateien zu löschen, stellen Sie die vorherige Einbindung wieder her und korrigieren Sie den schreibgeschützten Pfad sowie die Identitätszuordnung. Erweitern Sie keine Berechtigungen, löschen Sie keine Quelldaten, schwächen Sie nicht die Transportsicherheit und ersetzen Sie keinen funktionierenden Speicher, bevor eine wiederholbare Beobachtung zeigt, welche Grenze fehlgeschlagen ist.

Design erst nach einer wiederherstellungsfähigen Prüfung beibehalten

Wenden Sie nur die zur beobachteten Variante passende Maßnahme an und führen Sie anschließend die ursprüngliche Arbeitslast erneut aus. Behalten Sie das Design nur bei, wenn Assets indiziert und angezeigt werden, während die Originale ihre Pfade, Hashes, Eigentümer und ihren Löschschutz über zwei relevante Lebenszykluszyklen hinweg und unter der erwarteten gleichzeitigen Last behalten.

Nutzen Sie die schreibgeschützten Immich-Quellen, um den am stärksten abhängigen Arbeitsablauf zu überprüfen. Dessen Zugriffs-, Timing- und Wiederherstellungsverhalten muss unverändert bleiben, während das neue Design aktiv ist.

Stoppen Sie und kehren Sie zum gespeicherten Zustand zurück, wenn beim Scan Berechtigungen fehlen, Bearbeitungen Schreibvorgänge an der Quelle voraussetzen oder eine Aktion das Original löschen oder umbenennen kann. Eskalieren Sie mit Zeitstempeln, genauen Versionen, Belegen zu Route oder Einbindung und der kleinsten Reproduktion, statt einen weiteren Workaround hinzuzufügen.

Gleichen Sie das Ergebnis mit den getrennten Fotokonten ab, damit das Risiko nicht lediglich in eine andere Netzwerk-, Identitäts-, Backup- oder Speicherebene verlagert wird.

Für die Eigentümerschaft externer Immich-Bibliotheken lautet die qualifizierte Antwort daher wie eingangs beurteilt – kein uneingeschränktes Ja. Der beobachtbare Erfolgszustand ist die Abnahmelinie; der Fehlerzustand ist die Rücksetzlinie.

FAQ

Löscht das Entfernen einer externen Bibliothek die Originale?

Es sollte indizierte Datensätze statt Quelldateien entfernen. Überprüfen Sie das aktuelle Verhalten jedoch zunächst an einem entbehrlichen Ordner.

Wo werden von Immich erzeugte Vorschaubilder gespeichert?

Im von Immich verwalteten beschreibbaren Speicher, nicht in der schreibgeschützten externen Bibliothek.

Können Uploads und externe Assets gemeinsam angezeigt werden?

Ja, sofern ihre Lebenszyklus- und Backup-Richtlinien getrennt bleiben und sich die Pfade nicht überschneiden.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.