Varför ändras ägarna till containerfiler efter att appdata har kopierats?
Ägare av containerfiler ändras efter en kopiering när numeriska UID/GID-värden inte bevaras eller när körmiljön på målet mappar om eller skriver om dem.
I en hem-NAS kan samma fil visas med ett användarnamn på värden och ett annat inuti en container, eftersom ägarskap lagras som tal medan varje miljö slår upp dessa tal via olika kontodatabaser. Kopior som görs via ett grafiskt gränssnitt, en SMB-delning, ett arkiv, ett root-skal, ett migreringsverktyg eller en container-entrypoint kan också ersätta ägarskapet. Diagnostisera den numeriska identiteten först och skilj sedan mellan kopieringsbeteende, användarinställningar i körmiljön, startskript, användarnamnområden och mappning i nätverksfilsystem innan du ändrar behörigheter i hela appdataträdet.
Jämför numeriska UID och GID innan du jämför användarnamn
Inspektera källan och målet med numeriskt ägarskap, inte bara namn. Notera UID, GID, läge, ACL:er, utökade attribut och filsystem för en representativ fil och dess överordnade katalog på både värden och inuti containern.
Docker-bindmonteringar exponerar värdfiler för processer som kan använda en annan användardatabas. En diskussion i Docker-communityt förklarar varför tillförlitlig åtkomst beror på justering av numeriska UID/GID snarare än att enbart matcha användarnamn.
Om talen är identiska men de visade namnen skiljer sig åt kanske ägarskapet inte har ändrats alls. Korrigera dokumentationen eller kontomappningen i stället för att skriva om data rekursivt. Om talen skiljer sig åt ska du bevara informationen och fortsätta med kopierings- och körmiljöstegen.
Ta reda på om kopieringen bevarade eller återskapade ägarskapet
Skriv ned den exakta kopieringsvägen: filhanterare på värden, cp, rsync, tar-arkiv, SMB/NFS-klient, återställning från säkerhetskopia, Docker-kopieringskommando eller tillfällig migreringscontainer. Varje metod har olika standardinställningar för ägare, grupp, ACL:er och utökade attribut.
En kopiering som körs som root kan bevara numeriskt ägarskap när uttryckliga arkivalternativ används, medan ett annat verktyg kan skapa alla målfiler som det konto som utför kopieringen. Ett aktuellt problem vid containermigrering visar hur kopierad appdata kan bli oläsbar när UID:t på målet skiljer sig från programmets identitet i körmiljön.
Upprepa åtgärden med en liten testkatalog och kontrollera ägarskapet direkt innan programmet startar. Om talen redan är fel ska du korrigera kopieringsmetoden eller återställningsflaggorna. Om de ändras först efter starten ska du låta kopian vara och undersöka containerns entrypoint.
Matcha körmiljöns användare mot ägaren av lagringen på värden
Kontrollera den effektiva användaren inuti den körande containern och den numeriska ägaren av den bindmonterade appdatakatalogen. Kontrollera även Compose user:, kompletterande grupper, plattformens PUID/PGID-variabler och eventuella kontoinställningar som är specifika för avbildningen.
Att köra en container som en icke-root-användare ger inte automatiskt åtkomst till en värdkatalog som ägs av en annan numerisk identitet. Ett fall i Docker-forumet löser gränsen genom att matcha containeranvändaren med värdens behörigheter i stället för att göra katalogen skrivbar för alla.
Välj en stabil ägarmodell för programmet och dokumentera den i Compose. Lägg endast till de grupper som krävs för delad åtkomst. Undvik chmod 777, eftersom det döljer identitetsmissmatchen, försvagar avgränsningen och inte bevarar den avsedda ägaren för framtida filer.
Kontrollera om entrypointen ändrar ägarskapet vid start
Många avbildningar startar tillfälligt som root, skapar saknade kataloger, tillämpar ett konfigurerat UID/GID och ändrar ägarskapet rekursivt innan de sänker privilegierna. Det beteendet kan få en korrekt kopia att verka ändras av sig själv efter den första containerstarten.
Körmiljöer och avbildningar kan också erbjuda monteringsbeteenden som ändrar ägarskapet. Ett Podman-problem visar att alternativet :U kan skriva om källans ägarskap, medan entrypoint-skript kan utföra en liknande rekursiv ändring under programstarten.
Starta containern en gång med synliga loggar och övervaka ett litet testunderträd. Sök i entrypointen och avbildningens versionsinformation efter chown, användarmigrering, PUID/PGID och steg som åtgärdar behörigheter. Inaktivera eller begränsa beteendet endast när avbildningen stöder ett stabilt alternativ.
Ta hänsyn till rootless Docker, användarnamnområden och nätverksfilsystem
Rootless Docker och mappning av användarnamnområden översätter container-ID:n till ett annat intervall på värden. NFS, CIFS och vissa monteringsalternativ för NAS kan oberoende av detta ersätta root eller tvinga alla filer till ett konfigurerat UID och GID.
En rapport om Docker-behörigheter visar att filer kan visas med oväntat ägarskap eftersom containeridentiteten mappas via ett underordnat intervall på värden. Det diagnostiska tecknet är mappning av ägarskap via användarnamnområden, inte ett konventionellt kopieringsfel.
Kontrollera om datasökvägen är lokal eller använder NFS, CIFS, FUSE eller ett annat monterat filsystem, och notera dess UID/GID samt beteende för root-squash och ACL:er. Testa skapande av ägarskap separat från värden och containern. Kör inte chown rekursivt på en nätverksdelning innan identitetspolicyn på servern är förstådd.
Åtgärda ägarskapet utifrån en känd programidentitet
Stoppa programmet, säkerhetskopiera de aktuella metadata och definiera exakt vilket UID, GID, katalogläge, filläge, ACL:er och säkerhetsetiketter avbildningen förväntar sig. Korrigera endast de sökvägar som programmet äger och undanta delade medier eller orelaterade dataset.
Guiden från ZimaSpace om att skilja behörighetsfel från skrivskyddade monteringar är nästa kontroll när korrekt ägarskap fortfarande inte tillåter skrivningar.
Starta om containern och skapa, ändra och ta bort en testfil som den riktiga tjänsteanvändaren. Återskapa sedan containern och upprepa testet. Åtgärden är klar först när ägarskapet förblir stabilt efter kopiering, start, omstart och återskapande av containern, och programmet kan läsa och skriva utan breda behörighetsundantag.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
