Källanvändaren från mars 2026 byggde sin första NAS från en tunn HP T640-klient med en systemdisk på 128 GB NVMe och tre USB-anslutna hårddiskar. Planen var rimlig: lagra foton på en extern disk, säkerhetskopiera dem till en andra disk och använda en separat disk på 4 TB för Plex-medier. Huvudproblemet var inte att USB-lagring var omöjlig. Immich slutade fungera eftersom appens volymbindningar hade redigerats felaktigt.
Avsnittet om lagringsfunktioner i tråden behöver också en aktuell versionsgräns. I mars 2026 behandlade användaren och svaranden USB-enheter som mer begränsade än intern lagring. Den aktuella dokumentationen för ZimaOS säger nu uttryckligen att USB-enheter följer samma lagringslogik som interna hårddiskar och SSD-enheter och kan användas för lagring, läggas till i en array eller användas för att utöka befintligt utrymme.
Käll-NAS:en var helt beroende av USB-lagring
Konfigurationen använde:
- HP T640-tunn klient med AMD R1505G, 8 GB RAM och 128 GB NVMe;
- två Seagate-hårddiskar på 2,5 tum i separata USB-kabinett;
- en extern WD-hårddisk på 4 TB för Plex-medier.
Eftersom den tunna klienten saknade praktiska interna diskplatser behövde användaren att USB-lagringen fungerade som primär NAS-lagring i stället för som tillfälligt flyttbart medium.
Enheterna visades som USB-lagring
Användaren trodde att externa enheter inte kunde behandlas som intern lagring eller användas för RAID. Det återspeglade beteendet och förväntningarna kring konfigurationen i mars 2026, inte den aktuella lagringsmodellen i ZimaOS.
Aktuella ZimaOS behandlar USB-enheter som vanlig lagring
Den aktuella dokumentationen från IceWhale säger att USB-enheter följer samma logik som interna hårddiskar och SSD-enheter: de kan användas som enskild lagring, läggas till i en array eller användas för att utöka befintligt utrymme.
Använd det aktuella ZimaOS-arbetsflödet för lagring av USB-enheter i stället för att bygga ett nytt system utifrån det äldre antagandet att USB-RAID kategoriskt inte stöds.
Immich-felet berodde på en felaktig bindning mellan fil och katalog
Källanvändaren ändrade Immichs volyminställningar, och Docker returnerade ett felmeddelande om att det inte gick att montera:
/media/Photos/Immich
→ /etc/localtime/etc/localtime inuti containern är en fil, inte en katalog för fotobiblioteket. Docker avvisade därför försöket att montera en mapp ovanpå den filen.
/etc/localtime filmappning.Håll fotolagring och /etc/localtime som separata monteringar
Den som svarade från communityn skiljde korrekt mellan de två rollerna:
- värdmapp för foton → Immichs uppladdnings-/datakatalog;
- värd
/etc/localtimefil → container/etc/localtimefil.
Aktuella regler för Docker-bindningsmontering kräver fortfarande att källans och målets typer överensstämmer. En katalog kan inte monteras över en fil som om de vore utbytbara.
Bindningsmonteringslösningen med /DATA var ett historiskt förslag från communityn
Den som svarade föreslog också att skapa en stabil katalog under /DATA och bindningsmontera USB-sökvägen där, eftersom externa diskar kanske inte är klara när applikationer startas efter en omstart.
Det var vägledning från communityn för källversionen. Nuvarande ZimaOS har bättre stöd för hanterad USB-lagring, så en ny installation bör först använda Storage-gränssnittet och appens väljare för hanterade volymer i stället för att skapa en anpassad bindningsmontering som körs vid uppstart.
Peka Immich mot hanterad lagring, inte mot en rå enhetssökväg
Nuvarande ZimaOS rekommenderar att programdata och stora mediebibliotek placeras på det lagringsutrymme som är avsett för dem, i stället för att fylla systemenheten. Använd värdsökvägen som valts av ZimaOS och behåll sedan den containersökväg som Immich förväntar sig.
För aktuella appmappningar förklarar ZimaOS modell för app-lagringssökvägar hur värd- och containersökvägar hänger ihop.
RAID och säkerhetskopiering löser fortfarande olika problem
Även om nuvarande ZimaOS kan använda USB-enheter i arrayer ersätter RAID 1 inte en andra, oberoende säkerhetskopia. Två USB-diskar i samma array skyddar mot fel på en medlemsdisk, men inte mot oavsiktlig radering, skadlig kod, problem med kabinett eller styrenhet eller förlust av hela NAS-enheten.
Källanvändarens idé om att behålla en extra kopia är fortfarande användbar, även om lagringsfunktionerna har förändrats.
Plex-medier är enklare än Immichs programtillstånd
Användaren betraktade Plex-enheten på 4 TB som förbrukningsbar eftersom videoinnehållet kunde ersättas. Det är en rimlig riskdistinktion: mediefiler, Immich-foton, Immichs databastillstånd och programkonfiguration behöver inte nödvändigtvis ha samma redundans- eller säkerhetskopieringspolicy.
Vanliga frågor om extern USB-lagring
Kan nuvarande ZimaOS använda USB-enheter som hanterad lagring?
Ja. Den aktuella dokumentationen för Storage har uttryckligt stöd för USB-enheter som lagring och medlemmar i arrayer.
Varför slutade Immich fungera efter att katalogen ändrades?
Fotomappen mappades av misstag till containerns /etc/localtime filsökväg.
Bör nuvarande användare skapa manuella /DATA-bindningsmonteringar för varje USB-enhet?
Nej. Det var en historisk lösning från communityn. Börja med aktuella kontroller för hanterad lagring och appvolymer.
