Bestehende Fotosammlungen per SMB, NFS und Docker einbinden
Wer Immich neu installiert, beginnt nur selten mit einer leeren Fotosammlung.
Auf einem NAS, einer USB-Festplatte oder einem klassischen Dateiserver liegen möglicherweise bereits zehntausende Fotos aus vielen Jahren. Häufig existiert dort sogar eine über lange Zeit gepflegte Verzeichnisstruktur:
Fotos ├── 2019 │ ├── Urlaub Italien │ ├── Weihnachten │ └── Geburtstag ├── 2020 ├── 2021 ├── 2022 ├── 2023 ├── 2024 ├── 2025 └── 2026
Diese Sammlung komplett in den von Immich verwalteten Upload-Speicher zu kopieren, ist nicht immer sinnvoll.
Bei mehreren Terabyte Fotos würde dadurch möglicherweise zunächst eine zweite vollständige Kopie des Archivs entstehen.
Immich bietet dafür eine wesentlich elegantere Möglichkeit:
External Libraries – externe Bibliotheken.
Damit kann Immich auf bereits vorhandene Verzeichnisse zugreifen, deren Fotos und Videos katalogisieren und sie anschließend innerhalb der Immich-Oberfläche anzeigen.
Das ursprüngliche Archiv kann dabei weiterhin auf dem NAS liegen.
In diesem Teil unserer Serie zeigen wir, wie solche externen Bibliotheken funktionieren, wie SMB- und NFS-Freigaben unter Linux eingebunden werden und worauf bei großen Fotoarchiven besonders geachtet werden sollte.
Was ist eine externe Immich-Bibliothek?
Eine externe Bibliothek enthält Fotos und Videos, die außerhalb des von Immich verwalteten Medienbereichs gespeichert sind.
Immich bekommt Zugriff auf das entsprechende Verzeichnis und scannt dessen Inhalt.
Vereinfacht sieht die Architektur so aus:
NAS
│
└── /Fotos
│
│ SMB oder NFS
▼
Immich-Server
│
└── /mnt/fotos
│
│ Docker Bind Mount
▼
Immich-Container
│
└── /mnt/media/fotos
│
▼
External Library
Immich liest anschließend die Mediendateien ein und erzeugt daraus die notwendigen Einträge für Timeline, Metadaten, Vorschaubilder und weitere Funktionen.
Die Originaldateien müssen dafür nicht in die normale Immich-Bibliothek kopiert werden.
Der entscheidende Unterschied zum normalen Upload
Bei einem normalen Upload übernimmt Immich die Mediendatei in seinen verwalteten Speicher.
Beispielsweise:
Smartphone
│
▼
Immich Upload
│
▼
Immich Storage
│
▼
Originaldatei
Bei einer externen Bibliothek bleibt die Datei dagegen an ihrem ursprünglichen Speicherort:
NAS
│
├── foto001.jpg
├── foto002.jpg
└── foto003.jpg
│
▼
Immich
liest Dateien
Damit eignet sich die Funktion hervorragend für bereits vorhandene Archive.
Warum externe Bibliotheken interessant sind
Externe Bibliotheken bieten mehrere Vorteile.
Ein bestehendes Archiv muss nicht vollständig reorganisiert werden.
Die ursprüngliche Verzeichnisstruktur kann erhalten bleiben.
Auch andere Programme können weiterhin auf die Dateien zugreifen.
Große Datenbestände müssen nicht erst in Immich kopiert werden.
Und vor allem:
Immich kann als komfortable Oberfläche über einem bereits vorhandenen Fotoarchiv eingesetzt werden.
Das ist besonders interessant für NAS-Besitzer.
Read-Only-Bibliotheken
Für bestehende Fotoarchive empfiehlt sich häufig ein Read-Only-Mount.
Immich darf die Originaldateien dann lesen, aber nicht verändern oder löschen.
Bei Docker wird dies über die Option:
:ro
realisiert.
Beispielsweise:
volumes: - /mnt/nas/fotos:/mnt/media/fotos:ro
Damit kann der Container auf die Dateien zugreifen, erhält aber nur Leserechte.
Das ist für historische Archive eine sehr interessante Sicherheitsmaßnahme.
Warum Read-Only sinnvoll sein kann
Angenommen, auf dem NAS befindet sich ein 20 Jahre altes Fotoarchiv:
/mnt/nas/fotos
Dieses Archiv wird zusätzlich von:
- Lightroom
- Dateifreigaben
- Backup-Software
- Familienmitgliedern
verwendet.
Immich soll lediglich eine moderne Oberfläche mit Timeline, Suche, Kartenansicht und KI-Funktionen bereitstellen.
Dann besteht normalerweise kein Grund, Immich Schreibrechte auf die Originaldateien zu geben.
Das Prinzip lautet:
Originalarchiv
│
│ READ ONLY
▼
Immich
Damit bleibt die Hoheit über die Originaldateien beim bestehenden Speichersystem.
Einschränkungen von Read-Only
Read-Only bedeutet allerdings tatsächlich Read-Only.
Immich kann in einer schreibgeschützt eingebundenen externen Bibliothek keine XMP-Sidecar-Dateien für Änderungen an den Originalmedien anlegen.
Änderungen an Metadaten sind daher entsprechend eingeschränkt.
Auch beim Löschen ist die Besonderheit wichtig:
Immich kann eine schreibgeschützte Originaldatei selbstverständlich nicht physisch vom NAS entfernen.
Read-Only eignet sich deshalb besonders für Archive, die Immich katalogisieren, anzeigen und durchsuchen, aber nicht verwalten soll.
NAS als zentraler Fotospeicher
Ein typisches Heimnetz könnte folgendermaßen aussehen:
Netzwerk
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
NAS Immich-Server PC
│ │
│ │
└──────┬────┘
│
▼
Fotoarchiv
Das NAS übernimmt dabei die Speicherung der Originaldateien.
Der Immich-Server übernimmt:
- Katalogisierung
- Timeline
- Suche
- Gesichtserkennung
- Smart Search
- Vorschaubilder
- Kartenansicht
- Weboberfläche
Damit werden Speicher- und Anwendungsserver logisch voneinander getrennt.
SMB oder NFS?
Für die Bereitstellung eines NAS-Verzeichnisses kommen im Linux-Umfeld hauptsächlich zwei Protokolle infrage:
SMB
und
NFS
SMB ist insbesondere in Windows-Umgebungen verbreitet.
NFS ist dagegen traditionell sehr stark in Linux- und Unix-Umgebungen vertreten.
Für einen Debian-Server können grundsätzlich beide Varianten verwendet werden.
SMB-Freigabe unter Debian einbinden
Für SMB beziehungsweise CIFS wird zunächst das entsprechende Paket benötigt:
sudo apt update sudo apt install cifs-utils
Anschließend wird ein Mountpunkt erstellt:
sudo mkdir -p /mnt/nas-fotos
Nehmen wir an, das NAS besitzt folgende Adresse:
192.168.10.20
und die SMB-Freigabe heißt:
Fotos
Ein manueller Test könnte beispielsweise folgendermaßen aussehen:
sudo mount -t cifs //192.168.10.20/Fotos /mnt/nas-fotos \ -o username=immich,vers=3.0
Das Passwort sollte für einen dauerhaften Betrieb nicht direkt in Skripten oder der /etc/fstab hinterlegt werden.
Zugangsdaten für SMB sicher speichern
Dafür kann beispielsweise eine Credentials-Datei verwendet werden:
sudo nano /root/.smb-immich
Inhalt:
username=immich password=SEHR_SICHERES_PASSWORT
Anschließend werden die Dateirechte eingeschränkt:
sudo chmod 600 /root/.smb-immich
Damit können nur entsprechend privilegierte Prozesse die Zugangsdaten lesen.
SMB automatisch über /etc/fstab mounten
Damit das NAS nach einem Neustart automatisch eingebunden wird, kann ein entsprechender Eintrag in:
/etc/fstab
erstellt werden.
Beispiel:
//192.168.10.20/Fotos /mnt/nas-fotos cifs credentials=/root/.smb-immich,vers=3.0,ro,_netdev 0 0
Danach:
sudo mount -a
Mit:
mount | grep nas-fotos
lässt sich kontrollieren, ob die Freigabe eingebunden wurde.
Das ro sorgt bereits auf Betriebssystemebene dafür, dass die Freigabe schreibgeschützt eingebunden wird.
NFS-Freigabe unter Debian einbinden
In einer reinen Linux- beziehungsweise Unix-Umgebung kann NFS eine attraktive Alternative sein.
Zunächst werden die benötigten Werkzeuge installiert:
sudo apt update sudo apt install nfs-common
Anschließend:
sudo mkdir -p /mnt/nas-fotos
Eine Freigabe könnte beispielsweise so eingebunden werden:
sudo mount -t nfs 192.168.10.20:/volume1/Fotos /mnt/nas-fotos
Ob der konkrete Exportpfad genauso lautet, hängt vom verwendeten NAS-System ab.
NFS dauerhaft einbinden
Auch eine NFS-Freigabe kann über /etc/fstab automatisch eingebunden werden.
Beispielsweise:
192.168.10.20:/volume1/Fotos /mnt/nas-fotos nfs ro,_netdev 0 0
Danach wieder:
sudo mount -a
und zur Kontrolle:
df -h
oder:
mount | grep nas-fotos
SMB oder NFS – was ist besser?
Eine allgemeingültige Antwort gibt es nicht.
In einer heterogenen Umgebung mit Windows-PCs und einem NAS ist SMB häufig ohnehin bereits vorhanden.
In einer Linux-zentrierten Infrastruktur bietet sich dagegen oft NFS an.
Wichtiger als die reine Wahl des Protokolls sind für Immich:
- stabile Verbindung
- ausreichende Übertragungsrate
- korrekte Berechtigungen
- zuverlässiges Mounting
- geringe Latenz
Für ein großes Fotoarchiv ist außerdem eine kabelgebundene Netzwerkverbindung dringend zu empfehlen.
NAS zuerst auf dem Host mounten
Eine übersichtliche Architektur besteht darin, die NAS-Freigabe zunächst auf dem Debian-Host einzubinden:
NAS
│
│ NFS / SMB
▼
Debian
│
└── /mnt/nas-fotos
│
│ Bind Mount
▼
Docker
│
▼
Immich
Dadurch kann bereits auf dem Host getestet werden, ob:
ls -la /mnt/nas-fotos
die erwarteten Dateien liefert.
Erst danach wird das Verzeichnis an den Immich-Container weitergereicht.
Das vereinfacht die Fehlersuche erheblich.
Docker Volume einrichten
Nun muss der immich-server-Container Zugriff auf das Verzeichnis erhalten.
Dazu wird die docker-compose.yml angepasst.
Der entsprechende Bereich kann beispielsweise so aussehen:
services:
immich-server:
volumes:
- ${UPLOAD_LOCATION}:/data
- /mnt/nas-fotos:/mnt/media/fotos:ro
Links steht der Pfad auf dem Docker-Host:
/mnt/nas-fotos
Rechts steht der Pfad innerhalb des Containers:
/mnt/media/fotos
Und:
:ro
setzt den Mount auf Read-Only.
Container neu erstellen
Nach der Änderung wird die Compose-Konfiguration übernommen:
docker compose up -d
Danach sollte kontrolliert werden, ob der Container das Verzeichnis tatsächlich sehen kann.
Beispielsweise:
docker exec -it immich_server bash
und anschließend:
ls -la /mnt/media/fotos
Werden hier die Fotos angezeigt, funktioniert die Verbindung grundsätzlich.
Ein häufiger Fehler: Hostpfad und Containerpfad
Hier entsteht besonders häufig Verwirrung.
Auf dem Debian-Server lautet der Pfad beispielsweise:
/mnt/nas-fotos
Im Container lautet er dagegen:
/mnt/media/fotos
In Immich muss anschließend der Containerpfad verwendet werden:
/mnt/media/fotos
und nicht:
/mnt/nas-fotos
Immich läuft innerhalb des Containers und kennt deshalb nur die dort sichtbaren Pfade.
Externe Bibliothek in Immich erstellen
Nachdem der Mount funktioniert, wird die Bibliothek in der Weboberfläche eingerichtet.
Als Administrator wird dazu die Verwaltung der externen Bibliotheken geöffnet.
Dort wird eine neue Bibliothek erstellt und einem Benutzer zugeordnet.
Anschließend wird der Importpfad eingetragen:
/mnt/media/fotos
Danach kann der Scan gestartet werden.
Immich beginnt nun, das Archiv einzulesen.
Eigentümer der Bibliothek
Eine wichtige Besonderheit:
Eine externe Bibliothek gehört einem bestimmten Immich-Benutzer.
Der Eigentümer wird beim Erstellen der Bibliothek festgelegt.
Diese Zuordnung sollte daher vorher durchdacht werden.
Bei einer Familieninstallation könnte beispielsweise ein Benutzer:
familienarchiv
für historische Familienbilder verwendet werden.
Alternativ wird die Bibliothek einem der bestehenden Benutzer zugeordnet und anschließend über Immich-Funktionen geteilt.
Mehrere Importpfade
Eine externe Bibliothek kann auch mehrere Importpfade enthalten.
Beispielsweise:
/mnt/media/fotos-alt /mnt/media/fotos-neu /mnt/media/videos
Damit können logisch zusammengehörende Bestände innerhalb einer Bibliothek zusammengeführt werden.
Trotzdem sollte nicht automatisch alles in eine einzige riesige Bibliothek geworfen werden.
Eine sinnvolle Struktur erleichtert später Wartung und Fehlersuche.
Bestehende Verzeichnisstruktur
Viele Anwender besitzen bereits eine Struktur nach Jahren:
Fotos ├── 2005 ├── 2006 ├── 2007 ├── ... ├── 2024 ├── 2025 └── 2026
Andere organisieren nach Ereignissen:
Fotos ├── Familie ├── Urlaub ├── Hochzeit ├── Geburtstage ├── Natur └── Reisen
Oder kombiniert:
Fotos
├── 2025
│ ├── 2025-04 Ostern
│ ├── 2025-07 Urlaub
│ └── 2025-12 Weihnachten
│
└── 2026
├── 2026-04 Ostern
└── 2026-08 Urlaub
Eine solche Struktur muss für eine externe Immich-Bibliothek nicht aufgegeben werden.
Immich scannt die darunterliegenden Mediendateien.
Ordnerstruktur ist nicht automatisch Albumstruktur
Hier lauert allerdings ein häufiges Missverständnis.
Ein Verzeichnis:
/2026/Urlaub Italien/
wird bei einer externen Bibliothek nicht automatisch zu einem klassischen Immich-Album namens:
Urlaub Italien
Immich weist ausdrücklich darauf hin, dass derzeit kein offizieller Mechanismus existiert, der eine vorhandene Ordnerstruktur externer Bibliotheken automatisch in Alben umwandelt.
Wer beim Import gezielt Alben anhand von Verzeichnisnamen erzeugen möchte, kann stattdessen die Immich CLI mit der entsprechenden Albumfunktion für Uploads verwenden.
Exclusion Patterns
Nicht jedes Verzeichnis eines bestehenden Fotoarchivs soll zwangsläufig von Immich verarbeitet werden.
Angenommen, das Archiv enthält:
Urlaub ├── JPEG ├── RAW └── Export
Die RAW-Dateien sollen nicht in Immich erscheinen.
Dafür können Ausschlussmuster verwendet werden.
Beispielsweise:
**/RAW/**
Dadurch kann die Bibliothek gescannt werden, ohne dass die entsprechenden Verzeichnisse berücksichtigt werden.
Das ist auch interessant für:
- temporäre Verzeichnisse
- Vorschaubilder
- Exporte
- Arbeitskopien
- RAW-Archive
- Cache-Verzeichnisse
Vorsicht bei Symlinks
Externe Bibliotheken sollten nicht über komplizierte symbolische Links konstruiert werden.
Immich empfiehlt ausdrücklich, bei Importbibliotheken keine Symlinks zu verwenden und insbesondere keine Links über unterschiedliche Docker-Mounts hinweg aufzubauen.
Besser ist eine klare Struktur:
NAS ↓ Host Mount ↓ Docker Mount ↓ External Library
Je einfacher diese Kette aufgebaut ist, desto leichter lässt sich ein Problem später nachvollziehen.
Was passiert beim Scan?
Beim ersten Scan muss Immich zunächst die Dateien entdecken.
Danach entstehen weitere Hintergrundaufgaben.
Dazu gehören unter anderem:
- Metadaten extrahieren
- Vorschaubilder erzeugen
- Machine-Learning-Aufgaben
- Gesichtserkennung
- Smart Search
Bei einer kleinen Sammlung fällt das kaum auf.
Bei:
150.000 Fotos
sieht die Situation völlig anders aus.
Große Archive richtig importieren
Ein sehr großes Archiv sollte geplant eingelesen werden.
Nehmen wir beispielsweise an:
Fotos: 120.000 Videos: 8.000 Datenmenge: 4 TB
Der eigentliche Dateiscan ist nur ein Teil der Arbeit.
Anschließend müssen zehntausende Hintergrundjobs abgearbeitet werden.
CPU, Speicher, Datenträger und Netzwerk können deshalb über längere Zeit stark belastet werden.
Erst mit einem Testverzeichnis beginnen
Bevor ein komplettes 4-TB-Archiv eingebunden wird, empfiehlt sich ein Test.
Beispielsweise:
/mnt/nas-fotos/Test
mit:
500 Fotos 20 Videos einigen RAW-Dateien verschiedenen Kameras unterschiedlichen Dateiformaten
Damit können zunächst geprüft werden:
- Berechtigungen
- EXIF-Daten
- Vorschaubilder
- Videos
- KI-Verarbeitung
- Netzwerkperformance
- Ausschlussmuster
Erst wenn alles funktioniert, sollte das vollständige Archiv folgen.
Verarbeitung beobachten
Während des Imports können die Immich-Jobs in der Administration beobachtet werden.
Dort lässt sich erkennen, welche Aufgaben noch aktiv oder ausstehend sind.
Auf dem Linux-Server helfen zusätzlich Werkzeuge wie:
htop
und:
docker stats
Bei NVIDIA-GPU-Beschleunigung kann zusätzlich beispielsweise:
nvidia-smi
interessant sein.
Damit wird schnell sichtbar, welcher Teil des Systems zum Flaschenhals wird.
Netzwerkperformance
Liegt das Archiv auf einem NAS, müssen beim ersten Scan große Datenmengen über das Netzwerk gelesen werden.
Bei einem Gigabit-Netzwerk liegt das theoretische Maximum bei:
1 Gbit/s ≈ 125 MB/s
In der Praxis liegt die tatsächliche Übertragungsrate darunter.
Bei mehreren Terabyte Daten kann der erste Durchlauf deshalb entsprechend lange dauern.
2,5-Gigabit- oder 10-Gigabit-Ethernet kann bei sehr großen Archiven einen deutlichen Unterschied machen.
WLAN vermeiden
Zwischen Immich-Server und NAS sollte möglichst keine WLAN-Verbindung liegen.
Ungünstig:
NAS ↓ WLAN ↓ Immich
Besser:
NAS │ │ Ethernet ▼ Switch │ │ Ethernet ▼ Immich
Insbesondere viele kleine Dateien können empfindlich auf Latenz und instabile Netzwerkverbindungen reagieren.
Datenbank nicht auf SMB oder NFS legen
Ein besonders wichtiger Punkt betrifft PostgreSQL.
Nur weil das Fotoarchiv auf einem NAS liegt, sollte nicht automatisch auch die Immich-Datenbank dort abgelegt werden.
Immich empfiehlt ausdrücklich, DB_DATA_LOCATION möglichst auf lokalem SSD-Speicher zu betreiben und nicht auf einem Netzwerk-Share.
Eine sinnvolle Architektur lautet daher:
NAS / HDD
│
└── Originalfotos
│
│ NFS / SMB
▼
Immich-Server
│
├── SSD
│ ├── PostgreSQL
│ └── schnelle Anwendungsdaten
│
└── Netzwerk-Mount
└── externes Fotoarchiv
Damit liegen große Originalbestände kostengünstig auf dem NAS, während die Datenbank von der niedrigen Latenz einer lokalen SSD profitiert.
Vorschaubilder auf schnellem Speicher
Auch Vorschaubilder werden sehr häufig gelesen.
Beim Scrollen durch die Timeline müssen nicht jedes Mal die riesigen Originaldateien vom NAS übertragen werden.
Immich verwendet dafür erzeugte Thumbnails beziehungsweise Preview-Dateien.
Bei großen Installationen kann es daher sinnvoll sein, solche häufig verwendeten Daten auf schnellem Speicher abzulegen.
Eine mögliche Speicherstrategie lautet:
NAS / HDD │ └── Originalfotos SSD │ ├── PostgreSQL └── Thumbnails / schnelle Immich-Daten
Das kann die gefühlte Geschwindigkeit der Weboberfläche deutlich verbessern.
Library Watching bei Netzwerkfreigaben
Immich besitzt eine experimentelle Funktion zum automatischen Beobachten externer Bibliotheken.
Dabei reagiert Immich auf vom Betriebssystem gemeldete Dateiänderungen.
Bei über das Netzwerk eingebundenen Bibliotheken gibt es allerdings eine wichtige Einschränkung:
Library Watching funktioniert für Netzwerk-Mounts nicht.
Bei NAS-Bibliotheken sollte deshalb mit regelmäßigen Scans gearbeitet werden.
Periodische Scans
Immich kann externe Bibliotheken regelmäßig neu scannen.
Das ist sinnvoll, wenn beispielsweise Lightroom, ein Scanner oder andere Programme regelmäßig neue Dateien auf das NAS schreiben.
Der Ablauf könnte dann folgendermaßen aussehen:
Kamera / Lightroom
│
▼
NAS
│
▼
neue Fotodateien
│
▼
periodischer Immich-Scan
│
▼
neue Bilder erscheinen
Das Scanintervall kann in den Einstellungen für externe Bibliotheken konfiguriert werden.
Was passiert bei Änderungen?
Externe Dateien bleiben außerhalb der Kontrolle von Immich.
Wird eine Datei beispielsweise durch ein anderes Programm verändert, muss Immich die Bibliothek erneut scannen, damit entsprechende Änderungen erkannt werden.
Noch wichtiger ist das Löschen.
Wird eine externe Datei auf dem Dateisystem entfernt, erkennt Immich dies beim erneuten Scan und behandelt den zugehörigen Eintrag entsprechend.
Deshalb sollte ein externes Archiv niemals unüberlegt reorganisiert werden, nachdem es in Immich eingebunden wurde.
Verzeichnisse nicht ständig verschieben
Nehmen wir an:
/Fotos/2025/Urlaub/
wird später verschoben nach:
/Fotos/Reisen/2025/Italien/
Aus Sicht des Dateisystems handelt es sich um einen neuen Pfad.
Bei umfangreichen Umstrukturierungen kann Immich deshalb bestehende Zuordnungen verlieren beziehungsweise Dateien nach erneutem Auffinden als neue Assets behandeln.
Wer ein jahrzehntelanges Archiv neu strukturieren möchte, sollte dies möglichst vor dem endgültigen Einbinden in Immich erledigen.
Metadaten von Immich und Originaldateien
Bei externen Bibliotheken sollte außerdem zwischen den Originaldateien und der Immich-Datenbank unterschieden werden.
Informationen, die innerhalb von Immich ergänzt werden, können ausschließlich in Immich gespeichert sein.
Das betrifft beispielsweise bestimmte:
- Beschreibungen
- Albumzuordnungen
- Metadatenänderungen
Wer die Immich-Datenbank verliert, kann deshalb nicht davon ausgehen, dass sämtliche innerhalb von Immich vorgenommenen Organisationsinformationen automatisch in den Originalbildern stecken.
Auch bei einer Read-Only-Bibliothek bleibt ein Backup der Immich-Datenbank deshalb wichtig.
Duplikate beachten
Bei externen Bibliotheken sollte außerdem auf doppelte Dateien geachtet werden.
Ein Archiv könnte beispielsweise enthalten:
Fotos
├── Original
│ └── IMG_1000.JPG
│
├── Backup_alt
│ └── IMG_1000.JPG
│
└── Kopie_Laptop
└── IMG_1000.JPG
Immich führt bei externen Bibliotheken keine globale Duplikaterkennung durch, die automatisch sämtliche solchen Fälle beseitigt.
Dadurch kann dasselbe Foto mehrfach in der Timeline erscheinen.
Ein vorhandenes Archiv sollte deshalb möglichst vor dem Import auf offensichtliche Duplikatbestände und alte Backup-Unterordner überprüft werden.
SMB direkt über Docker
Technisch kann eine CIFS-/SMB-Freigabe auch direkt als Docker-Volume eingebunden werden.
Docker unterstützt entsprechende driver_opts.
Für eine übersichtliche Linux-Installation bevorzuge ich allerdings häufig:
NAS ↓ Linux Mount ↓ Docker Bind Mount ↓ Immich
gegenüber:
NAS ↓ Docker CIFS Volume ↓ Immich
Der erste Aufbau lässt sich auf dem Host einfacher testen und unabhängig von Docker diagnostizieren.
Die direkte Docker-Variante kann jedoch in bestimmten Umgebungen sinnvoll sein und wird auch in der Immich-Dokumentation beschrieben.
Berechtigungen prüfen
Wenn Immich eine externe Bibliothek nicht findet, sind Berechtigungsprobleme eine der häufigsten Ursachen.
Zunächst auf dem Host:
ls -la /mnt/nas-fotos
Dann innerhalb des Containers:
docker exec -it immich_server bash
und:
ls -la /mnt/media/fotos
Funktioniert bereits der erste Befehl nicht, liegt das Problem beim NAS-Mount.
Funktioniert der erste, aber nicht der zweite, liegt das Problem wahrscheinlich beim Docker-Mount oder bei den Berechtigungen.
Funktionieren beide, sollte der in Immich konfigurierte Importpfad überprüft werden.
Eine sinnvolle Architektur für große Archive
Für eine umfangreiche Sammlung könnte die Infrastruktur beispielsweise so aufgebaut werden:
10-Gbit-Netzwerk
│
┌────────────┴────────────┐
│ │
▼ ▼
NAS / ZFS Immich-Server
│ │
8 TB Fotoarchiv ├── NVMe SSD
│ │ ├── PostgreSQL
│ │ └── Immich-Daten
│ │
└──── NFS Read Only ─────┤
│
├── Docker
│
└── GPU optional
│
▼
Machine Learning
Damit werden die unterschiedlichen Aufgaben sinnvoll verteilt.
Das NAS bietet viel Speicherkapazität.
Die NVMe-SSD sorgt für schnelle Datenbankzugriffe.
Und eine optionale GPU beschleunigt Machine Learning.
Beispiel für ein Familienarchiv
Ein praktisches Familienarchiv könnte so strukturiert sein:
/photos ├── Familie │ ├── 1990-1999 │ ├── 2000-2009 │ ├── 2010-2019 │ └── 2020-2026 │ ├── Reisen │ ├── Italien │ ├── Spanien │ └── USA │ ├── Scans │ ├── Alte Fotos │ └── Dias │ └── Videos
Das gesamte Verzeichnis könnte anschließend beispielsweise als:
/mnt/media/familienarchiv
Read-Only in Immich eingebunden werden.
Damit erhält die jahrzehntelang gewachsene Sammlung eine moderne Oberfläche, ohne dass die Originalstruktur aufgegeben werden muss.
Performance optimieren
Bei großen externen Bibliotheken bestimmen mehrere Komponenten die Geschwindigkeit:
Netzwerk
Gigabit-Ethernet ist ein sinnvoller Ausgangspunkt. Bei mehreren Terabyte können 2,5 oder 10 Gbit/s interessant werden.
NAS
Langsame Festplatten oder stark ausgelastete RAID-Systeme können zum Flaschenhals werden.
SSD
PostgreSQL sollte möglichst lokal auf einer SSD beziehungsweise NVMe liegen.
CPU
Metadatenextraktion und weitere Hintergrundjobs benötigen Rechenleistung.
GPU
Machine Learning kann bei großen Archiven erheblich von Hardwarebeschleunigung profitieren.
RAM
Viele parallele Aufgaben benötigen entsprechend Arbeitsspeicher.
Job-Concurrency
Zu viele parallele Hintergrundjobs können ein schwächeres System überfordern.
Performance bedeutet deshalb nicht einfach:
Möglichst viele Jobs gleichzeitig starten.
Ein gut abgestimmtes System ist häufig schneller und stabiler als maximale Parallelität.
Externe Bibliothek oder Import?
Vor der Übernahme einer vorhandenen Sammlung sollte eine grundsätzliche Entscheidung getroffen werden.
Externe Bibliothek
Sinnvoll, wenn:
- die bestehende Ordnerstruktur erhalten bleiben soll,
- das NAS das führende Speichersystem bleibt,
- andere Programme weiterhin auf die Dateien zugreifen,
- mehrere Terabyte nicht kopiert werden sollen,
- Immich hauptsächlich als Fotoverwaltung dienen soll.
Klassischer Immich-Import
Sinnvoll, wenn:
- Immich künftig das führende Fotosystem werden soll,
- Dateien vollständig von Immich verwaltet werden sollen,
- die alte Ordnerstruktur nicht mehr benötigt wird,
- eine zentrale Migration gewünscht ist.
Beide Konzepte können auch nebeneinander existieren.
Best Practices für NAS-Bibliotheken
Für eine langfristig stabile Installation empfiehlt sich folgendes Vorgehen:
- Archiv zunächst bereinigen und strukturieren.
- Mit einem kleinen Testbestand beginnen.
- NAS zuverlässig per NFS oder SMB auf dem Host mounten.
- Für historische Archive Read-Only verwenden.
- Mount anschließend als Docker-Volume bereitstellen.
- Containerpfad als Importpfad in Immich verwenden.
- Unnötige RAW-, Backup- oder Cache-Verzeichnisse ausschließen.
- Ersten Scan beobachten und Jobs kontrollieren.
- PostgreSQL auf lokalem SSD-Speicher betreiben.
- Bei Netzwerkbibliotheken periodische Scans konfigurieren.
- Immich-Datenbank und Konfiguration zusätzlich sichern.
- Erst danach das komplette Archiv einbinden.
Immich ersetzt kein Backup
Auch bei externen Read-Only-Bibliotheken gilt weiterhin:
Immich ist kein Ersatz für ein Backup.
Wenn das NAS ausfällt und die Originaldateien nur dort gespeichert sind, kann Immich die Fotos nicht wiederherstellen.
Für wertvolle Archive sollte weiterhin die 3-2-1-Regel gelten:
3 Kopien 2 unterschiedliche Speichermedien 1 Kopie außerhalb des Standorts
Ein mögliches Konzept:
NAS
│
├── Originalarchiv
│
├──────────────► Immich
│
└──────────────► lokales Backup
│
▼
externes Backup
Dabei müssen nicht nur die Originalfotos, sondern auch die für Immich relevanten Daten und insbesondere die Datenbank in das Sicherungskonzept einbezogen werden.
Externe Bibliotheken gehören zu den interessantesten Immich-Funktionen für Anwender, die bereits eine große Fotosammlung besitzen.
Statt mehrere Terabyte Bilder in eine komplett neue Speicherstruktur zu kopieren, kann das vorhandene Archiv auf einem NAS bleiben. Immich katalogisiert die Dateien und stellt anschließend moderne Funktionen wie Timeline, Kartenansicht, Suche, Alben und Machine Learning darüber bereit.
Besonders attraktiv ist die Kombination aus NAS, Read-Only-Mount und Immich.
Das NAS bleibt das führende Archiv, während Immich lediglich lesend darauf zugreift. Dadurch können bestehende Strukturen erhalten und gleichzeitig die Möglichkeiten einer modernen Fotoverwaltung genutzt werden.
SMB und NFS eignen sich beide zur Anbindung eines NAS. Unter Linux bietet es sich häufig an, die Netzwerkfreigabe zunächst auf dem Host einzubinden und anschließend per Docker Bind Mount an Immich weiterzugeben.
Bei großen Archiven entscheidet schließlich die Infrastruktur über die Geschwindigkeit. Ein schnelles Netzwerk, lokaler SSD-Speicher für PostgreSQL, ausreichend RAM und gegebenenfalls GPU-Beschleunigung können einen erheblichen Unterschied machen.
So lässt sich selbst ein über Jahrzehnte gewachsenes Fotoarchiv mit hunderttausenden Bildern in eine moderne Self-Hosting-Umgebung integrieren – ohne die Originalsammlung komplett neu aufbauen zu müssen.
Im nächsten Teil unserer Serie beschäftigen wir uns mit einem Thema, das spätestens jetzt unverzichtbar wird: Backup und Wiederherstellung von Immich. Wir zeigen, welche Daten wirklich gesichert werden müssen, wie PostgreSQL und Originaldateien zusammenspielen und wie eine vollständige Disaster-Recovery-Strategie aufgebaut wird.
