Het oorspronkelijke doel in deze thread uit november 2025 was eenvoudig: ZimaOS en de applicaties op de interne SSD van 512 GB van de minicomputer houden en een externe Seagate-USB-harde schijf van 5 TB gebruiken voor media en downloads. De moeilijkheid ontstond doordat de externe schijf werd behandeld als een mount op een algemene Linux-server, voordat duidelijk was hoe ZimaOS opslag al beheert.
De gebruiker experimenteerde met handmatig mounten onder /var, waarna de server crashte en ZimaOS opnieuw werd geïnstalleerd. Daarna mountten ze de schijf onder een ZimaOS-datapad en koppelden ze die aan SABnzbd, maar de applicatie gaf nog steeds een toestemmingsfout. Deze thread bevat daarom twee afzonderlijke lessen: kies eerst een veilig, beheerd hostpad en los daarna de containerrechten afzonderlijk op.
Gebruik /var niet als willekeurig USB-mountpunt
ZimaOS is een besturingssysteem in appliance-stijl met beheerde systeempaden. De oorspronkelijke gebruiker zei dat de externe schijf werd gemount onder /var leek aanvankelijk te werken, maar werd gevolgd door een volledige servercrash en herinstallatie.
De thread bewijst niet dat de mount zelf de crash rechtstreeks veroorzaakte, maar is voldoende reden om systeemmappen niet als normale opslaglocaties voor mediaschijven aan te bevelen.
Laat het huidige ZimaOS de externe schijf beheren
Het huidige ZimaOS biedt veel uitgebreidere ondersteuning voor USB-opslag dan de omgeving uit 2025 in deze thread. Een USB-schijf kan worden toegevoegd via Instellingen > Opslag en vervolgens als gewone opslag worden gebruikt, in plaats van handmatig aan een verzonnen Linux-mountpunt te worden gekoppeld.
Gebruik voor een nieuwe implementatie de huidige ZimaOS-workflow voor het toevoegen van USB-opslag. Gebruik zodra de schijf wordt beheerd de echte opslagmap ervan in de volumekoppeling van de applicatie.
De bronschijf verscheen uiteindelijk onder door ZimaOS beheerde paden
Het exacte pad dat in een installatie uit 2025 wordt weergegeven, mag niet naar een andere server worden gekopieerd. Apparaatnamen zoals sda, sdb, en sdc kan veranderen afhankelijk van de opstartvolgorde en aangesloten hardware.
Koppel een map, niet het onbewerkte blokapparaat
Dockerapplicaties horen normaal gesproken een map te ontvangen, zoals een download- of mediamap, niet het onbewerkte apparaat. /dev/sda1. ZimaOS koppelt het bestandssysteem; de container ontvangt een hostmap uit dat gekoppelde bestandssysteem.
De huidige uitleg over hoe hostopslag een containervolume wordt helpt verwarring tussen het schijfapparaat, het koppelpunt en het containerpad te voorkomen.
Een correcte koppeling kan nog steeds een toestemmingsfout veroorzaken
De gebruiker bereikte /DATA/HDD1 en koppelde deze aan SABnzbd, maar de applicatie kon de geselecteerde downloadmap niet gebruiken. Dat betekent dat zichtbaarheid van de opslag niet langer het enige probleem was.
Dockerprocessen draaien als een gebruiker of groep in de container. Als de hostmap eigendom is van een andere gebruiker en beperkte rechten heeft, kan de container het pad zien maar nog steeds geen bestanden aanmaken.
Kopieer PUID 999 niet blind
In een communityreactie werd de gebruiker geadviseerd PUID van 1000 naar 999 te wijzigen. Dat kan overeenkomen met het accountmodel van ZimaOS van de beantwoorder, maar het is geen universele constante.
Voordat je PUID of PGID wijzigt, bepaal je eerst wie eigenaar is van de daadwerkelijke hostmap en onder welke gebruiker de applicatie hoort te draaien. Een numerieke waarde die op de ene installatie werkt, kan op een andere installatie naar een ander account verwijzen.
Recursieve chmod en chown zijn krachtig en destructief
Een later communityantwoord stelde recursief chmod 775 en chown voor het downloadpad. Die opdrachten kunnen nuttige Linux-beheertools zijn, maar ze wijzigen elk bestand en elke map onder het doel. Ze zijn in deze thread niet door medewerkers van IceWhale geplaatst.
Voordat je het eigenaarschap recursief wijzigt:
- bevestig het exacte doelpad;
- bevestig dat het bestandssysteem normaal Linux-eigenaarschap ondersteunt;
- begrijp welke gebruikers of services al afhankelijk zijn van de map;
- maak een back-up van belangrijke metagegevens of machtigingen als de map door meerdere applicaties wordt gedeeld.
Het bestandssysteemtype kan het machtigingsmodel veranderen
Een ext4-schijf slaat Linux-UID's, GID's en modusbits rechtstreeks op. exFAT en sommige NTFS-configuraties kunnen eigenaarschap in plaats daarvan via opties op aankoppelingsniveau weergeven. Als wijzigingen aan de PUID geen effect hebben, controleer dan eerst het bestandssysteem voordat je de applicatie-instellingen steeds opnieuw wijzigt.
Een overzichtelijkere indeling voor media-apps
Een praktische indeling is:
- interne SSD: ZimaOS-systeem en kleine runtime voor applicaties;
- grote externe HDD: media, downloads, back-ups en andere bulkgegevens;
- persistente AppData: geplaatst op een opslaglocatie met voldoende capaciteit en back-updekking;
- elke app: expliciete volumekoppelingen naar alleen de mappen die de app nodig heeft.
Zo voorkom je dat een mediadownload de systeemschijf vult en wordt het eenvoudiger om de applicatieconfiguratie afzonderlijk van grote mediabestanden te back-uppen.
Veelgestelde vragen over externe HDD's in ZimaOS
Moet ik een externe HDD handmatig onder /var aankoppelen?
Niet voor normaal huidig gebruik van ZimaOS. Gebruik de interface Opslag en beheerde opslagpaden.
Moet SABnzbd /dev/sda1 rechtstreeks koppelen?
Nee. Koppel een normale hostmap van het aangekoppelde bestandssysteem aan het verwachte downloadpad van de container.
Waarom kan de app de map zien, maar er niet naartoe schrijven?
De machtigingen of eigenaar van het hostbestandssysteem, of de PUID/PGID van de container, staan schrijven mogelijk niet toe.
Is PUID 999 een standaardwaarde in ZimaOS?
Nee. Het was een suggestie die specifiek was voor een community en moet op het daadwerkelijke systeem worden geverifieerd.
