Så låser du behållarens UID/GID och volymens ägarskap före uppdateringar av egenhostade appar
Uppdateringar av självhostade appar löper mindre risk att skapa filer som ägs av root när distributionen låser ett numeriskt användarkontrakt och validerar volymägarskap innan containern ersätts.
Den förebyggande åtgärden är att sluta behandla bildens interna användarnamn som en stabil lagringsidentitet. Registrera det effektiva UID och GID som skriver beständiga data, koppla dem till värddatorns kataloger eller namngivna volymer, bevara eventuella PUID/PGID- eller användarnamnområdesinställningar och testa den nya avbildningen mot en liten skrivbar sökväg före full utrullning. På så sätt kan en bilduppdatering inte i tysthet ändra den numeriska ägaren för konfiguration, uppladdningar, databaser eller mediametadata.
Registrera numeriskt UID och GID före uppdatering
Dokumentera den körande processens användare, primära grupp, kompletterande grupper och numeriska ägarskap för representativa filer i varje skrivbar monteringspunkt. Spara avbildningens digest eller version tillsammans med denna ägarskapsbaslinje.
Dockers vägledning för avbildningsbyggen säger att explicita ID:n förhindrar avvikelser mellan ombyggnader, eftersom automatiskt tilldelade avbildningsanvändare kan få olika numeriska ID:n vid olika ombyggnader.
Registrera nummer, inte bara namn som app eller media. En ny avbildning kan återanvända samma användarnamn men ändra dess UID, och filer på värddatorn lagrar numeriskt ägarskap.
Lås körningsanvändaren i distributionskontraktet
När avbildningen stöder direkt körning som ett icke-rootkonto anger du den avsedda användaren och gruppen uttryckligen i Compose eller körningskonfigurationen. Om avbildningen kräver en initieringsfas med root ska du dokumentera vilken efterföljande process som faktiskt skriver beständiga data.
Open Container-avbildningsspecifikationen definierar User som standard för körningen, vilket innebär att en ändrad avbildning kan ändra körningsidentiteten om distributionen inte avsiktligt åsidosätter eller validerar den.
Tvinga inte fram ett godtyckligt icke-root-UID på avbildningar som kräver en stödd initieringsmodell. Kontraktet ska följa applikationens dokumenterade utformning och samtidigt göra ägaren till beständiga filer förutsägbar.
Håll PUID och PGID i linje med ägarskapet på värddatorn
För avbildningar som exponerar variablerna PUID och PGID ska du låsa dessa värden i versionshanterad Compose- eller miljökonfiguration och se till att volymkatalogerna på värddatorn ägs av motsvarande tjänstekonto.
LinuxServer förklarar att PUID kopplar containerns skrivningar så att filer som skapas i mappade volymer förblir hanterbara utanför containern.
Före uppdateringen jämför du de konfigurerade ID:na med id på värddatorn och med befintligt filägarskap. Kopiera inte blint ett exempelvärde som 1000 till en server där det ID:t tillhör en annan person eller tjänst.
Ta hänsyn till användarnamnområden och rootless-mappning
Rootless Docker eller Podman kan få en process att se ut som root inne i containern samtidigt som den mappas till ett icke-root-UID på värddatorn. Registrera namnområdesläget och konfigurationen för underordnade UID/GID innan du tolkar ägarskapsförändringar.
Podmans körningsalternativ visar att keep-id bevarar användarmappningen när en container behöver förutsägbar åtkomst till monterade filer på värddatorn.
Försök inte ”åtgärda” en ägare som ser ut som root inne i containern innan du har kontrollerat det numeriska ID:t på värddatorn. Root i ett namnområde och root på värddatorn är inte alltid samma identitet.
Förtesta den nya avbildningen mot en testvolym
Innan produktionscontainern ersätts kör du den nya avbildningen med avsett UID/GID och en tillfällig katalog som motsvarar produktionens behörigheter. Låt initieringen vid uppstart skapa en fil och en katalog och kontrollera sedan deras ägarskap på värddatorn.
Red Hats felsökningsguide för rootless-volymer visar att ägarskapet på värddatorn följer UID-mappningen och att användarnamnet som visas inne i containern inte ensamt är tillräckliga bevis.
Om kanariet skapar oväntade filer som ägs av root eller ommappade filer ska du stoppa utrullningen och jämföra avbildningens användare, startkommando, namnområde och monteringsinställningar. Det är mycket säkrare än att upptäcka förändringen efter att en rekursiv migrering vid uppstart har påverkat ett helt foto- eller databasträd.
Verifiera kompletterande grupper och skrivbara sökvägar
Vissa appar behöver ett primärt tjänste-UID samt åtkomst via en gemensam grupp för media, nedladdningar eller enheter. Registrera dessa grupp-ID:n och testa alla skrivbara sökvägar, inte bara konfigurationskatalogen.
Kubernetes använder explicita kontrollerna runAsUser och runAsGroup, vilket illustrerar samma Linux-princip för ägarskap även utanför en enkel Docker Compose-distribution.
Uppdateringspolicyn är komplett när den nya avbildningen skapar filer med förväntat ägarskap på värddatorn i alla beständiga sökvägar och klarar att containern återskapas en gång. Den relaterade ZimaSpace-artikeln om filer som ägs av root efter avbildningsuppdateringar är återställningsalternativet om en utrullning redan har skapat data som ägs av root.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
