De brongebruiker uit maart 2026 bouwde een eerste NAS met een HP T640-thin client, een NVMe-systeemschijf van 128 GB en drie via USB aangesloten harde schijven. Het plan was verstandig: foto's op één externe schijf bewaren, er een back-up van maken op een tweede schijf en Plex-media op een afzonderlijke schijf van 4 TB zetten. De belangrijkste fout was niet dat USB-opslag onmogelijk was. Immich stopte omdat de volumetoewijzingen van de app onjuist waren bewerkt.
Voor het deel over de opslagmogelijkheden van de thread is ook een actuele tijdsgrens nodig. In maart 2026 beschouwden de gebruiker en de beantwoorder USB-schijven als beperkter dan interne opslag. In de huidige documentatie van ZimaOS staat echter expliciet dat USB-schijven dezelfde opslaglogica volgen als interne HDD's en SSD's en kunnen worden gebruikt voor opslag, aan een array kunnen worden toegevoegd of kunnen worden gebruikt om bestaande ruimte uit te breiden.
De bron-NAS was volledig afhankelijk van USB-opslag
De configuratie bestond uit:
- HP T640-thin client met AMD R1505G, 8 GB RAM en 128 GB NVMe;
- twee Seagate-harde schijven van 2,5 inch in afzonderlijke USB-behuizingen;
- één externe WD-harde schijf van 4 TB voor Plex-media.
Omdat de thin client geen handige interne schijfposities had, moest de gebruiker USB-opslag als primaire NAS-opslag kunnen gebruiken in plaats van als tijdelijk verwijderbaar medium.
De schijven verschenen als USB-opslag
De gebruiker dacht dat externe schijven niet als interne opslag konden worden behandeld of voor RAID konden worden gebruikt. Dat weerspiegelde het gedrag en de verwachtingen rond de configuratie van maart 2026, niet het huidige opslagmodel van ZimaOS.
Huidig ZimaOS behandelt USB-schijven als normale opslag
Volgens de huidige documentatie van IceWhale volgen USB-schijven dezelfde logica als interne HDD's en SSD's: ze kunnen als afzonderlijke opslag worden gebruikt, aan een array worden toegevoegd of worden gebruikt om bestaande ruimte uit te breiden.
Gebruik de huidige ZimaOS-opslagworkflow voor USB-schijven in plaats van een nieuw systeem te bouwen rond de oudere aanname dat USB-RAID categorisch niet wordt ondersteund.
De Immich-fout was een toewijzingsfout tussen bestand en map
De gebruiker van de bron had de volumekinstellingen van Immich gewijzigd en Docker gaf een foutmelding dat het de volgende map niet kon koppelen:
/media/Photos/Immich
→ /etc/localtime/etc/localtime in de container een bestand is en geen map voor de fotobibliotheek. Docker weigerde daarom de poging om een map boven op dat bestand te koppelen.
/etc/localtime bestandskoppeling.Houd foto-opslag en /etc/localtime als afzonderlijke mounts
De beantwoorder uit de community maakte terecht onderscheid tussen de twee rollen:
- hostmap voor foto's → upload-/gegevensmap van Immich;
- host
/etc/localtimebestand → container/etc/localtimebestand.
De huidige Docker-regels voor bind-mounts vereisen nog steeds dat de bron en bestemming hetzelfde type hebben. Een map kan niet over een bestand worden gemount alsof ze uitwisselbaar zijn.
De bind-mount-workaround met /DATA was een historische suggestie uit de community
De beantwoorder stelde ook voor om een stabiele map aan te maken onder /DATA en koppel het USB-pad daar als bind-mount, omdat externe schijven mogelijk niet gereed zijn wanneer applicaties na een herstart worden gestart.
Dat was communityadvies voor de bronversie. Het huidige ZimaOS biedt sterkere ondersteuning voor beheerde USB-opslag. Gebruik daarom bij een nieuwe installatie eerst de opslaginterface en de beheerde volumekiezer van de app, in plaats van een aangepaste bind-mount die bij het opstarten wordt aangemaakt.
Laat Immich naar beheerde opslag verwijzen, niet naar een onbewerkt apparaatpad
Het huidige ZimaOS raadt aan om applicatiegegevens en grote mediabibliotheken op de daarvoor bedoelde opslagruimte te plaatsen in plaats van de systeemschijf te vullen. Gebruik het door ZimaOS geselecteerde hostpad en behoud vervolgens het containerpad dat Immich verwacht.
Voor huidige applicatiekoppelingen legt het model voor app-opslagpaden van ZimaOS uit hoe host- en containerpaden op elkaar aansluiten.
RAID en back-ups lossen nog steeds verschillende problemen op
Hoewel het huidige ZimaOS USB-schijven in arrays kan gebruiken, is RAID 1 geen vervanging voor een tweede onafhankelijke back-up. Twee USB-schijven in één array beschermen tegen een defect aan een schijf, maar niet tegen per ongeluk verwijderen, malware, problemen met de behuizing of controller, of verlies van de volledige NAS.
Het idee van de brongebruiker om een extra kopie te bewaren blijft nuttig, ook al zijn de opslagfuncties veranderd.
Plex-media zijn eenvoudiger dan de applicatiestatus van Immich
De gebruiker beschouwde de Plex-schijf van 4 TB als vervangbaar, omdat de video-inhoud opnieuw kon worden verkregen. Dat is een redelijk onderscheid in risico: mediabestanden, Immich-foto's, de databasestatus van Immich en de applicatieconfiguratie hoeven niet noodzakelijk hetzelfde redundantie- of back-upbeleid te krijgen.
Veelgestelde vragen over externe USB-opslag
Kan het huidige ZimaOS USB-schijven gebruiken als beheerde opslag?
Ja. De huidige opslagdocumentatie ondersteunt USB-schijven expliciet als opslag en als leden van een array.
Waarom werkte Immich niet meer nadat de map was gewijzigd?
De fotomap was per ongeluk gekoppeld aan het /etc/localtime bestandspad.
Moeten huidige gebruikers voor elke USB-schijf handmatig bind-mounts naar /DATA aanmaken?
Nee. Dat was een historische workaround uit de community. Begin met de huidige beheerde opslag- en app-volumebeheeropties.
