En Docker-bindmontering blir skrivskyddad när Docker får en skrivskyddad sökväg eller när värdfilsystemet slutar ta emot skrivningar.
Eftersom en bindmontering exponerar en sökväg på värden direkt i containern kan containern inte själv reparera en underliggande disk, ett filsystem, en monteringsflagga eller en säkerhetspolicy. Den säkraste återställningen är att stoppa skrivningar, jämföra containerns montering med värdens montering, avgöra om skrivskyddet konfigurerades eller utlöstes av ett fel och återställa lagringens hälsa innan programmet startas om.
Bekräfta vilken sökväg som är skrivskyddad
Testa en ofarlig skrivning i containern vid bindmonteringens målsökväg och ytterligare en skrivning på värden vid källsökvägen. Notera det exakta felet i stället för att anta att alla behörighetsfel innebär att filsystemet är skrivskyddat.
Ett fall på Docker-forumet visar att en skrivskyddad överordnad bindmontering kan hindra Docker från att skapa en kapslad monteringspunkt, eftersom den nödvändiga katalogen inte kan skapas på det skrivskyddade överordnade filsystemet.
Om värden kan skriva men containern inte kan det, granskar du Dockers monteringsalternativ och säkerhetskontroller. Om båda misslyckas med ett fel om skrivskyddat filsystem ska du sluta ändra containeranvändare och flytta felsökningen till värdens montering och lagringsenhet.
Kontrollera de effektiva monteringsflaggorna i Docker
Inspektera konfigurationen för den körande containern i stället för att bara kontrollera den aktuella Compose-filen. Bekräfta källan, målet, spridningsläget och om monteringen är markerad som skrivskyddad genom :ro, lång syntax, en åsidosättningsfil eller ett distributionsverktyg.
Ett klientproblem i Docker dokumenterar fall där monterade sökvägar verkade vara skrivskyddade eftersom körningskonfigurationen skilde sig från den avsedda skrivbara konfigurationen. Det viktiga beviset är det effektiva monteringsläget som är kopplat till den körande containern.
Om monteringen är avsiktligt skrivskyddad tar du bort flaggan endast när programmet verkligen behöver skriva. Skapa containern på nytt efter att deklarationen har ändrats, eftersom en redigering av Compose-filen inte ändrar en befintlig montering retroaktivt.
Ta reda på om värden monterade om filsystemet som skrivskyddat
Kontrollera värdens monteringstabell, kärnlogg, lagringslogg och filsystemets status efter I/O-fel, journalfel, kontrollsummefel, enhetsåterställningar eller en skyddande ommontering. Tvinga inte fram en skrivbar ommontering innan du har förstått varför skyddet aktiverades.
Ett supportfall från Unraid beskriver hur Docker-appdata slutade fungera efter att ett filsystem blivit skrivskyddat, inklusive fel vid skapandet av Plex-kataloger. Det mönstret pekar på ett fel i värdens filsystem snarare än en behörighetsinställning i containern.
Stoppa berörda containrar och bevara diagnostiken. Reparera disken, poolen, kabeln, filsystemet eller journalen via plattformens stödda underhållsprocess och bekräfta sedan att sökvägen på värden är felfri innan databas- eller mediacontainrar tillåts skriva igen.
Inspektera kapslade och överlappande monteringar
Lista alla bindmonteringar och namngivna volymer vars mål ligger inuti en annan monterad katalog. Överlappande monteringar kan dölja kataloger, ärva oväntat åtkomstbeteende eller kräva att Docker skapar en monteringspunkt under en skrivskyddad överordnad katalog.
En diskussion på Server Fault förklarar att en överlagring av en skrivbar montering och en bredare skrivskyddad montering vid relaterade containersökvägar kan ge förvirrande resultat. Eftersom det området redan används på annat håll i denna omgång är den praktiska regeln att kartlägga hela målträdet innan du ändrar behörigheter.
Skapa nödvändiga värdkataloger innan containern startas, undvik att montera ett skrivbart underordnat objekt under en skrivskyddad överordnad katalog när körmiljön måste skapa det och håll beständiga sökvägar uttryckliga i Compose. Skapa containern på nytt efter att monteringsstrukturen har förenklats.
Skilj skrivskyddat läge från behörigheter och säkerhetspolicy
Jämför felet från skrivtestet med källkatalogens ägare, läge, ACL, SELinux-etikett, AppArmor-profil och containerns användar-ID. Nekad åtkomst och skrivskyddat filsystem är olika fel och kräver olika åtgärder.
En guide för felsökning av lagring delar in incidenter med skrivskyddade volymer i monteringsflaggor, filsystemsfel, säkerhetskontexter och problem med lagringsdrivrutinen. Den klassificeringen hjälper till att förhindra ett reflexmässigt chmod 777-svar på ett skrivskyddat tillstånd på lagringsnivå.
Om behörigheterna är felaktiga korrigerar du ägarskap eller ACL:er på värden med det användar-ID och grupp-ID som containern ska använda. Om själva filsystemet är skrivskyddat misslyckas behörighetsändringar och ska inte användas som ersättning för en filsystemsreparation.
Starta om programmet först när ett skrivtest på värden lyckas
Skriv, synkronisera, läs och radera en tillfällig fil på värdens sökväg och upprepa sedan testet genom en kortlivad testcontainer med samma monteringsdeklaration och användare. Bekräfta att det förväntade filsystemet fortfarande är monterat efter en omstart.
ZimaSpaces guide om att hitta ett containerberoende som orsakar en omstartsloop är nästa kontroll om programmet fortsätter att starta om efter att lagringen blivit skrivbar.
Reparationen är klar först när värdens filsystem är friskt, den effektiva Docker-monteringen är skrivbar enligt avsikt, programmet kan uppdatera sina beständiga filer och inga nya I/O- eller filsystemsfel uppstår under kontinuerlig användning.
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.

