Containergebruikers-ID's configureren voor meerdere 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.

How to Configure Container User IDs Across Multiple NAS Shares

Configureer containergebruikers-ID's voor meerdere NAS-shares door de daadwerkelijke numerieke identiteit van elk containerproces te koppelen aan de eigenaar, groep, ACL en mountmodus van elke share die het nodig heeft.

Forceer niet dat één UID eigenaar is van elke dataset en gebruik chmod 777 niet als integratiestrategie. Een mediaserver heeft mogelijk alleen-lezen toegang tot foto's nodig, een downloader lees- en schrijftoegang tot een ingest-share en een back-upcontainer mogelijk een andere beveiligde bestemming. Gebruik eigenaarschap voor primaire verantwoordelijkheid en groepen of ACL's voor gedeelde toegang.

Leg de drie identiteiten vast voordat je machtigingen wijzigt

Leg voor elke service de eigenaar-UID/GID aan de NAS-zijde vast, evenals de numerieke gebruiker en groepen van het proces in de container en eventuele image-specifieke identiteitsconventies zoals PUID/PGID. Deze drie waarden worden vaak door elkaar gehaald, omdat gebruikersnamen er hetzelfde uit kunnen zien terwijl de numerieke ID's verschillen.

Een actuele uitleg over PUID en PGID maakt het onderscheid duidelijk: PUID en PGID zijn variabelen die door bepaalde containerimages worden geïnterpreteerd, geen universele Docker-instellingen.

Controleer het actieve proces met id in de container en inspecteer bestanden op de host met numeriek eigenaarschap. Ga er niet van uit dat de waarden in Compose het proces daadwerkelijk aansturen, tenzij de image die methode ondersteunt.

Gebruik een primaire eigenaar en gedeelde groepen voor gegevens tussen services

Een share die door één applicatie wordt gebruikt, kan een toegewijde eigenaar hebben. Een share waarnaar meerdere services schrijven, is meestal eenvoudiger te beheren met een doelbewust gedeelde groep of ACL die alleen de benodigde bewerkingen toestaat.

Een praktische uitleg van eigenaarschap met numerieke UID en GID laat zien waarom bestanden in bind mounts het numerieke eigenaarschap van de host volgen en waarom het matchen of bewust koppelen van deze ID's root-eigendom van uitvoer en machtigingsproblemen voorkomt.

In een mediaworkflow kan de downloader bijvoorbeeld eigenaar zijn van de stagingbestanden, terwijl zowel de downloader als de organizer lid zijn van een groep media. Stel directory-overerving, standaard-ACL's of passend umask-gedrag in, zodat nieuwe bestanden automatisch gedeelde toegang behouden.

Geef elke share alleen de mountrechten die de container nodig heeft

Identiteit is slechts één laag. Een correct gekoppelde UID kan nog steeds niet schrijven via een alleen-lezen bind mount, en een container met brede bestandssysteemmachtigingen kan nog steeds veilig worden beperkt door een bibliotheek als alleen-lezen te mounten.

Een uitleg uit 2026 over runtimegebruikersoverschrijvingen legt uit hoe bind mounts het eigenaarschap van de host gebruiken en hoe runtime-instellingen met user: proces-ID's kunnen uitlijnen. Ook wordt gewaarschuwd dat het forceren van een gebruiker images kan verstoren waarvan de opstartlogica andere machtigingen verwacht.

Documenteer voor elk hostpad, containerpad, mountmodus, de vereiste bewerkingen en de verantwoordelijke service. Gebruik alleen-lezen mounts voor bibliotheken die een service alleen gebruikt en reserveer schrijftoegang voor het kleinst mogelijke pad dat deze werkelijk nodig heeft.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Ga bewust om met meerdere NAS-ACL-modellen

SMB/NFSv4-ACL's, POSIX-ACL's, NFS-identiteitskoppeling en eenvoudige Unix-modusbits kunnen verschillende toegangsweergaven bieden. Een share die via SMB werkt als één NAS-gebruiker, kan een containerproces met een andere numerieke identiteit op de host nog steeds weigeren.

Het gerelateerde ZimaSpace-artikel over wijzigingen in NAS-machtigingen laat zien waarom overerving van bestemmings-ACL's, SMB-identiteit, container-UID/GID en umask als afzonderlijke lagen moeten worden gediagnosticeerd.

Wanneer meerdere protocollen één dataset gebruiken, kies dan één machtigingsmodel en documenteer dit. Het herhaaldelijk combineren van ACL-wijzigingen in de NAS-GUI met shellopdrachten als chmod en chown kan ervoor zorgen dat het volgende bestand zich anders gedraagt dan het vorige.

Test het aanmaken van bestanden vanuit elke schrijver voordat je recursief toepast

Maak een tijdelijke testdirectory met het beoogde eigenaarschap en de beoogde ACL. Test vanuit elke container het weergeven, lezen, aanmaken, hernoemen en verwijderen, maar alleen de bewerkingen die de service nodig heeft. Controleer vervolgens op de NAS de numerieke eigenaar, groep, modus en overgeërfde ACL van het nieuwe bestand.

Als oude bestanden wel werken maar nieuw aangemaakte bestanden voor een andere service mislukken, herstel dan het aanmaakpad: groepslidmaatschap, standaard-ACL, umask of de bestandmodus van de applicatie. Een recursieve reparatie van oude gegevens voorkomt niet dat dezelfde mismatch morgen terugkeert.

Rol pas uit naar productie nadat elke schrijver bestanden aanmaakt die de volgende vereiste service zonder verhoogde machtigingen kan gebruiken. Een helder UID/GID-ontwerp is herstelbaar omdat de koppeling gedocumenteerd en herhaalbaar is, niet omdat toevallig elke container als dezelfde gebruiker draait.