Om Immich fortsätter att rapportera ledigt utrymme från ZimaOS-systemets SSD även efter att du har lagt till en större hårddisk, är den viktiga frågan vilken katalog på värddatorn som faktiskt är bunden till Immichs uppladdnings-/lagringsmontering. I gemenskapstråden från april 2026 körde den ursprungliga användaren Immich 2.7.4 på en system-SSD på 250 GB och ville lagra foton på en hårddisk på 1 TB. Upprepade ändringar av sökvägen efter installationen ledde till containrar som inte var friska eller till startfel.
Källtråden ledde till flera olika resultat. En användare lyckades efter en ren ominstallation och med en anpassad YAML-fil. Upphovspersonen rapporterade till slut att det endast fungerade efter att ha valt hårddisken som lagringsplats innan Immich installerades. Ett senare svar kopplade vissa startproblem till Immichs kontroller av lagringsintegritet. Den aktuella uppströmsdokumentationen för Immich har också ändrats sedan version 2.7.4, så den exakta containersökvägen i detta historiska ZimaOS-paket bör inte kopieras till alla aktuella Immich-distributioner.
Vad den ursprungliga Immich 2.7.4-konfigurationen använde
Gemenskapsinstruktionerna visade denna historiska mappning:
Värd: /DATA/Gallery/immich
Container: /usr/src/app/uploadDen första rekommendationen var att endast ändra värdsidan och behålla containersökvägen. Exempelvis kan en sekundär enhet exponeras via en värdsökväg i ZimaOS medan Immich fortfarande ser den förväntade interna uppladdningskatalogen.
Varför det inte fungerade för alla att bara ändra värdsökvägen
Flera användare försökte ersätta standardsökvägen på värddatorn efter att Immich redan hade initierats. Vissa fick ett tillstånd med en container som inte var frisk, vissa såg ett fel om ett skrivskyddat filsystem och andra upptäckte att appen fortfarande rapporterade systemenheten.
Det innebär att den här tråden inte stöder påståendet att ”redigera en volym och starta om” alltid fungerar. Immich sparar databastillstånd och markörer för lagringsintegritet, och om en bind mount ändras efter initieringen kan den nya katalogen bli inkonsekvent med det tillstånd som Immich förväntar sig.
Upphovspersonens bekräftat fungerande metod
Efter flera misslyckade försök återkom Solid den 19 april och sade att den fungerande metoden var att göra en ren installation och ändra installations-/lagringssökvägen till 1 TB-hårddisken innan Immich-installationen initierades.
En annan användare bekräftade en ren ominstallation och en anpassad YAML-sökväg
En annan deltagare, scott492010, tog bort den misslyckade installationen, bevarade befintliga foton, raderade det föråldrade Immich AppData-/databastillståndet, installerade om och använde sedan den anpassade YAML-konfigurationen som delades i tråden. Personen bekräftade uttryckligen att den nya konfigurationen fungerade.
Ta inte bort AppData eller Immich-databasen på måfå. Den community-beskrivna proceduren användes på en trasig/testinstallation. Om biblioteket innehåller viktiga metadata, användare, album eller uppladdade filer ska du säkerhetskopiera både databasen och fotolagringen innan du bygger om.
Historisk ZimaOS-sökväg: /DATA/.media/...
Tråden testade externa enhetssökvägar som:
/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/uploadDessa exempel var specifika för enheterna och ZimaOS-sökvägslayouten i den diskussionen. Kopiera inte namnet Element eller anta att alla enheter visas på samma sökväg på värddatorn. Använd den faktiska sökväg som visas i de aktuella ZimaOS-inställningarna för Filer/appen.
Aktuella Immich använder en annan lagringslayout uppströms
Den aktuella uppströmsdokumentationen för Immich Docker Compose använder UPLOAD_LOCATION på värddatorn och monterar den till /data i den aktuella Compose-mallen. Det skiljer sig från den historiska ZimaOS Immich 2.7.4-mappningen till /usr/src/app/upload.
Se aktuell dokumentation om Immich Docker Compose.
Detta är en versionsgräns, inte en motsägelse. Om du använder ett ZimaOS App Store-paket ska du behålla den containermålplats som definieras av det aktuella paketet. Om du själv hanterar Compose uppströms ska du följa den aktuella uppströmsmallen.
Aktuella Immich-anvisningar för anpassade filplatser
Immich har nu en särskild guide om anpassade fillagringsplatser. Den rekommenderar att värdplatser ändras medvetet och att motsvarande befintliga filer flyttas så att Immich fortsätter att hitta dem.
Immich varnar också för att dela upp upload/ och library/ till separata bindmonteringar på samma enhet. För en ny layout bör du följa den aktuella lagringsmodellen i stället för att återskapa YAML-raden från communityn från 2026 rad för rad.
Varför saknade .immich-filer kan stoppa starten
Ett svar från juli 2026 i tråden identifierade fel som:
ENOENT: ingen sådan fil eller katalog
.../encoded-video/.immichDen aktuella dokumentationen om systemintegritet för Immich bekräftar att dolda .immich-filer är monteringsmarkörer som används för att upptäcka felaktiga behörigheter eller saknade eller ersatta lagringsmonteringar.
Foruminlägget föreslog att man manuellt skulle skapa de förväntade mapparna och markörfilerna. Den aktuella dokumentationen uppströms är mer försiktig: markörfiler bör i allmänhet inte skapas eller raderas manuellt, utom i särskilda återställningssituationer. Om monteringen har ändrats oväntat ska du åtgärda monteringen först. Att återskapa en markör manuellt är lämpligt endast när du har verifierat varför den saknas.
Använd inte chmod 777 som standardlösning för behörighetsproblem
Det slutliga svaret från communityn använde också:
sudo chmod -R 777 /DATA/Main-Storage/immichDetta ger alla lokala användare och processer omfattande skrivåtkomst. Det kan undanröja ett behörighetshinder, men är inte den rekommenderade permanenta behörighetsmodellen. Identifiera i stället det UID/GID och de lagringsbehörigheter som förväntas av det installerade Immich-paketet.
Håll PostgreSQL-databasen på ett lämpligt filsystem
Att flytta fototillgångarna till en stor HDD innebär inte att alla Immich-komponenter bör ligga där. Enligt de aktuella kraven för Immich bör PostgreSQL-databasen helst ligga på lokal SSD-lagring och kräver ett filsystem med normal semantik för Unix-ägarskap och behörigheter; NTFS och exFAT stöds inte för datakatalogen.
Se installationskrav för Immich.
Det innebär att en rimlig arkitektur kan behålla Immich-databasen och appens tillstånd på tillförlitlig SSD-lagring, samtidigt som den mycket större platsen för uppladdade foton och videor läggs på en lämplig sekundär disk.
Säkerhetskopiera innan du bygger om eller flyttar befintliga Immich-data
Aktuell Immich-dokumentation rekommenderar att både databasen och filsystemets tillgångar skyddas. Enbart en säkerhetskopia av databasen innehåller inte de ursprungliga fotona och videorna.
Guide för säkerhetskopiering och återställning i Immich
Säkrare felsökningsordning
- Identifiera det exakta Immich-paketet och versionen som är installerade i ZimaOS.
- Dokumentera den aktuella mappningen mellan värd och container för uppladdningar.
- Säkerhetskopiera viktiga foton och Immich-databasen innan du ändrar en befintlig installation.
- Vid en ny installation väljer du den avsedda värdsökvägen på den stora lagringsenheten före den första initieringen, när ZimaOS-paketet tillåter det.
- Bevara sökvägen på containersidan som definieras av paketet.
- Om appen blir instabil, läs Immich-loggarna och leta efter fel gällande behörigheter eller lagringsintegritet.
- Kontrollera att den nya värdmappen är skrivbar för Immich-containerns identitet.
- Om loggarna nämner saknade
.immichmarkörer och kontrollera monteringen och katalogstrukturen innan du skapar filer manuellt. - Undvik
chmod 777som en permanent lösning.
Vanliga frågor om Immich-systemlagring
Varför visar Immich fortfarande kapaciteten på min system-SSD?
Den aktiva bind-monteringen för uppladdningar kan fortfarande peka på systemlagringen, eller så kanske den ändrade monteringen inte initierades korrekt. Kontrollera den faktiska mappningen mellan värd och container som används av den körande servern.
Löste den ursprungliga författaren problemet?
Ja. Solid rapporterade att en ren installation där hårddiskens sökväg valdes före installationen fungerade efter att ändringar efter installationen hade misslyckats.
Ska jag kopiera /usr/src/app/upload till en ny Immich-installation?
Inte utan vidare. Det var sökvägen i containern i det historiska ZimaOS Immich 2.7.4-paketet. Aktuella Immich Compose från upstream använder /data. Följ det paket och den version som du faktiskt kör.
Ska jag skapa .immich-filer manuellt?
Först efter att du har bekräftat varför de saknas. I aktuell Immich-dokumentation står det att dessa markörer normalt inte ska skapas eller tas bort manuellt, utom i särskilda återställningsfall.
Kan jag ha databasen på en exFAT-formaterad USB-enhet?
Aktuella Immich-krav stöder inte exFAT/NTFS för PostgreSQL-datakatalogen. Behåll databasen på ett lämpligt lokalt filsystem och flytta fototillgångarna separat vid behov.
