Een Docker-bindmount oplossen die plotseling alleen-lezen wordt

Een Docker-bindkoppeling wordt alleen-lezen wanneer Docker een alleen-lezen pad ontvangt of het hostbestandssysteem geen schrijfbewerkingen meer accepteert.

Omdat een bindkoppeling een hostpad rechtstreeks beschikbaar maakt in de container, kan de container onderliggende problemen met een schijf, bestandssysteem, mountoptie of beveiligingsbeleid niet zelfstandig herstellen. De veiligste herstelprocedure is om schrijfbewerkingen te stoppen, de containermount te vergelijken met de hostmount, vast te stellen of het alleen-lezen gedrag is geconfigureerd of door een fout is geactiveerd, en de opslaggezondheid te herstellen voordat de applicatie opnieuw wordt gestart.

Controleer welk pad alleen-lezen is

Test een onschadelijke schrijfbewerking in de container op de bestemming van de bindkoppeling en voer nog een schrijfbewerking uit op de host op het bronpad. Noteer de exacte foutmelding in plaats van ervan uit te gaan dat elke machtigingsfout betekent dat het bestandssysteem alleen-lezen is.

Een geval op het Docker-forum laat zien dat een alleen-lezen bovenliggende bindkoppeling kan voorkomen dat Docker een genest mountpunt aanmaakt, omdat de vereiste map niet kan worden aangemaakt op het alleen-lezen bovenliggende bestandssysteem.

Als de host wel kan schrijven maar de container niet, controleer dan de Docker-mountopties en beveiligingscontroles. Als beide mislukken met een foutmelding dat het bestandssysteem alleen-lezen is, stop dan met het wijzigen van containergebruikers en verplaats de diagnose naar de hostmount en het opslagapparaat.

Controleer de effectieve Docker-mountopties

Inspecteer de configuratie van de actieve container in plaats van alleen het huidige Compose-bestand. Controleer de bron, bestemming, propagatiemodus en of de mount als alleen-lezen is gemarkeerd via :ro, de lange syntaxis, een overridebestand of een implementatietool.

Een probleem in de Docker-client documenteert gevallen waarin gemounte paden alleen-lezen leken omdat de runtimeconfiguratie afweek van de bedoelde lees-schrijfconfiguratie. Het belangrijkste bewijs is de effectieve mountmodus die aan de actieve container is gekoppeld.

Als de mount bewust alleen-lezen is, verwijder die vlag dan alleen wanneer de applicatie daadwerkelijk schrijfbewerkingen nodig heeft. Maak de container opnieuw aan nadat je de declaratie hebt gewijzigd, want het bewerken van een Compose-bestand verandert een bestaande mount niet met terugwerkende kracht.

Bepaal of de host het bestandssysteem opnieuw als alleen-lezen heeft gemount

Controleer de mounttabel van de host, het kernel­logboek, het opslaglogboek en de status van het bestandssysteem op I/O-fouten, journalingfouten, checksumfouten, apparaatresets of een beschermende remount. Forceer geen remount als lees-schrijf voordat je begrijpt waarom de beveiliging is geactiveerd.

Een Unraid-supportgeval beschrijft hoe Docker-appdata niet meer werkte nadat een bestandssysteem alleen-lezen was geworden, inclusief fouten bij het aanmaken van Plex-mappen. Dat patroon wijst op een fout in het hostbestandssysteem en niet op een machtigingsinstelling van de container.

Stop de getroffen containers en bewaar de diagnostische gegevens. Herstel de schijf, pool, kabel, het bestandssysteem of het journaal via de ondersteunde onderhoudsprocedure van het platform en controleer vervolgens of het hostpad gezond is voordat database- of mediacontainers weer schrijfbewerkingen mogen uitvoeren.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer geneste en overlappende mounts

Toon elke bindkoppeling en elk benoemd volume waarvan de bestemming zich binnen een andere gemounte map bevindt. Overlappende mounts kunnen mappen verbergen, onverwacht toegangs gedrag overnemen of vereisen dat Docker een mountpunt onder een alleen-lezen bovenliggende map aanmaakt.

Een bespreking op Server Fault legt uit dat het over elkaar heen leggen van een lees-schrijfmount en een bredere alleen-lezen mount op gerelateerde containerpaden verwarrende resultaten kan opleveren. Omdat dat onderwerp elders in deze batch al wordt gebruikt, is de praktische regel hier om de volledige bestemmingsstructuur in kaart te brengen voordat je machtigingen wijzigt.

Maak vereiste hostmappen aan voordat je de container start, vermijd een beschrijfbaar kind onder een alleen-lezen bovenliggende map wanneer de runtime dit zelf moet aanmaken en houd persistente paden expliciet in Compose. Maak de container opnieuw aan nadat je de mountstructuur hebt vereenvoudigd.

Maak onderscheid tussen alleen-lezen en machtigingen of beveiligingsbeleid

Vergelijk de foutmelding van een schrijftest met de eigenaar, modus, ACL, SELinux-label, het AppArmor-profiel en de containergebruikers-ID van de bronmap. ‘Permission denied’ en ‘read-only filesystem’ zijn verschillende fouten en vereisen verschillende oplossingen.

Een handleiding voor het oplossen van opslagproblemen deelt incidenten met alleen-lezen volumes in op basis van mountopties, bestandssysteemfouten, beveiligingscontexten en problemen met opslagstuurprogramma’s. Die classificatie helpt een blinde reactie met chmod 777 op een alleen-lezen status op de opslaglaag te voorkomen.

Als de machtigingen onjuist zijn, corrigeer dan het eigendom of de ACL’s op de host met de bedoelde UID en GID van de container. Als het bestandssysteem zelf alleen-lezen is, zullen wijzigingen aan machtigingen mislukken en mogen ze niet worden gebruikt als vervanging voor herstel van het bestandssysteem.

Start de applicatie pas opnieuw nadat een schrijftest op de host is geslaagd

Schrijf, synchroniseer, lees en verwijder een tijdelijk bestand op het hostpad en herhaal dit vervolgens via een kortstondige testcontainer met dezelfde mountdeclaratie en gebruiker. Controleer of het verwachte bestandssysteem na een herstart gemount blijft.

De ZimaSpace-handleiding voor het vinden van een containerafhankelijkheid die een herstartlus veroorzaakt is de volgende controle als de applicatie in een lus blijft herstarten nadat de opslag weer beschrijfbaar is.

Het herstel is pas voltooid wanneer het hostbestandssysteem gezond is, de effectieve Docker-mount bewust lees-schrijf is ingesteld, de applicatie de persistente bestanden kan bijwerken en er bij langdurig gebruik geen nieuwe I/O- of bestandssysteemfouten optreden.