Att ändra PUID och PGID i en Docker-app garanterar inte att containern kan skriva till alla filsystem på värden. I den här tråden från februari 2026 kunde HandBrake inte skriva till en SSD som var monterad under /media/sda2, trots att användaren provade flera olika användar- och grupp-ID:n.
Den avgörande detaljen var filsystemet: disken var formaterad med exFAT och monterad som ägd av root. exFAT tillhandahåller inte normalt UID/GID-ägarskap per fil i Linux på samma sätt som ext4, så det gick inte att lösa behörigheterna för värdens monteringspunkt genom att bara ändra användaren i containern.
Problemet gällde inte bara användaren i containern
Användaren visade att HandBrake-containern redan hade värden för PUID och PGID, men mappen på värden fortfarande visades som ägd av root. En användare i communityn skiljde korrekt mellan Dockers identitet och värdfilsystemets semantik.
Den här skillnaden gäller många självhostade appar: containern kan bara använda de behörigheter som värdens monteringspunkt exponerar.
exFAT använder behörighetsmappning på monteringsnivå
exFAT är praktiskt för att flytta diskar mellan olika operativsystem, men lagrar inte Linux-ägarskap och rättighetsbitar på samma sätt som ext4. UID, GID och maskbeteende fastställs när filsystemet monteras.
Därför kan vanliga försök med chown eller chmod verka vara verkningslösa på en exFAT-disk, även om samma kommandon fungerar normalt på ext4.
Den aktuella versionen av ZimaOS listar exFAT som ett filsystem med stöd för läsning och skrivning. Det beskriver grundläggande åtkomst till filsystemet, inte POSIX-behörigheter specifika för Docker. Använd den aktuella tabellen över filsystem som stöds när du avgör om portabilitet eller Linux-infödda behörigheter är viktigast för en serverdisk.
Det gick inte heller att formatera om disken via gränssnittet i det här fallet
Senare granskning visade att disken var monterad på flera platser som hanterades av ZimaOS och fortfarande var upptagen via filhanteringstjänsten. Tråden nådde aldrig en officiell reparationsprocedur från IceWhale, så destruktiva avmonterings- eller fstab-kommandon från community-svar bör inte återpubliceras som officiella instruktioner.
Mappa värdmappen uttryckligen till containern
Ett senare svar visade den korrekta konceptuella volymmappningen: välj en faktisk mapp på värden och mappa den till den sökväg som appen förväntar sig i containern.
Varför ext4 är enklare för containerlagring som bara används i Linux
Rekommendationen från communityn var att använda ext4 för en disk som är avsedd för Docker-arbetslaster, eftersom ext4 stöder normalt Linux-ägarskap och vanliga rättighetsbitar. Det är en praktisk rekommendation för Linux-administration, inte ett krav från IceWhale på att alla datadiskar i ZimaOS måste använda ext4.
Om kompatibilitet mellan olika plattformar är viktigare kan exFAT fortfarande vara lämpligt, men modellen för ägarskap på monteringsnivå måste stämma överens med de användare som kör dina containrar.
Håll applagringen borta från systemdisken
Den aktuella versionen av ZimaOS låter användare välja plats för appdata och mappa riktiga lagringsmappar till containrar. Förklaringen av hur mappar på värden blir containervolymen är användbar innan du ändrar ägarskap eller formaterar om en disk.
Vanliga frågor om behörigheter för Docker-mappar
Varför löste det inte problemet med exFAT-disken att ändra PUID och PGID?
Eftersom exFAT inte lagrar normalt Linux-ägarskap för filer. Monteringspunktens UID/GID och mask avgör hur filsystemet visas för Linux-processer.
Har ZimaOS stöd för läsning och skrivning på exFAT?
Ja. Den aktuella versionen av ZimaOS listar exFAT som ett filsystem med stöd för läsning och skrivning, men det gör det inte likvärdigt med ext4 när det gäller POSIX-ägarskap.
Bör varje datadisk för Docker använda ext4?
Inte alltid, men ext4 är enklare när disken är avsedd för Linux-containrar som är beroende av normalt ägarskap och normala behörigheter.
Löstes formateringsfelet i tråden?
Nej, ingen officiell slutlig lösning publicerades. Disken förblev upptagen via monteringar och tjänster som hanterades av ZimaOS.
