Nettailor.net

Immich Foto-Workflow

7 Min. Lesezeit

Immich Foto-Workflow – Dokumentation (Stand: Juli 2026, Immich v3.0.1)

1. Zielsetzung

Immich läuft auf der Synology (Host: Mimir) als zentrale Verwaltung für das private Foto-Archiv. Die Originaldateien bleiben dabei bewusst im normalen DSM-Freigabekonzept (/volume1/photo/...) statt in einem Immich-eigenen Datensilo, damit Synology Drive, SMB-Zugriffe und Backups weiter normal funktionieren. Immich greift nur lesend/verwaltend darauf zu, die eigentliche Bild- und Video-Bearbeitung passiert extern auf dem Mac.

2. Architektur

Container (docker-compose Stack immich, /volume1/docker/immich)

ContainerRolle
immichImmich Server (Web-UI, API), Image: ghcr.io/immich-app/immich-server:release, aktuell v3.0.1
immich-machine-learningGesichtserkennung, CLIP-Suche etc.
immich_dbPostgres mit Vektor-Erweiterung. Seit dem v3-Update auf ghcr.io/immich-app/postgres:16-vectorchord0.3.0-pgvectors0.3.0 (vorher tensorchord/pgvecto-rs, jetzt VectorChord)
immich_redisJob-Queue / Cache
immich_folder_album_creatorDrittanbieter-Tool (salvoxia), erstellt automatisch die Alben Transfer und Archiv aus der External-Library-Struktur. Läuft wieder (v3-kompatibles Release), siehe Punkt 5.

Datenhaltung

Zwei getrennte Kategorien von Daten:

  • Immich-interne Daten (/volume1/docker/immich/db für die DB, /volume1/docker/immich/data für Thumbnails, encodierte Videos, Library-Metadaten, Backups und rohe Uploads): Nicht für manuellen Zugriff gedacht, muss aber dauerhaft gemountet bleiben (siehe Warnung in Punkt 3).
  • Foto-Originale (/volume1/photo/...): normaler DSM-Share, den Immich nur über External Libraries einliest.

3. Ordnerkonzept

Pfad (Host)Mount im ContainerModusRolle
/volume1/docker/immich/data/usr/src/app/uploadread-writePflicht-Mount. Enthält thumbs/, library/, encoded-video/, profile/, backups/ und upload/ – die komplette interne Persistenz von Immich, nicht nur App-/Web-Uploads. Ohne diesen Mount startet der Container nicht (siehe Warnung unten).
/volume1/photo/Transfer/usr/src/app/external/Transferread-onlySammelordner. Familie lädt hier unsortierte, unbearbeitete Handy-/DSLR-Fotos hoch. Auch Philipps eigenes Handy-Backup läuft jetzt hierüber (automatisches Synology-Drive-Backup wurde deaktiviert).
/volume1/photo/Fotos/usr/src/app/external/Archivread-onlyFinales, kuratiertes Foto-Archiv nach Jahr/Anlass sortiert. Einzige “dauerhafte” Ablage.

Transfer und Archiv sind bewusst read-only, damit Immich strukturell keine Originaldateien löschen oder verändern kann – das passiert ausschließlich über File Station/SMB von außen. Beide externen Bibliotheken werden in Immich unter Administration → External Libraries eingebunden und per Scan Library Files aktualisiert, nachdem außerhalb von Immich Dateien verschoben wurden.

Warnung: Der upload-Mount darf NICHT entfernt werden, auch wenn kein App-/Web-Upload genutzt wird. Er ist der Wurzelordner für die gesamte interne Storage-Persistenz. Wird er entfernt, verliert der Container beim Neustart Zugriff auf thumbs/, library/, encoded-video/ etc. und hängt in einer Crash-Loop beim Startup-Integritätscheck (ENOENT ... encoded-video/.immich). Der separate PhotoBackup-Mount (Synology Drive) ist dagegen tatsächlich obsolet, da das automatische Handy-Backup jetzt über Transfer läuft.

Ausschlussmuster (External Libraries)

Beide Libraries (Transfer, Archiv) nutzen dieselben Ausschlussmuster, um System-/App-Artefakte von Synology, macOS, Windows und Syncthing beim Scan zu ignorieren:

