Checklist voor gebruiker- en groepskoppeling van containers voor NAS-shares

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Container User and Group Mapping Checklist for NAS Shares - Zima Store Online

De veilige aanpak is om een controle van de numerieke identiteitskoppeling van NAS-export via hostkoppeling naar het actieve containerproces te behandelen als een reeks waarneembare poorten, niet als één opdracht.

Op een Linux-containerhost met SMB- of NFS-ondersteunde NAS-shares is het praktische risico dat een container een NAS-gemount pad kan zien, maar dat lezen of schrijven mislukt met machtigingsfouten. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende test, interpreteer geslaagde en mislukte resultaten voordat je een andere variabele wijzigt, en stop wanneer de opslag instabiel wordt of de enige herstelbare kopie zou worden blootgesteld. De onderstaande workflow eindigt pas nadat de oorspronkelijke workload werkt of het bewijs een escalatiegrens bereikt.

Identificeer de daadwerkelijke identiteit van het containerproces

Bekijk de documentatie van de image, de Compose-instelling user, omgevingsvariabelen, het gedrag van het entrypoint en de UID, GID en aanvullende groepen van het actieve applicatieproces. Variabelen met de naam PUID en PGID zijn conventies van images, geen universele Docker-functies. Controleer daarom of deze image ze ondersteunt.

Een communitycasus van LinuxServer over een machtigingscasus met PUID en PGID van een container laat zien dat ogenschijnlijk correcte PUID- en PGID-waarden een bind mount toch ontoegankelijk kunnen laten. Gebruik de casus als herinnering om het actieve proces en de mount te inspecteren, niet als bewijs dat elke image dezelfde initialisatielogica gebruikt.

Leg numerieke waarden vast met id in de container en op de host. Stop als de applicatie alleen als root draait omdat machtigingen eerder faalden; roottoegang verbergt het probleem met de koppeling en vergroot de impact van een gecompromitteerde service.

Traceer het eigenaarschap van de NAS naar de hostkoppeling

Inspecteer op de NAS de numerieke eigenaar, groep, modus, ACL en standaard-ACL van de doelmap. Inspecteer op de containerhost dezelfde gemounte objecten en vergelijk de numerieke waarden. Als namen verschillen maar de nummers overeenkomen, zijn de labels alleen cosmetisch; als de nummers verschillen, is het autorisatiepad daadwerkelijk anders.

Neem voor NFS de exportopties, NFS-versie, ID-koppeling, root squashing en de mountidentiteit van de client mee. Neem voor SMB de mountreferentie, de serverzijde van de gemapte identiteit, de presentatieopties uid of gid en het gebruik van Unix-extensies of ACL-vertaling mee.

Wijzig niet tegelijk server-ACL's en client-mountopties. De fase slaagt wanneer één testbestand een bekende numerieke eigenaar heeft en de host een stabiele koppeling ziet na unmounten, opnieuw mounten en opnieuw opstarten.

Test de bind mount en aanvullende groepen

Controleer of het bronpad van de container het verwachte hostmountpunt is en niet een lege lokale map die is aangemaakt voordat de netwerkshare werd gemount. Inspecteer de runtime-mount en test vervolgens als applicatiegebruiker in een tijdelijke submap het weergeven, lezen, aanmaken, hernoemen en verwijderen.

Een casus op Server Fault documenteert een NFS-ACL-machtigingsverschil, zelfs wanneer eigenaar en ACL-vermeldingen op elkaar afgestemd lijken. Dit illustreert waarom ook het ACL-masker, de serverkoppeling en de effectieve identiteit moeten worden geïnspecteerd. Leg getfacl vast voor zowel de map als het aangemaakte bestand.

Als groepstoegang bedoeld is, voeg dan de ondersteunde aanvullende numerieke groep toe en maak de container opnieuw aan, omdat procesgroepen bij het starten worden vastgelegd. Gebruik de ZimaSpace-handleiding over diagnose van een leeg containerpad wanneer de applicatie met een leeg pad start; dat is een probleem met de mountvolgorde, geen ACL-probleem.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Pas de nauwst mogelijke identiteitscorrectie toe en test opnieuw

Geef de voorkeur aan het afstemmen van de door de applicatie ondersteunde UID, GID of aanvullende groep op het NAS-beleid. Gebruik een gedeelde groep en overgeërfde ACL wanneer meerdere services samenwerken. Vermijd wereldschrijfbare machtigingen, recursieve eigendomswijzigingen over niet-gerelateerde datasets en geprivilegieerde containers als snelkoppeling.

Maak de container opnieuw aan, mount de share opnieuw als de koppelingsopties zijn gewijzigd en herhaal dezelfde bewerkingen. Start de host eenmaal opnieuw op om te controleren of de mountvolgorde en numerieke identiteit na het opstarten behouden blijven. Controleer of nieuw aangemaakte bestanden schrijfbaar blijven voor de beoogde menselijke clients zonder de container onnodige rechten te geven.

Sluit de checklist wanneer de app de oorspronkelijke workload uitvoert, geweigerde bewerkingen geweigerd blijven en het eigenaarschap stabiel blijft na opnieuw opstarten. Escaleer wanneer user namespaces, rootless-koppelingen of NAS-identiteitsservices ID's herschrijven op een manier die de gekozen image niet kan ondersteunen.