Wenn Immich auch nach dem Hinzufügen einer größeren HDD weiterhin den freien Speicherplatz der ZimaOS-System-SSD meldet, ist die entscheidende Frage, welches Hostverzeichnis tatsächlich an den Upload-/Speicher-Mount von Immich gebunden ist. Im Community-Thread vom April 2026 betrieb der ursprüngliche Benutzer Immich 2.7.4 auf einer 250-GB-System-SSD und wollte die Fotos auf einer 1-TB-HDD speichern. Das wiederholte Ändern des Pfads nach der Installation führte zu Containern mit fehlerhaftem Zustand oder Startfehlern.
Der Quellthread führte zu mehreren unterschiedlichen Ergebnissen. Ein Benutzer hatte nach einer sauberen Neuinstallation mit einer benutzerdefinierten YAML-Datei Erfolg. Der ursprüngliche Autor berichtete letztlich nur dann von Erfolg, nachdem er den HDD-Speicherpfad vor der Installation von Immich ausgewählt hatte. Eine spätere Antwort brachte einige Startfehler mit den Prüfungen der Speicherintegrität von Immich in Verbindung. Auch die aktuelle Immich-Dokumentation der Upstream-Version hat sich seit Version 2.7.4 geändert. Daher sollte der genaue Containerpfad dieses historischen ZimaOS-Pakets nicht in jede aktuelle Immich-Bereitstellung übernommen werden.
Was die ursprüngliche Immich-2.7.4-Einrichtung verwendete
Die Community-Anleitung zeigte dieses historische Mapping:
Host: /DATA/Gallery/immich
Container: /usr/src/app/uploadDie erste Empfehlung lautete, nur die Hostseite zu ändern und den Containerpfad beizubehalten. Beispielsweise könnte ein sekundäres Laufwerk über einen ZimaOS-Hostpfad eingebunden werden, während Immich weiterhin das erwartete interne Upload-Verzeichnis sieht.
Warum das einfache Ändern des Hostpfads nicht bei allen funktionierte
Mehrere Benutzer versuchten, den standardmäßigen Hostpfad zu ersetzen, nachdem Immich bereits initialisiert worden war. Bei einigen wurde ein Status mit nicht gesundem Container angezeigt, andere sahen einen Fehler wegen eines schreibgeschützten Dateisystems, und wieder andere stellten fest, dass die App weiterhin das Systemlaufwerk meldete.
Das bedeutet, dass dieser Thread keine allgemeingültige Aussage stützt, wonach „ein Volume bearbeiten und neu starten“ immer funktioniert. Immich speichert den Datenbankstatus und Markierungen zur Speicherintegrität. Wird ein Bind-Mount nach der Initialisierung geändert, kann das neue Verzeichnis inkonsistent mit dem von Immich erwarteten Zustand sein.
Der bestätigte funktionierende Ansatz des ursprünglichen Autors
Nach mehreren fehlgeschlagenen Versuchen meldete sich Solid am 19. April zurück und sagte, der funktionierende Ansatz bestehe darin, eine saubere Installation durchzuführen und den Installations-/Speicherpfad auf die 1-TB-Festplatte zu ändern, bevor die Immich-Installation initialisiert wurde.
Ein zweiter Nutzer bestätigte eine saubere Neuinstallation mit einem benutzerdefinierten YAML-Pfad
Ein weiterer Teilnehmer, scott492010, entfernte die fehlgeschlagene Installation, bewahrte die vorhandenen Fotos auf, löschte den veralteten Immich-AppData-/Datenbankstatus, installierte die App neu und verwendete anschließend die im Thread geteilte benutzerdefinierte YAML-Konfiguration. Er bestätigte ausdrücklich, dass die neue Einrichtung funktionierte.
Lösche AppData oder die Immich-Datenbank nicht unbedacht. Dieses Verfahren aus der Community wurde bei einer fehlerhaften/Testinstallation verwendet. Wenn die Bibliothek wichtige Metadaten, Benutzer, Alben oder hochgeladene Dateien enthält, sichere vor dem Neuaufbau sowohl die Datenbank als auch den Fotospeicher.
Historischer ZimaOS-Pfad: /DATA/.media/...
In dem Thread wurden Pfade zu externen Laufwerken ausprobiert, zum Beispiel:
/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/uploadDiese Beispiele bezogen sich speziell auf die Laufwerke und das ZimaOS-Pfadlayout in dieser Diskussion. Kopiere den Namen nicht Elemente oder gehe davon aus, dass jedes Laufwerk unter demselben Hostpfad erscheint. Verwende den tatsächlichen Pfad, der in den aktuellen ZimaOS-Datei-/App-Einstellungen angezeigt wird.
Das aktuelle Immich verwendet ein anderes Upstream-Speicherlayout
Die aktuelle Upstream-Immich-Docker-Compose-Dokumentation verwendet UPLOAD_LOCATION auf dem Host und bindet es in /data in der aktuellen Compose-Vorlage. Das unterscheidet sich vom historischen ZimaOS-Immich-2.7.4-Mapping auf /usr/src/app/upload.
Siehe die aktuelle Immich-Docker-Compose-Dokumentation.
Dies ist eine Versionsgrenze, kein Widerspruch. Wenn du ein ZimaOS-App-Store-Paket verwendest, behalte das Containerziel bei, das im aktuellen Paket definiert ist. Wenn du den Upstream-Compose selbst verwaltest, befolge die aktuelle Upstream-Vorlage.
Aktuelle Immich-Anleitung für benutzerdefinierte Dateispeicherorte
Immich verfügt jetzt über einen eigenen Leitfaden zu benutzerdefinierten Speicherorten für Dateien. Er empfiehlt, die Speicherorte auf dem Host bewusst zu ändern und die entsprechenden vorhandenen Dateien zu verschieben, damit Immich sie weiterhin findet.
Immich warnt außerdem davor, die Verzeichnisse upload/ und library/ in separate Bind-Mounts auf demselben Gerät. Für ein neues Layout sollten Sie dem aktuellen Speichermodell folgen, statt die YAML-Zeile der Community aus dem Jahr 2026 Schritt für Schritt nachzubauen.
Warum fehlende .immich-Dateien den Start verhindern können
Eine Antwort vom Juli 2026 im Thread nannte folgende Fehler:
ENOENT: Datei oder Verzeichnis nicht gefunden
.../encoded-video/.immichDie aktuelle Dokumentation zur Systemintegrität von Immich bestätigt, dass versteckte .immich-Dateien als Mount-Markierungen dienen, um falsche Berechtigungen oder fehlende bzw. ausgetauschte Speichereinbindungen zu erkennen.
Die Forumsantwort schlug vor, die erwarteten Ordner und Markierungsdateien manuell zu erstellen. Die aktuelle Upstream-Dokumentation ist vorsichtiger: Markierungsdateien sollten im Allgemeinen nicht manuell erstellt oder gelöscht werden, außer in bestimmten Wiederherstellungssituationen. Wenn sich der Mount unerwartet geändert hat, korrigieren Sie zuerst den Mount. Das manuelle Wiederherstellen einer Markierung ist nur dann angemessen, wenn Sie überprüft haben, warum sie fehlt.
chmod 777 nicht als standardmäßige Lösung für Berechtigungsprobleme verwenden
Die abschließende Antwort der Community enthielt außerdem:
sudo chmod -R 777 /DATA/Main-Storage/immichDadurch erhalten alle lokalen Benutzer/Prozesse umfassenden Schreibzugriff. Das kann eine Berechtigungshürde beseitigen, ist aber nicht das bevorzugte dauerhafte Berechtigungsmodell. Ermitteln Sie stattdessen die für das installierte Immich-Paket erwartete UID/GID und die erforderlichen Speicherberechtigungen.
Die PostgreSQL-Datenbank auf einem geeigneten Dateisystem speichern
Das Verschieben von Fotodateien auf eine große HDD bedeutet nicht, dass jede Immich-Komponente dort liegen sollte. Laut den aktuellen Immich-Anforderungen sollte die PostgreSQL-Datenbank idealerweise auf lokalem SSD-Speicher liegen und benötigt ein Dateisystem mit normalen Unix-Eigentümer- und Berechtigungssemantiken. NTFS und exFAT werden für das Datenverzeichnis der Datenbank nicht unterstützt.
Siehe Installationsanforderungen für Immich.
Das bedeutet, dass eine sinnvolle Architektur den Immich-Datenbank-/App-Zustand auf einem zuverlässigen SSD-Speicher belassen kann, während der wesentlich größere Speicherort für Foto-/Video-Uploads auf einem geeigneten sekundären Laufwerk liegt.
Vor dem Neuaufbau oder Verschieben bestehender Immich-Daten sichern
Die aktuelle Immich-Dokumentation empfiehlt, sowohl die Datenbank als auch die Dateisystem-Assets zu schützen. Eine reine Datenbanksicherung enthält nicht die ursprünglichen Fotos und Videos.
Anleitung zur Immich-Sicherung und -Wiederherstellung
Sicherere Reihenfolge zur Fehlerbehebung
- Ermitteln Sie das genaue in ZimaOS installierte Immich-Paket und dessen Version.
- Notieren Sie die aktuelle Host-zu-Container-Zuordnung für Uploads.
- Sichern Sie wichtige Fotos und die Immich-Datenbank, bevor Sie eine bestehende Installation ändern.
- Wählen Sie bei einer neuen Installation den vorgesehenen Hostpfad für den großen Speicher vor der ersten Initialisierung, sofern das ZimaOS-Paket dies zulässt.
- Behalten Sie den containerseitigen Pfad bei, der von diesem Paket definiert wird.
- Wenn die App ungesund wird, lesen Sie die Immich-Protokolle und suchen Sie nach Berechtigungs- oder Fehlern bezüglich der Speicherintegrität.
- Stellen Sie sicher, dass der neue Host-Ordner für die Identität des Immich-Containers beschreibbar ist.
- Wenn in den Protokollen fehlende
.immichMarkierungsdateien; überprüfen Sie den Mount und die Verzeichnisstruktur, bevor Sie Dateien manuell erstellen. - Vermeiden Sie
chmod 777als dauerhafte Lösung.
FAQ zum Systemspeicher von Immich
Warum zeigt Immich weiterhin die Kapazität meiner System-SSD an?
Der aktive Upload-Bind-Mount verweist möglicherweise weiterhin auf den Systemspeicher, oder der geänderte Mount wurde möglicherweise nicht erfolgreich initialisiert. Überprüfen Sie die tatsächliche Host-zu-Container-Zuordnung, die der laufende Server verwendet.
Hat der ursprüngliche Autor das Problem gelöst?
Ja. Solid berichtete, dass eine saubere Installation mit ausgewähltem HDD-Pfad vor der Installation funktionierte, nachdem Änderungen nach der Installation fehlgeschlagen waren.
Sollte ich /usr/src/app/upload in eine neue Immich-Installation kopieren?
Nicht blind. Das war der Containerpfad im historischen ZimaOS-Immich-2.7.4-Paket. Das aktuelle Immich-Compose des Upstream-Projekts verwendet /data. Befolgen Sie die Paket-/Version, die Sie tatsächlich ausführen.
Sollte ich .immich-Dateien manuell erstellen?
Erst nachdem geklärt wurde, warum sie fehlen. In der aktuellen Immich-Dokumentation steht, dass diese Markierungsdateien normalerweise nicht manuell erstellt oder gelöscht werden sollten, außer in bestimmten Wiederherstellungsfällen.
Kann ich die Datenbank auf einem exFAT-USB-Laufwerk ablegen?
Die aktuellen Immich-Anforderungen unterstützen exFAT/NTFS für das PostgreSQL-Datenverzeichnis nicht. Lassen Sie die Datenbank auf einem geeigneten lokalen Dateisystem und verschieben Sie die Foto-Assets bei Bedarf separat.
