När chown och chmod verkar inte göra någonting på en USB-enhet bör du först identifiera filsystemet. Svaret i källcommunityn misstänkte NTFS eller exFAT, vilket är en rimlig förklaring eftersom dessa filsystem inte fungerar som ext4/Btrfs med inbyggt Unix-ägarskap och lägesbitar.
Källan berättar inte vilket filsystem MikeFrizz faktiskt använde, och det ursprungliga inlägget följdes aldrig upp med ett bekräftat resultat. Detta bör därför förbli en filsystemsmedveten felsökningsguide, inte ett påstående om att alla ZimaOS-USB-enheter ignorerar behörigheter.
Identifiera USB-enhetens filsystem innan du ändrar behörigheter
Kontrollera diskformatet i ZimaOS Storage eller med ett skrivskyddat kommando som:
lsblk -fNuvarande ZimaOS stöder läs- och skrivåtkomst till NTFS, exFAT, ext4 och Btrfs samt flera andra format, men att läsning och skrivning stöds innebär inte att alla filsystem bevarar Unix-metadata för UID/GID/lägesbitar på samma sätt.
Använd den aktuella matrisen över stödda diskformat.
NTFS och exFAT visar ofta behörigheter genom monteringsalternativ
I Linux visar exFAT och många NTFS-monteringskonfigurationer filer med ägar- och lägesvärden som härrör från monteringsalternativ, i stället för att lagra vanliga POSIX-behörighetsändringar exakt som ext4. Därför kan chown eller chmod verka vara verkningslösa eller återställas när enheten monteras om.
Det betyder inte att enheten är skrivskyddad eller trasig.
Ett Linux-filsystem ger Docker de mest förutsägbara POSIX-behörigheterna
Om USB-disken är avsedd för ZimaOS/Linux och du behöver verklig kontroll över UID/GID/lägesbitar är ext4 eller Btrfs ett naturligare val. Omformatering förstör data, så kopiera data någon annanstans innan du byter filsystem.
Undvik att använda en symbolisk länk på värden som primär migreringsmetod för Docker-lagring
Källanvändaren kopierade Immich-data till USB och skapade en symbolisk länk från den gamla platsen. Containrar följer inte automatiskt symboliska länkar på värden till platser utanför deras monterade volymnamnrymd. Den symboliska länken kan peka på en sökväg som containern inte kan se.
En direkt bind-montering/volym är tydligare och enklare att granska.
Mappa USB-mappen direkt till Immich
I stället för att behålla en gammal sökväg på värden och omdirigera den med en symbolisk länk bör du redigera Immich-appens/container-volym så att den riktiga USB-mappen monteras på den containersökväg som Immich förväntar sig.
Aktuell dokumentation från IceWhale förklarar att sökvägen på värden kan ändras utan att sökvägen i containern ändras.
Använd den aktuella modellen för volymsökvägar i ZimaOS Docker.
Flytta inte alla Immich-komponenter till godtycklig USB-lagring utan eftertanke
Immichs mediebibliotek och uppladdningslagring har andra krav än PostgreSQL-databasen och applikationens tillstånd. Innan du flyttar kataloger bör du identifiera exakt vilken volym på värden som flyttas och följa aktuell vägledning för Immich-distribution och migrering.
Flytta inte en aktiv databaskatalog med en symbolisk länk medan containrarna körs.
Åtgärda mappningen innan du använder ett omfattande chmod 777
Om containern inte kan se rätt mapp på värden löser en ändring av behörigheterna inte sökvägen. Verifiera monteringen först och justera sedan endast den minsta åtkomst till användare/grupp som containern behöver.
Vanliga frågor om USB-behörigheter
Stöder ZimaOS läsning och skrivning för NTFS och exFAT?
Ja, aktuell dokumentation från IceWhale anger att båda stöds för läsning och skrivning.
Varför kan chmod/chown ändå fungera annorlunda?
Dessa filsystem använder inte inbyggd Linux-semantik för POSIX-ägarskap och lägesbitar på samma sätt som ext4 eller Btrfs.
Bekräftades källanvändarens filsystem och slutliga lösning?
Nej. Filsystemet antogs av ett svar i communityn, och det ursprungliga inlägget rapporterade inget resultat.
