Waarom veranderen de bestandseigenaren van containers na het kopiëren van appgegevens?
De eigenaars van containerbestanden veranderen na het kopiëren wanneer numerieke UID/GID-waarden niet behouden blijven of de doelruntime ze opnieuw toewijst of herschrijft.
Op een thuis-NAS kan hetzelfde bestand op de host met de ene gebruikersnaam worden weergegeven en in een container met een andere, omdat eigenaarschap als nummers wordt opgeslagen terwijl elke omgeving die nummers via een andere accountdatabase omzet. Kopieën die via een GUI, SMB-share, archief, root-shell, migratietool of container-entrypoint worden gemaakt, kunnen het eigenaarschap ook vervangen. Diagnoseer eerst de numerieke identiteit en maak daarna onderscheid tussen kopieergedrag, runtime-gebruikersinstellingen, opstartscripts, gebruikersnaamruimten en mapping van netwerkbestandssystemen voordat je de rechten in de volledige app-datastructuur wijzigt.
Vergelijk numerieke UID en GID voordat je gebruikersnamen vergelijkt
Inspecteer de bron en bestemming met numeriek eigenaarschap, niet alleen met namen. Noteer voor één representatief bestand en de bovenliggende map op zowel de host als in de container de UID, GID, modus, ACL's, uitgebreide kenmerken en het bestandssysteem.
Docker-bind-mounts stellen hostbestanden beschikbaar aan processen die mogelijk een andere gebruikersdatabase gebruiken. Een Docker-communitydiscussie legt uit waarom betrouwbare toegang afhankelijk is van numerieke UID/GID-overeenkomst en niet alleen van overeenkomende gebruikersnamen.
Als de nummers identiek zijn maar de weergegeven namen verschillen, is het eigenaarschap mogelijk helemaal niet veranderd. Corrigeer dan de documentatie of accountmapping in plaats van de gegevens recursief te herschrijven. Als de nummers verschillen, bewaar dan het bewijsmateriaal en ga verder met de kopieer- en runtimefasen.
Stel vast of de kopie het eigenaarschap behield of opnieuw aanmaakte
Noteer het exacte kopieerpad: bestandsbeheer op de host, cp, rsync, tar-archief, SMB/NFS-client, herstel van een back-up, Docker-kopieeropdracht of tijdelijke migratiecontainer. Elke methode heeft andere standaardinstellingen voor eigenaar, groep, ACL's en uitgebreide kenmerken.
Een kopie die als root wordt uitgevoerd, kan het numerieke eigenaarschap behouden wanneer expliciete archiefopties worden gebruikt, terwijl een andere tool elk doelbestand kan aanmaken als de account die de kopie uitvoert. Een recent probleem bij containermigratie laat zien hoe gekopieerde app-gegevens onleesbaar kunnen worden wanneer de UID van de bestemming verschilt van de runtime-identiteit van de applicatie.
Herhaal de bewerking met één kleine testmap en inspecteer het eigenaarschap onmiddellijk voordat de applicatie start. Als de nummers al verkeerd zijn, corrigeer dan de kopieermethode of herstelopties. Als ze pas na het opstarten veranderen, laat de kopie dan ongemoeid en onderzoek het container-entrypoint.
Stem de runtimegebruiker van de container af op de eigenaar van de hostopslag
Inspecteer de effectieve gebruiker in de actieve container en de numerieke eigenaar van de aan de app gekoppelde map. Controleer ook Compose user:, aanvullende groepen, platformspecifieke PUID/PGID-variabelen en accountspecifieke afbeeldingsinstellingen.
Een container die als niet-rootgebruiker draait, krijgt niet automatisch toegang tot een hostmap die eigendom is van een andere numerieke identiteit. Een geval op het Docker-forum lost deze grens op door de containergebruiker en hostrechten op elkaar af te stemmen in plaats van de map voor iedereen schrijfbaar te maken.
Kies één stabiel eigenaarschapsmodel voor de applicatie en leg dit vast in Compose. Voeg alleen de groepen toe die nodig zijn voor gedeelde toegang. Vermijd chmod 777, omdat dit de identiteitsmismatch verbergt, de scheiding verzwakt en de bedoelde eigenaar voor toekomstige bestanden niet behoudt.
Controleer of het entrypoint het eigenaarschap bij het opstarten wijzigt
Veel images starten kortstondig als root, maken ontbrekende mappen aan, passen een geconfigureerde UID/GID toe en wijzigen het eigenaarschap recursief voordat ze de privileges verlagen. Daardoor kan een correcte kopie na de eerste containerstart lijken alsof die vanzelf is gewijzigd.
Container-runtimes en images kunnen ook mountgedrag bieden dat het eigenaarschap wijzigt. Een Podman-probleem vermeldt dat de optie :U het bron-eigenaarschap kan herschrijven, terwijl entrypoint-scripts tijdens het opstarten van de applicatie een vergelijkbare recursieve wijziging kunnen uitvoeren.
Start de container eenmaal met zichtbare logs en houd een kleine testsubstructuur in de gaten. Zoek in het entrypoint en de releaseopmerkingen van de image naar chown, gebruikersmigratie, PUID/PGID en stappen voor het herstellen van rechten. Schakel dit gedrag alleen uit of beperk het wanneer de image een stabiel alternatief ondersteunt.
Houd rekening met rootless Docker, gebruikersnaamruimten en netwerkbestandssystemen
Rootless Docker en mapping van gebruikersnaamruimten vertalen container-ID's naar een ander bereik op de host. NFS-, CIFS- en sommige NAS-mountopties kunnen root bovendien afzonderlijk onderdrukken of alle bestanden aan een geconfigureerde UID en GID toewijzen.
Een rapport over rechten bij rootless Docker laat zien dat bestanden onverwacht eigenaarschap kunnen krijgen omdat de containeridentiteit via een onderliggend hostbereik wordt toegewezen. De diagnostische aanwijzing is mapping van eigenaarschap via gebruikersnaamruimten, niet een conventionele kopieerfout.
Controleer of het gegevenspad lokaal is of gebruikmaakt van NFS, CIFS, FUSE of een ander gekoppeld bestandssysteem en noteer het UID/GID-, root-squash- en ACL-gedrag. Test het aanmaken van eigenaarschap afzonderlijk vanaf de host en vanuit de container. Voer geen recursieve chown uit op een netwerkshare voordat het identiteitsbeleid aan de serverzijde duidelijk is.
Herstel het eigenaarschap vanuit een bekende applicatie-identiteit
Stop de applicatie, maak een back-up van de huidige metadata en definieer de exacte UID, GID, mapmodi, bestandsmodi, ACL's en beveiligingslabels die de image verwacht. Corrigeer alleen de paden waarvan de applicatie eigenaar is en sluit gedeelde media of niet-gerelateerde datasets uit.
De ZimaSpace-handleiding voor het onderscheiden van rechtenproblemen en alleen-lezen-mounts is de volgende controle wanneer correct eigenaarschap schrijven nog steeds niet toestaat.
Start de container opnieuw en maak, wijzig en verwijder één testbestand als de echte servicegebruiker. Maak de container vervolgens opnieuw aan en herhaal de test. Het herstel is pas voltooid wanneer het eigenaarschap stabiel blijft na kopiëren, opstarten, opnieuw opstarten en het opnieuw aanmaken van de container, en de applicatie kan lezen en schrijven zonder brede uitzonderingen voor rechten.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Waarom herstelt een Docker-volume de bestandsinhoud, maar gaan uitgebreide bestandskenmerken verloren?
Een diagnose van volumeterugzetting met een inventaris van xattrs, tar- en Rsync-opties, naamruimten, ondersteuning voor bestemmingen, machtigingen, labels, app-metagegevens en tests.
Waarom behoudt een actieve container zijn oude geheugenlimiet nadat het Compose-bestand is gewijzigd?
Een diagnose van geheugenlimieten met aandacht voor actieve cgroups, herstarten versus opnieuw aanmaken, Compose-velden, harde en zachte limieten, bovenliggende scopes, swap en runtime-heaps.
Waarom maakt het herstarten van een reverse proxy elke sessie voor één zelfgehoste app ongeldig?
Een diagnose van sessieverlies met aandacht voor de reikwijdte van herstarts, cookie-eigenaarschap, geheimenrotatie, cachegestuurde sessies, sticky routing, authenticatiegateways en herstel.
