Immich kan kräva betydligt mer lagringsutrymme än vad ZimaOS-systemdisken är utformad för att rymma, särskilt när telefonöverföringar, miniatyrbilder, kodad video, maskininlärningsmodeller och PostgreSQL-databasen börjar växa. Den ursprungliga IceWhale Community-guiden löste detta i april 2025 genom att ändra utvalda volymmappningar under en anpassad installation i ZimaOS, så att Immich-data skulle lagras på en RAID-volym i stället för på ZimaOS-disken.
Den lösningen är användbar för att förstå hur containern är kopplad, men bör inte betraktas som en universell aktuell instruktion. Senare svar rapporterade misslyckade installationer, upprepade omstarter, en PostgreSQL-container med felstatus och till och med skadade fotoöverföringar efter experiment med mappningar. ZimaOS har också lagt till och förfinat inbyggda migreringsverktyg, medan aktuella Immich-versioner för Docker Compose använder variabler på värdsidan, såsom UPLOAD_LOCATION och DB_DATA_LOCATION. På ett aktuellt system bör du först använda ZimaOS inbyggda migreringsfunktion när den passar ditt mål och reservera manuell volymredigering för fall där du specifikt behöver en anpassad Immich-lagringslayout.
Vad den ursprungliga ZimaOS Immich-guiden från 2025 ändrade
Community-guiden använde ZimaOS anpassade installation, eller appens inställningsskärm efter installationen, och gick igenom tjänsteflikarna en i taget. Målet var att omdirigera Immichs beständiga data till en större RAID-plats och samtidigt behålla sökvägarna på containersidan som Immich förväntade sig.
Databas: Flytta värdsökvägen, behåll containersökvägen
På databasfliken ändrade författaren lagringsplatsen på ZimaOS-sidan till en RAID-sökväg och behöll suffixet för databasens katalog. Den viktiga principen var att inte skriva om sökvägen på höger sida inuti containern. Om containerns destination ändras kan tjänsten sluta fungera, eftersom PostgreSQL förväntar sig att data finns på den sökväg som definieras av Immich-paketet eller Compose-konfigurationen.
I den aktuella dokumentationen för Immich Docker Compose exponeras denna värdplats via DB_DATA_LOCATION. Immich varnar också för att nätverksdelningar inte stöds för PostgreSQL-databasen, så databasen bör ligga på tillförlitlig lokalt ansluten lagring i stället för på en SMB- eller NFS-delning.
Maskininlärning: Omdirigera endast modellcachen vid behov
Den ursprungliga guiden omdirigerade även cachelagringen för maskininlärningsmodeller på värdsidan, samtidigt som cachesökvägen på containersidan lämnades oförändrad. Att flytta denna cache kan spara utrymme på en liten systemdisk, även om det är mindre viktigt än att skydda fotobiblioteket och databasen eftersom nedladdade modeller normalt kan återskapas.
Immich-servern: Den känsligaste volymsektionen
Immich-serverfliken var den del som författaren tyckte var lättast att råka förstöra. Extra värdmonteringar lades till så att uppladdningar och andra beständiga mediekataloger skulle använda RAID-lagringen. Tråden betonar upprepade gånger att endast de avsedda platserna på värdsidan ska ändras och att sökvägar på containersidan inte bör ändras utan eftertanke.
Redis-fliken krävde inga lagringsändringar i den ursprungliga genomgången. Det är ytterligare ett skäl att inte tillämpa ett generellt sök-och-ersätt på varje volympost: olika Immich-tjänster har olika krav på beständig lagring.
Använd ZimaOS-datamigrering först på aktuella system
Den viktigaste uppdateringen från den senare diskussionen är att ZimaOS nu erbjuder ett särskilt migreringsflöde. En IceWhale-teammedlem i tråden varnade uttryckligen för att manuell kopiering av programdata kan orsaka fel och rekommenderade att migreringsfunktionen används i de flesta fall.
Den aktuella guiden för ZimaOS-datamigrering listar tre flyttbara lagringskategorier: Docker-avbildningar, Docker-programdata och användardatabaser. Den normala sökvägen är:
- Öppna Inställningar > Datamigrering.
- Välj den lagringskategori du vill flytta.
- Välj Ändra plats.
- Välj måldisken eller lagringsutrymmet.
- Granska varningen, starta migreringen och vänta på slutrapporten.
Den här inbyggda migreringen är en bättre utgångspunkt när målet helt enkelt är att hålla Docker-appdata borta från ZimaOS-systemdisken. Den minskar också risken för att sökvägar, behörigheter eller symboliska länkar blir inkonsekventa efter en manuell flytt.
Vad händer om du vill ha Immich på SSD men fotona på RAID?
En senare fråga i tråden tog upp en mer användbar layout på lång sikt: behåll appen och prestandakänsliga komponenter på SSD, men placera det stora fotobiblioteket på RAID. Den ursprungliga författaren hade inte testat den uppdelningen, så tråden innehåller inget verifierat ZimaOS-recept för den.
Aktuell Immich-dokumentation beskriver två koncept som hjälper till att definiera rätt layout. För Immich-medier som laddas upp använder den officiella Docker Compose-konfigurationen UPLOAD_LOCATION som värdsökväg för medielagringen. För en befintlig fotosamling som Immich ska indexera utan att importera till sitt hanterade uppladdningsområde stöder Immich externa bibliotek.
I en aktuell Immich-distribution med standardkonfiguration via Compose ser de relevanta miljövärdena i princip ut så här:
UPLOAD_LOCATION=/path/to/large-media-storage
DB_DATA_LOCATION=/path/to/local-database-storageKlistra inte in dessa sökvägar utan vidare i en äldre ZimaOS-appdefinition. Kontrollera först Compose- eller Custom Install-konfigurationen som används av det exakta Immich-paketet du har installerat. Immichs aktuella officiella Compose-fil monterar ${UPLOAD_LOCATION} in i servercontainern och ${DB_DATA_LOCATION} in i PostgreSQL, medan äldre versioner och community-paket kan använda andra interna sökvägar.
Se installationsguiden för Immich Docker Compose och guiden för Immich External Library för aktuell information från upstream-projektet.
Varför manuella volymändringar kan få Immich att sluta fungera
Svaren visar flera fel som kan uppstå efter att användare ändrat lagringsmappningar. En deltagare rapporterade först att appen slutade fungera och sa senare att den började fungera efter flera omstarter. En annan användare sa att upprepade experiment fick Immich att sluta fungera och att vissa telefonuppladdningar blev skadade. En senare rapport beskrev upprepade installationsfel där PostgreSQL-tjänsten var i ett ohälsosamt tillstånd.
Dessa rapporter bevisar inte att det rör sig om ett enda gemensamt fel. De visar däremot varför lagringsmigrering bör hanteras som en dataintegritetsåtgärd snarare än som en kosmetisk ändring av en sökväg. Vanliga orsaker som är värda att kontrollera är:
- Fel containerdestination: Värdsökvägen kan anpassas, men sökvägen inne i containern måste stämma överens med vad den aktuella Immich-distributionen förväntar sig.
- Behörigheter: Destinationen måste vara skrivbar för den containeranvändare eller tjänst som äger filerna.
- Databasplacering: PostgreSQL behöver tillförlitlig lokal lagring och bör inte placeras på en nätverksresurs som inte stöds.
- Ofullständiga flyttar: Om du manuellt kopierar endast delar av ett befintligt Immich-dataträd kan databasen och medielagret hamna ur synk.
- Versionsmismatch: Immichs volymlayout har utvecklats, så anvisningar som skrevs för ett äldre paket kanske inte stämmer överens med Immich v2, v3 eller en senare definition i ZimaOS App Store.
Säkrare checklista för migrering av Immich-lagring
- Säkerhetskopiera Immich-databasen och oersättliga mediefiler innan du ändrar någon volymmappning.
- Bekräfta vilken Immich-version och vilket ZimaOS App Store-paket du kör.
- Bestäm om du vill flytta all appdata eller endast det stora mediebiblioteket.
- Om du flyttar allmänna ZimaOS-appdata kan du prova Inställningar > Datamigrering innan du redigerar enskilda containersökvägar.
- Om du använder en anpassad Immich-layout bör du dokumentera alla befintliga värdsökvägar och containerdestinationer innan du ändrar något.
- Låt destinationerna inne i containern vara oförändrade, såvida dokumentationen för din exakta Immich-version inte uttryckligen kräver en annan sökväg.
- Se till att målfilsystemet är monterat och skrivbart innan du återskapar containrarna.
- Placera inte PostgreSQL:s datakatalog på en nätverksresurs som inte stöds.
- Efter migreringen laddar du upp en liten testuppsättning och verifierar original, miniatyrbilder, videouppspelning, metadata och nya mobiluppladdningar innan du flyttar resten av biblioteket.
- Behåll den gamla kopian tills du har verifierat både databasen och mediefilerna på den nya lagringen.
Vad communityns svar tillförde den ursprungliga guiden
De mest användbara svaren ändrade tolkningen av den ursprungliga handledningen på tre sätt. För det första visade de att den manuella mappningen kunde fungera, men att den var känslig för exakt appversion, lagringsbehörigheter och omstartstillstånd. För det andra ville användarna ha en uppdelning med SSD plus RAID, i stället för att flytta alla Immich-komponenter till samma array. För det tredje rekommenderade en medlem i IceWhale-teamet den inbyggda migreringsfunktionen och varnade för att manuell kopiering kan orsaka fel.
Det innebär att det ursprungliga inlägget från 2025 bäst bör förstås som ett fungerande communityexempel för sin tid, inte som en oföränderlig specifikation för alla senare versioner av Immich eller ZimaOS. Om ditt aktuella ZimaOS-gränssnitt inte längre visar samma fält för Anpassad installation som i skärmbilderna, följ det aktuella migreringsgränssnittet och granska den installerade appens Compose-konfiguration i stället för att försöka återskapa gamla fält.
Vanliga frågor om Immich-lagring i ZimaOS
Kan jag installera Immich på en RAID-disk i stället för på ZimaOS-systemdisken?
Ja, men skilj mellan att flytta ZimaOS-applikationsdata och att utforma en anpassad medielayout för Immich. I aktuella ZimaOS-versioner bör du först använda den inbyggda funktionen för datamigrering när målet är att flytta Docker-applikationsdata. Manuella volymmappningar bör främst användas för en genomtänkt lagringsdesign med uppdelad lagring.
Bör jag ändra Immichs volymsökväg på höger sida i Anpassad installation?
Inte om dokumentationen för just din Immich-distribution inte anger att du ska göra det. Den ursprungliga communityguiden ändrade platserna på värdsidan samtidigt som destinationerna på containersidan bevarades. Om du skriver om en intern destination kan tjänsten hindras från att hitta sina förväntade databas-, cache- eller mediekataloger.
Kan jag behålla Immich på en SSD och bara lagra foton på RAID?
Ja, i princip, och aktuella versioner av Immich stöder både val av uppladdningsplats på värden och montering av externa bibliotek. Den exakta ZimaOS-mappningen beror på vilket Immich-paket och vilken version som är installerad, så kontrollera den aktuella Compose-definitionen innan du ändrar sökvägar.
Varför blir PostgreSQL ohälsosamt efter att lagringsplatsen ändrats?
Möjliga orsaker är bland annat felaktig monteringsdestination, saknade behörigheter, ofullständiga databasfiler eller lagring som inte stöds. Kontrollera att hela databaskatalogen har flyttats korrekt, att destinationen är lokal och skrivbar samt att containerns destination fortfarande överensstämmer med den installerade Compose-konfigurationen.
Kan jag bara kopiera Immichs AppData-mapp till en annan disk?
Det är inte den rekommenderade vägen i nuvarande ZimaOS. En medlem i IceWhale-teamet varnade uttryckligen i tråden för att manuell kopiering kan orsaka fel och rekommenderade migreringsfunktionen för de flesta appflyttar.
Är skärmbildsguiden från april 2025 fortfarande aktuell?
Det är fortfarande användbart som en historisk förklaring av ZimaOS-volymmappningar, men både ZimaOS migreringsfunktioner och Immichs Compose-layout har ändrats sedan dess. Se skärmbilderna som en referens för den ursprungliga konfigurationen och kontrollera sedan fälten och sökvägarna som visas i din aktuella installation innan du gör någon ändring.
