De bron identificeert de daadwerkelijke eigendomslaag correct: wanneer een container een map aanmaakt in een gemounte ZimaOS-map, erft de nieuwe map normaal gesproken de identiteit en het umask-gedrag van het proces dat in de container draait, en niet de rechten waarvan je hoopte dat de bovenliggende map die automatisch zou afdwingen.
Daarom kan een voor iedereen schrijfbare bovenliggende map toch eindigen met nieuw aangemaakte submappen van root:root met rechten 0755. Als de toepassing als root draait en een standaard-umask gebruikt, zijn door root beheerde submappen te verwachten, tenzij de image PUID/PGID, een specifieke containergebruiker, setgid-groepserving, standaard-ACL's of een ander rechtenmodel ondersteunt.
Het bronvoorbeeld betrof een gemounte back-upmap
De gebruiker beschreef een pad zoals:
/media/Daten/Backupwaar nieuw aangemaakte submappen werden:
root:root
drwxr-xr-xEen niet-rootgebruiker, zoals UID 999, kon vervolgens wel lezen maar geen bestanden aanmaken in die nieuwe submappen.
Een bovenliggende map met 0777 dwingt het eigenaarschap van submappen niet af
De schrijfrechten van de bovenliggende map staan het containerproces toe een submap aan te maken. Ze zorgen er niet automatisch voor dat de submap de eigenaar of groep van de bovenliggende map overneemt, tenzij bestandssysteem- of groepsregels voor dat gedrag zijn ingesteld.
De UID/GID van de maker en de umask van het proces bepalen het normale resultaat.
Gebruik PUID/PGID alleen als de containerimage dit ondersteunt
Veel images in LinuxServer-stijl bieden omgevingsvariabelen PUID en PGID. Andere images negeren deze variabelen volledig en vereisen het Docker-veld user: of toepassingsspecifieke instellingen.
De huidige Syncthing-instructies van IceWhale voor ZimaOS adviseren gebruikers expliciet om de echte ZimaOS-gebruikers-ID's op te vragen met:
id -u username
id -g usernameen die waarden vervolgens in de PUID/PGID-velden van de app te plaatsen.
Zie het huidige ZimaOS PUID/PGID-voorbeeld.
umask bepaalt welke rechtenbits bij het aanmaken worden verwijderd
Een app die mappen aanmaakt met een basismodus van 0777, produceert bij een gebruikelijke umask van 022 mappen met rechten 0755. Voor samenwerking binnen een groep kan een andere umask worden gebruikt, als de toepassing dit ondersteunt.
Stel niet globaal een extreem permissieve umask in om slechts één app te repareren.
setgid kan helpen om een gedeelde groep op nieuwe submappen te behouden
Op Linux-eigen bestandssystemen kan het instellen van de setgid-bit op een gedeelde map ervoor zorgen dat nieuw aangemaakte items de groep van de map overnemen. Dit is nuttig wanneer meerdere services/gebruikers bewust via één groep samenwerken.
Hierdoor verandert de gebruikers-ID van het aanmakende proces niet. Bovendien werkt dit mogelijk niet hetzelfde op NTFS-/exFAT-koppelingen die Unix-eigenaarschap via koppelopties nabootsen.
Standaard-ACL's bieden explicietere overerving
Op bestandssystemen die POSIX-ACL's ondersteunen, kunnen standaard-ACL-items bepalen welke rechten nieuwe items krijgen. Dit is vaak netter dan na elke back-uptaak opnieuw recursief chmod uitvoeren.
Of de huidige ZimaOS-interface voor een bepaald opslagpad een volledige ACL-werkwijze aanbiedt, moet worden gecontroleerd voordat je uitsluitend op configuratie via de shell vertrouwt.
De bron was een functieverzoek, geen bestaande ZimaOS-instelling
De auteur vroeg om globale PUID/PGID-regeling, een overervingsschakelaar, umask-verwerking, setgid-ondersteuning en een grafische interface voor recursieve reparaties. In de discussie staat geen reactie van IceWhale waarin wordt bevestigd dat deze functies zijn geïmplementeerd.
Presenteer de lijst met verzoeken niet als huidige opties in Instellingen.
Herstel eerst de app-identiteit voordat je de hele schijf recursief wijzigt
Als een back-upapp steeds opnieuw door root beheerde mappen aanmaakt, behandelt het uitvoeren van chown -R na elke taak alleen het symptoom. Stel eerst de containeridentiteit, groep en umask correct in en herstel daarna alleen de betreffende mappenstructuur.
Met de huidige app-instellingen van ZimaOS kunnen gebruikers volumekoppelingen en appconfiguratie bekijken, terwijl de exacte rechtenvariabelen afhankelijk zijn van de image.
Veelgestelde vragen over eigenaarschap van gemounte mappen
Waarom kan een submap root:root worden onder een schrijfbare bovenliggende map?
Omdat het proces in de container de map als root heeft aangemaakt en de bovenliggende map de identiteit van de maker niet automatisch overschrijft.
Werken PUID en PGID met elke Docker-image?
Nee. Het zijn image-specifieke conventies voor omgevingsvariabelen, geen universele Docker-variabelen.
Heeft IceWhale in de bron een globale schakelaar voor overerving van rechten bevestigd?
Nee. De discussie is een functieverzoek zonder bevestiging van implementatie.