**/@eaDir/**
**/._*
**/#recycle/**
**/#snapshot/**
**/.stversions/**
**/.stfolder/**
**/Thumbs.db
**/.DS_Store
**/.Spotlight-V100/**
**/.fseventsd/**
**/.Trashes/**
**/desktop.ini
**/.dtrash/**

Hintergrund: .dtrash, .Spotlight-V100 und .fseventsd lagen konkret im /volume1/photo-Root (macOS erzeugt Spotlight/FSEvents-Ordner automatisch auf jedem per SMB gemounteten Volume – relevant, da der Sichtungs-/Bearbeitungsworkflow jetzt über den Mac läuft). Thumbs.db/desktop.ini und .Trashes sind vorsorglich für Windows- bzw. macOS-Zugriffe anderer Familienmitglieder ergänzt.

4. Workflow (Ende-zu-Ende)

  1. Aufnahme/Backup: Handy- und DSLR-Fotos landen unsortiert in /volume1/photo/Transfer (Familie lädt manuell hoch, Philipps Handy sichert automatisch über Synology Drive ebenfalls dorthin).
  2. Vorauswahl in Immich: External-Library-Scan macht die Fotos in Immich sichtbar. Dort werden sie bewertet (Sterne/Favoriten), grob gesichtet – alles reine Datenbank-Metadaten, die Originaldatei bleibt unangetastet (Mount ist read-only).
  3. Sichtung/Culling in XnViewMP: Der Transfer-Ordner wird zusätzlich per SMB (read-write) auf dem Mac in XnViewMP eingebunden. Dort erfolgt die eigentliche Auswahl und das Löschen schlechter Aufnahmen.
  4. Bearbeitung in Affinity: Ausgewählte Fotos werden in Affinity Photo bearbeitet (RAW-Entwicklung, Anpassungen, Export).
  5. Archivierung: Fertige Bilder werden aus Affinity bzw. per File Station nach /volume1/photo/Fotos/<Jahr>/<Anlass>/... verschoben.
  6. Finale Verwaltung in Immich: Nach erneutem Scan der Archiv-Library erscheinen die finalen Bilder dort dauerhaft – Alben, Gesichtserkennung, Teilen, Suche laufen ab jetzt in Immich.

5. Album-Creator: wieder aktiv

immich_folder_album_creator war nach dem v3-Upgrade zwischenzeitlich funktionsunfähig (Pydantic-Validierungsfehler beim Abruf der Assets), da die zugrunde liegende Python-Library immichpy erst am 01.07.2026 in v5.0.0 v3-Support nachgezogen hat. Bug-Tracking dazu: GitHub Issue #291.

Status (05.07.2026): behoben und verifiziert. Neues Image (salvoxia/immich-folder-album-creator:latest) unterstützt Immich v3. Ein Dry-Run zeigte zunächst “0 albums identified” bei nur 127 gefundenen Assets – das war kein Fehler: Die Alben Transfer und Archiv existierten bereits aus einem früheren erfolgreichen Lauf, der Dry-Run meldet nur neu vorzuschlagende Alben. Per Live-Test (4 Testfotos hochgeladen, nächster Cron-Lauf abgewartet) bestätigt, dass der Sync tatsächlich aktiv läuft und nicht nur ein eingefrorener alter Stand ist (Details siehe unten).

Zusätzlich wurde der Mount des Album-Creator-Containers von einem flachen Mount (/volume1/photo:/usr/src/app/external) auf dieselbe Alias-Struktur wie beim Immich-Server umgestellt, damit beide Container exakt dieselbe Ordneransicht haben:

    volumes:
     - /volume1/docker/immich/data/secret.file:/immich_api_key.secret:ro
     - /volume1/photo/Transfer:/usr/src/app/external/Transfer:ro
     - /volume1/photo/Fotos:/usr/src/app/external/Archiv:ro

Live-Test bestätigt Sync funktioniert: 4 Testfotos in Transfer hochgeladen, nach dem nächsten stündlichen Cron-Lauf zeigte das Album Transfer kurzzeitig 6.659 Assets statt der erwarteten 6.559 (Library: 6.306 Fotos + 253 Videos). Ursache war kein Bug im Album-Creator, sondern 100 alte, im Papierkorb liegende Karteileichen-Assets (aus dem “Alle löschen” der 127 fehlenden Dateien, siehe Integritätsbericht unten), die bis zum endgültigen Leeren des Papierkorbs weiter als Album-Mitglieder gezählt wurden. Nach Papierkorb leeren stand das Album korrekt bei 6.559 – exakter Match mit der Library. Der Album-Creator hält Transfer/Archiv also zuverlässig aktuell.

5a. Integritätsbericht: Aufräumen alter Karteileichen (Immich 3.0 Feature)

Beim Testen des Album-Creators fiel unter Administration → Wartung/Integritätsbericht (neues v3-Feature) Folgendes auf:

  • 127 “Fehlende Dateien”: DB-Einträge für Assets unter dem alten, längst gelöschten internen Upload-Pfad (/usr/src/app/upload/upload/d9da087b-1653-41aa-a9e4-5a54c5d3add3/...) aus der Zeit vor der Umstellung auf reine External Libraries (siehe ursprünglicher Perplexity-Workflow). Die Originaldateien wurden damals per rm direkt gelöscht, nicht über Immich selbst – dadurch blieben die DB-Referenzen zurück.
  • 2 “Nicht getrackte Dateien”: umgekehrter Fall – zwei verwaiste encoded-video-Dateien (Motion-Photo-Begleitvideos, *-MP.mp4) zu denselben alten Assets, die beim damaligen rm des upload/-Unterordners nicht mit gelöscht wurden, da encoded-video/ ein Geschwisterordner von upload/ ist (nicht darin verschachtelt).

Aufräumen (erledigt):

  1. “Alle löschen” bei den 127 fehlenden Dateien geklickt – das verschiebt die Assets aber nur in den Papierkorb (Soft-Delete), löscht sie nicht endgültig.
  2. Die 2 verwaisten encoded-video-Dateien manuell per SSH gelöscht.
  3. Papierkorb geleert – erst danach waren die Karteileichen wirklich weg (siehe Album-Sync-Test oben, der zeigte, dass Album-Mitgliedschaft bis zum endgültigen Löschen bestehen bleibt).

Alle drei Wartungszähler stehen jetzt bei 0.

6. Änderungshistorie

  • Juli 2026, Immich v2 → v3 Upgrade: DB-Migration von pgvecto.rs auf VectorChord (ghcr.io/immich-app/postgres:16-vectorchord0.3.0-pgvectors0.3.0). Server/ML-Container auf v3.0.1.
  • Juli 2026, Konfigurationsbereinigung:
    • :ro bei Transfer- und Archiv-Mount ergänzt (vorher fehlte der Schreibschutz – Immich hätte Originaldateien löschen/ändern können).
    • Automatisches Handy-Backup über Synology Drive (PhotoBackup) deaktiviert, läuft jetzt über Transfer.
    • Korrektur: Der interne upload-Mount wurde versehentlich entfernt in der Annahme, er sei nur für App-/Web-Uploads da. Tatsächlich ist er die Wurzel für die komplette interne Persistenz (thumbs/library/encoded-video/profile/backups) – Entfernen führte zu einer Crash-Loop beim Container-Start. Mount wieder ergänzt, Container läuft seitdem wieder normal.
    • Bearbeitungs-Tools gewechselt: ACDSee → XnViewMP (Sichtung/Culling) + Affinity Photo (Bearbeitung), beide auf dem Mac.
    • Alter Perplexity-Chat-Verlauf (enthielt DB-Passwort im Klartext) gelöscht, dieses Dokument ist jetzt die aktuelle Referenz.
  • Juli 2026, Album-Creator-Fix: immich_folder_album_creator war wegen v3-Inkompatibilität vorübergehend gestoppt, läuft mit neuem Image wieder. Alben Transfer/Archiv sind vollständig synchron mit den Libraries (per Live-Test verifiziert). Mount an Immich-Server-Aliasing angeglichen (siehe Punkt 5).
  • Juli 2026, Karteileichen-Cleanup: Über den neuen Immich-3.0-Integritätsbericht 127 alte, verwaiste Asset-DB-Einträge (aus der Vor-External-Library-Ära) sowie 2 verwaiste Motion-Photo-Videodateien gefunden und bereinigt, inkl. Papierkorb-Leerung (siehe Punkt 5a).
  • Juli 2026, Ausschlussmuster ergänzt: Thumbs.db, .DS_Store, .Spotlight-V100, .fseventsd, .Trashes, desktop.ini und .dtrash zu den External-Library-Ausschlussmustern hinzugefügt (siehe Punkt 3).

7. Empfehlungen / Beobachtungsposten

Neu in Immich 3.0 – Workflows (Preview-Feature): Unter Utilities → Workflows gibt es ab v3.0 einen visuellen Automatisierungs-Baukasten (Trigger → Filter/Bedingungen → Actions), inkl. JSON-Editor zum Teilen von Workflows. Das Feature ist explizit als experimentell/Preview markiert und kann sich noch ändern; aktuell nur im Web-UI verfügbar, Mobile-Unterstützung ist in Arbeit. Die konkrete Liste der verfügbaren Trigger/Actions habe ich nicht im Detail geprüft (Doku dazu ist noch dünn) – lohnt sich aber, selbst mal unter Utilities → Workflows reinzuschauen, ob sich z.B. das manuelle “Sterne setzen → Album zuordnen” aus Phase 2 teilweise automatisieren lässt. Eher als Beobachtungsposten sehen, nicht produktiv auf ein Preview-Feature bauen, solange sich die API/Struktur noch ändern kann.

Neu in Immich 3.0 – Integrity Checks: Der Server kann Speicherverzeichnisse gegen die Datenbank abgleichen und meldet nicht erfasste Dateien, fehlende Dateien oder Checksummen-Abweichungen. Da der Workflow viel manuelles Verschieben außerhalb von Immich beinhaltet (File Station, Affinity-Export), lohnt es sich, das nach größeren manuellen Umzügen als Kontrolle laufen zu lassen, um verwaiste DB-Referenzen oder vergessene Dateien zu finden. Vermutlich unter Administration → Jobs/Maintenance zu finden; UI selbst noch nicht geprüft.

Sonstiges aus v3.0, ohne direkten Bezug zum Workflow, aber erwähnenswert: Non-destructive Editing jetzt auch mobil (Crop/Rotate/Anpassungen reversibel, auch vom Web aus bearbeitbar), OCR in der Mobile-App, neue “Recently Added”-Ansicht (sortiert nach Import- statt Aufnahmedatum).

Quellen

Graphansicht

Backlinks