Källan identifierar korrekt det verkliga ägarskiktet: när en container skapar en katalog i en monterad ZimaOS-mapp ärver den nya katalogen normalt identiteten och umask-beteendet från processen som körs inuti containern, inte de behörigheter som du hoppades att den överordnade mappen automatiskt skulle tvinga fram.
Därför kan en överordnad mapp med skrivbehörighet för alla ändå få nyskapade underkataloger med root:root och behörigheten 0755. Om programmet körs som root och använder en standardumask är root-ägda underkataloger förväntade, såvida avbilden inte stöder PUID/PGID, en specifik containeranvändare, setgid-gruppärvning, standard-ACL:er eller någon annan behörighetsmodell.
Källexemplet var en monterad säkerhetskopieringsmapp
Användaren beskrev en sökväg som:
/media/Daten/Backupdär nyskapade underkataloger fick:
root:root
drwxr-xr-xEn icke-root-användare som UID 999 kunde då läsa, men inte skapa filer i de nya underkatalogerna.
En överordnad mapp med 0777 tvingar inte fram ägarskap för underkataloger
Den överordnade mappens skrivbehörighet gör att containerprocessen kan skapa en underkatalog. Den gör inte automatiskt att underkatalogen ärver den överordnade mappens ägare eller grupp, såvida filsystems- och gruppregler inte har konfigurerats för det beteendet.
Skaparens UID/GID och processens umask avgör normalt resultatet.
Använd PUID/PGID endast när containeravbilden stöder dem
Många avbilder i LinuxServer-stil har miljövariablerna PUID och PGID. Andra avbilder ignorerar dessa variabler helt och kräver fältet user: i Docker eller programspecifika inställningar.
Den aktuella Syncthing-dokumentationen från IceWhale instruerar uttryckligen användare att hämta de faktiska användar-ID:na i ZimaOS med:
id -u username
id -g usernameoch sedan ange dessa värden i appens PUID/PGID-fält.
Se det aktuella PUID/PGID-exemplet för ZimaOS.
umask styr vilka behörighetsbitar som tas bort vid skapandet
Ett program som skapar kataloger med grundläget 0777 under en typisk umask på 022 skapar kataloger med behörigheten 0755. Ett arbetsflöde för gruppsamarbete kan använda en annan umask om programmet stöder det.
Ställ inte in en extremt tillåtande umask globalt bara för att åtgärda ett enda program.
setgid kan hjälpa till att behålla en delad grupp i nya underkataloger
I Linux-interna filsystem kan setgid-biten på en delad katalog göra att nyskapade underkataloger ärver katalogens grupp. Detta är användbart när flera tjänster eller användare avsiktligt samarbetar genom en gemensam grupp.
Det ändrar inte den skapande processens användar-ID och kanske inte fungerar på samma sätt på NTFS- eller exFAT-monteringar som efterliknar Unix-ägarskap genom monteringsalternativ.
Standard-ACL:er ger mer explicit ärvning
På filsystem som stöder POSIX-ACL:er kan standard-ACL-poster definiera vilka behörigheter nya objekt får. Detta är ofta renare än att upprepade gånger köra rekursiva chmod-kommandon efter varje säkerhetskopieringsjobb.
Innan man förlitar sig på en konfiguration som endast görs via skalet bör man kontrollera om det aktuella ZimaOS-gränssnittet visar ett fullständigt ACL-arbetsflöde för den aktuella lagringssökvägen.
Källan var en funktionsförfrågan, inte en befintlig ZimaOS-inställning
Författaren efterfrågade global kontroll av PUID/PGID, en växlingsfunktion för ärvning, hantering av umask, stöd för setgid samt ett grafiskt gränssnitt för rekursiv korrigering. Tråden innehåller inget svar från IceWhale som bekräftar att dessa funktioner har implementerats.
Presentera inte listan över önskemål som aktuella alternativ under Inställningar.
Korrigera appens identitet innan du ändrar behörigheterna rekursivt på hela disken
Om en säkerhetskopieringsapp upprepade gånger återskapar root-ägda mappar innebär det att köra chown -R efter varje jobb att man behandlar symptomet. Konfigurera först containeridentitet, grupp och umask korrekt och reparera sedan endast det berörda trädet.
Aktuella appinställningar i ZimaOS låter användare granska volymmappningar och appkonfiguration, medan de exakta behörighetsvariablerna beror på avbilden.
Vanliga frågor om ägarskap för monterade mappar
Varför kan en underkatalog bli root:root under en skrivbar överordnad mapp?
Eftersom processen inuti containern skapade den som root och den överordnade katalogen inte automatiskt åsidosätter skaparens identitet.
Fungerar PUID och PGID för alla Docker-avbilder?
Nej. De är avbildsspecifika miljövariabelkonventioner, inte universella Docker-variabler.
Bekräftade IceWhale en global växlingsfunktion för behörighetsärvning i källan?
Nej. Tråden är en funktionsförfrågan utan bekräftelse på att den har implementerats.
