Det ursprungliga målet i den här tråden från november 2025 var enkelt: behålla ZimaOS och programmen på mini-datorns interna SSD på 512 GB och använda en extern Seagate USB-hårddisk på 5 TB för media och nedladdningar. Problemet uppstod när den externa disken behandlades som en vanlig Linux-servermontering innan man förstått hur ZimaOS redan hanterar lagring.
Användaren experimenterade med manuell montering under /var, servern kraschade senare och ZimaOS installerades om. Därefter monterades disken under en ZimaOS-datasökväg och mappades till SABnzbd, men programmet returnerade fortfarande ett behörighetsfel. Den här tråden innehåller därför två separata lärdomar: välj först en säker, hanterad värdsökväg och lös sedan behörigheterna för containern separat.
Använd inte /var som en godtycklig monteringspunkt för USB
ZimaOS är ett operativsystem i appliance-stil med hanterade systemsökvägar. Källanvändaren uppgav att den externa enheten monterades under /var verkade fungera inledningsvis men följdes av en fullständig serverkrasch och ominstallation.
Tråden bevisar inte att själva monteringen direkt orsakade kraschen, men den är tillräcklig anledning att inte använda systemkataloger som vanliga lagringsplatser för mediadiskar.
Låt aktuella ZimaOS hantera den externa enheten
Aktuella ZimaOS har betydligt bredare stöd för USB-lagring än miljön från 2025 i den här tråden. En USB-disk kan läggas till via Inställningar > Lagring och sedan användas som vanlig lagring i stället för att manuellt kopplas till en påhittad Linux-monteringspunkt.
För en ny installation börjar du med det aktuella ZimaOS-flödet för att lägga till USB-lagring. När disken har hanterats använder du dess faktiska lagringsmapp i programmets volymmappning.
Källdisken dök så småningom upp under ZimaOS-hanterade sökvägar
Den exakta sökvägen som visas i en installation från 2025 bör inte kopieras till en annan server. Enhetsnamn som sda, sdb, och sdc kan ändras beroende på startordning och ansluten hårdvara.
Mappa en mapp, inte den råa blockenheten
Docker-program bör normalt få en katalog, till exempel en nedladdnings- eller mediamapp, inte den råa enheten. /dev/sda1. ZimaOS monterar filsystemet; containern får en värdmapp från det monterade filsystemet.
Den aktuella förklaringen av hur värdlagring blir en containervolym hjälper till att undvika att blanda ihop diskenheten, monteringspunkten och containersökvägen.
En korrekt montering kan fortfarande ge ett behörighetsfel
Källanvändaren nådde /DATA/HDD1 och mappade den till SABnzbd, men programmet kunde inte använda den valda nedladdningskatalogen. Det innebär att lagringssynlighet inte längre var det enda problemet.
Docker-processer körs som en användare eller grupp inuti containern. Om värdmappen ägs av en annan användare och har begränsade behörigheter kan containern se sökvägen men ändå inte kunna skapa filer.
Kopiera inte PUID 999 blint
Ett communitysvar uppmanade användaren att ändra PUID från 1000 till 999. Det kan ha stämt med svararens ZimaOS-kontomodell, men det är ingen universell konstant.
Innan du ändrar PUID eller PGID bör du identifiera ägarskapet för den faktiska värdmappen och vilken användare programmet förväntas köras som. Ett numeriskt värde som fungerar i en installation kan hänvisa till ett annat konto i en annan.
Rekursiv chmod och chown är kraftfulla och destruktiva
Ett senare svar från gemenskapen föreslog rekursiva chmod 775 och chown över nedladdningssökvägen. Dessa kommandon kan vara användbara verktyg för Linux-administration, men de ändrar alla filer och kataloger under målet. De publicerades inte av IceWhale-personal i den här tråden.
Innan du ändrar ägarskap rekursivt:
- bekräfta den exakta målsökvägen;
- bekräfta att filsystemet stöder normalt Linux-ägarskap;
- förstå vilka användare eller tjänster som redan är beroende av mappen;
- säkerhetskopiera viktiga metadata eller behörigheter om mappen delas av flera appar.
Filsystemstypen kan ändra behörighetsmodellen
En ext4-disk lagrar Linux-UID, GID och lägesbitar direkt. exFAT och vissa NTFS-konfigurationer kan i stället presentera ägarskap genom monteringsalternativ. Om ändringar av PUID inte har någon effekt bör du kontrollera filsystemet innan du ändrar appinställningarna upprepade gånger.
En renare layout för medieappar
En praktisk utformning är:
- intern SSD: ZimaOS-systemet och små applikationskörningar;
- stor extern hårddisk: media, nedladdningar, säkerhetskopior och annan massdata;
- beständiga AppData: placeras på en lagringsplats med tillräcklig kapacitet och säkerhetskopiering;
- varje app: uttryckliga volymmappningar till endast de mappar den behöver.
Detta hindrar en medienedladdning från att fylla systemdisken och gör det enklare att säkerhetskopiera appkonfigurationen separat från stora mediefiler.
Vanliga frågor om externa hårddiskar i ZimaOS
Bör jag montera en extern hårddisk manuellt under /var?
Nej, inte vid vanlig användning av aktuella ZimaOS. Använd lagringsgränssnittet och hanterade lagringssökvägar.
Bör SABnzbd mappa /dev/sda1 direkt?
Nej. Mappa en vanlig värdkatalog från det monterade filsystemet till containerns förväntade nedladdningssökväg.
Varför kan appen se mappen men misslyckas med att skriva?
Behörigheter eller ägarskap i värdfilsystemet, eller containerns PUID/PGID, kanske inte tillåter skrivning.
Är PUID 999 ett standardvärde i ZimaOS?
Nej. Det var ett gemenskapsspecifikt förslag och bör verifieras på det faktiska systemet.
