Come risolvere un bind mount Docker che diventa improvvisamente di sola lettura
Un bind mount di Docker diventa di sola lettura quando Docker riceve un percorso di sola lettura o il filesystem dell’host smette di accettare scritture.
Poiché un bind mount espone direttamente un percorso dell’host all’interno del container, il container non può riparare autonomamente un disco, un filesystem, un’opzione di mount o una policy di sicurezza sottostante. Il ripristino più sicuro consiste nel interrompere le scritture, confrontare il mount del container con quello dell’host, determinare se il comportamento di sola lettura è stato configurato o attivato da un errore e ripristinare l’integrità dello storage prima di riavviare l’applicazione.
Conferma quale percorso è di sola lettura
Prova una scrittura innocua all’interno del container, nella destinazione del bind, e un’altra scrittura sull’host, nel percorso di origine. Registra l’errore esatto invece di presumere che ogni errore di autorizzazione indichi un filesystem di sola lettura.
Un caso discusso sul forum Docker mostra che un bind padre di sola lettura può impedire a Docker di creare un punto di mount annidato, perché la directory richiesta non può essere creata nel filesystem padre di sola lettura.
Se l’host può scrivere ma il container no, controlla le opzioni di mount di Docker e i controlli di sicurezza. Se entrambi falliscono con un errore relativo a un filesystem di sola lettura, smetti di modificare gli utenti del container e sposta la diagnosi sul mount dell’host e sul dispositivo di storage.
Controlla i flag effettivi del mount Docker
Controlla la configurazione del container in esecuzione invece di limitarti all’attuale file Compose. Verifica l’origine, la destinazione, la modalità di propagazione e se il mount è contrassegnato come di sola lettura tramite :ro, la sintassi estesa, un file di override o uno strumento di distribuzione.
Un problema segnalato dal client Docker documenta casi in cui i percorsi montati apparivano di sola lettura perché la configurazione del runtime differiva da quella prevista in modalità di lettura e scrittura. L’elemento importante è la modalità effettiva del mount associata al container in esecuzione.
Se il mount è intenzionalmente di sola lettura, rimuovi quel flag solo quando l’applicazione ha realmente bisogno di scrivere. Ricrea il container dopo aver modificato la dichiarazione, perché la modifica di un file Compose non cambia retroattivamente un mount esistente.
Determina se l’host ha rimontato il filesystem in sola lettura
Controlla la tabella dei mount dell’host, il log del kernel, il log dello storage e lo stato del filesystem alla ricerca di errori di I/O, problemi del journal, errori di checksum, reset del dispositivo o un rimontaggio protettivo. Non forzare un rimontaggio in modalità di lettura e scrittura prima di aver compreso il motivo per cui è stata attivata la protezione.
Un caso dell’assistenza Unraid descrive il mancato funzionamento dell’appdata di Docker dopo che un filesystem è diventato di sola lettura, inclusi errori durante la creazione delle directory di Plex. Questo schema indica un problema del filesystem dell’host piuttosto che un’impostazione dei permessi del container.
Arresta i container interessati e conserva i dati diagnostici. Ripara il disco, il pool, il cavo, il filesystem o il journal tramite il flusso di manutenzione supportato dalla piattaforma, quindi verifica che il percorso dell’host sia integro prima di consentire nuovamente la scrittura ai container di database o multimediali.
Controlla i mount annidati e sovrapposti
Elenca ogni bind mount e volume denominato la cui destinazione si trova all’interno di un’altra directory montata. I mount sovrapposti possono nascondere directory, ereditare comportamenti di accesso imprevisti o richiedere a Docker di creare un punto di mount sotto un elemento padre di sola lettura.
Una discussione su Server Fault spiega che la sovrapposizione di un mount in lettura e scrittura e di un mount più ampio di sola lettura su percorsi correlati del container può produrre risultati confusi. Poiché questo argomento è già utilizzato altrove in questo batch, la regola pratica è mappare l’intero albero delle destinazioni prima di modificare i permessi.
Crea le directory host necessarie prima di avviare il container, evita di montare un elemento figlio scrivibile sotto un elemento padre di sola lettura quando il runtime deve crearlo e mantieni espliciti i percorsi persistenti in Compose. Ricrea il container dopo aver semplificato l’albero dei mount.
Distingui lo stato di sola lettura dai permessi e dalla policy di sicurezza
Confronta l’errore del test di scrittura con il proprietario della directory di origine, la modalità, gli ACL, l’etichetta SELinux, il profilo AppArmor e l’ID utente del container. Un errore di accesso negato e un filesystem di sola lettura sono problemi diversi e richiedono riparazioni diverse.
Una guida alla risoluzione dei problemi dello storage suddivide gli incidenti relativi ai volumi di sola lettura in flag di mount, errori del filesystem, contesti di sicurezza e problemi del driver di storage. Questa classificazione aiuta a evitare un uso indiscriminato di chmod 777 in risposta a uno stato di sola lettura a livello di storage.
Se i permessi sono errati, correggi la proprietà o gli ACL sull’host usando l’UID e il GID previsti dal container. Se il filesystem è di per sé in sola lettura, le modifiche ai permessi falliranno e non devono essere usate come sostituto della riparazione del filesystem.
Riavvia l’applicazione solo dopo aver superato un test di scrittura sull’host
Scrivi, sincronizza, leggi ed elimina un file temporaneo nel percorso dell’host, quindi ripeti il test tramite un container temporaneo che utilizzi la stessa dichiarazione di mount e lo stesso utente. Verifica che il filesystem previsto rimanga montato dopo un riavvio.
La guida di ZimaSpace per individuare la dipendenza che causa il riavvio continuo di un container è il controllo successivo se l’applicazione continua a entrare in un ciclo dopo che lo storage è tornato scrivibile.
La riparazione è completa solo quando il filesystem dell’host è integro, il mount Docker effettivo è progettato per la lettura e scrittura, l’applicazione può aggiornare i propri file persistenti e non compaiono nuovi errori di I/O o del filesystem durante l’uso prolungato.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
