Comment résoudre le problème d’un montage lié Docker qui devient soudainement accessible en lecture seule
Un montage bind Docker devient accessible en lecture seule lorsque Docker reçoit un chemin en lecture seule ou que le système de fichiers de l’hôte n’accepte plus les écritures.
Comme un montage bind expose directement un chemin de l’hôte dans le conteneur, le conteneur ne peut pas réparer seul un disque, un système de fichiers, une option de montage ou une règle de sécurité sous-jacente. La récupération la plus sûre consiste à arrêter les écritures, à comparer le montage du conteneur avec celui de l’hôte, à déterminer si le comportement en lecture seule a été configuré ou déclenché par une erreur, puis à rétablir la santé du stockage avant de redémarrer l’application.
Confirmer quel chemin est en lecture seule
Testez une écriture sans danger dans le conteneur, à la destination du montage bind, puis une autre écriture sur l’hôte, dans le chemin source. Notez l’erreur exacte au lieu de supposer que chaque échec de permission signifie que le système de fichiers est en lecture seule.
Un cas présenté sur le forum Docker montre qu’un montage parent en lecture seule peut empêcher Docker de créer un point de montage imbriqué, car le répertoire requis ne peut pas être créé sur le système de fichiers parent en lecture seule.
Si l’hôte peut écrire mais pas le conteneur, examinez les options de montage Docker et les contrôles de sécurité. Si les deux échouent avec une erreur indiquant que le système de fichiers est en lecture seule, cessez de modifier les utilisateurs du conteneur et poursuivez le diagnostic au niveau du montage de l’hôte et du périphérique de stockage.
Vérifier les options de montage Docker réellement appliquées
Examinez la configuration du conteneur en cours d’exécution plutôt que le seul fichier Compose actuel. Confirmez la source, la destination, le mode de propagation et le fait que le montage soit ou non marqué en lecture seule via :ro, la syntaxe longue, un fichier de surcharge ou un outil de déploiement.
Un problème signalé par un client Docker documente des cas où des chemins montés semblaient être en lecture seule parce que la configuration d’exécution différait de la configuration prévue en lecture-écriture. L’élément essentiel est le mode de montage réellement appliqué au conteneur en cours d’exécution.
Si le montage est intentionnellement en lecture seule, supprimez cette option uniquement lorsque l’application a réellement besoin d’écrire. Recréez le conteneur après avoir modifié la déclaration, car la modification d’un fichier Compose ne change pas rétroactivement un montage existant.
Déterminer si l’hôte a remonté le système de fichiers en lecture seule
Vérifiez la table des montages de l’hôte, le journal du noyau, le journal du stockage et l’état du système de fichiers à la recherche d’erreurs d’E/S, d’échecs du journal, d’erreurs de somme de contrôle, de réinitialisations du périphérique ou d’un remontage préventif. Ne forcez pas un remontage en lecture-écriture avant d’avoir compris pourquoi la protection s’est activée.
Un cas d’assistance Unraid décrit l’échec de l’appdata Docker après le passage d’un système de fichiers en lecture seule, notamment avec des erreurs lors de la création de répertoires Plex. Ce comportement indique un problème du système de fichiers de l’hôte plutôt qu’un réglage de permissions du conteneur.
Arrêtez les conteneurs concernés et conservez les données de diagnostic. Réparez le disque, le pool, le câble, le système de fichiers ou le journal via le processus de maintenance pris en charge par la plateforme, puis vérifiez que le chemin de l’hôte est sain avant d’autoriser à nouveau les conteneurs de bases de données ou de médias à écrire.
Examiner les montages imbriqués et superposés
Répertoriez chaque montage bind et chaque volume nommé dont la destination se trouve à l’intérieur d’un autre répertoire monté. Les montages qui se chevauchent peuvent masquer des répertoires, hériter de comportements d’accès inattendus ou obliger Docker à créer un point de montage sous un parent en lecture seule.
Une discussion sur Server Fault explique que la superposition d’un montage en lecture-écriture et d’un montage plus large en lecture seule à des chemins de conteneur associés peut produire des résultats déroutants. Comme ce domaine est déjà utilisé ailleurs dans ce lot, la règle pratique consiste ici à cartographier l’arborescence complète des destinations avant de modifier les permissions.
Créez les répertoires requis sur l’hôte avant de démarrer le conteneur, évitez de monter un enfant accessible en écriture sous un parent en lecture seule lorsque l’environnement d’exécution doit le créer, et indiquez explicitement les chemins persistants dans Compose. Recréez le conteneur après avoir simplifié l’arborescence des montages.
Distinguer l’état en lecture seule des permissions et des règles de sécurité
Comparez l’erreur du test d’écriture avec le propriétaire, le mode, les ACL, l’étiquette SELinux, le profil AppArmor et l’identifiant utilisateur du conteneur du répertoire source. « Permission refusée » et « système de fichiers en lecture seule » sont deux erreurs différentes qui nécessitent des réparations différentes.
Un guide de dépannage du stockage regroupe les incidents de volumes en lecture seule en quatre catégories : options de montage, erreurs du système de fichiers, contextes de sécurité et problèmes de pilote de stockage. Cette classification permet d’éviter une réponse automatique du type chmod 777 face à un état en lecture seule au niveau du stockage.
Si les permissions sont incorrectes, corrigez le propriétaire ou les ACL sur l’hôte en utilisant l’UID et le GID prévus pour le conteneur. Si le système de fichiers lui-même est en lecture seule, les modifications de permissions échoueront et ne doivent pas servir de substitut à une réparation du système de fichiers.
Redémarrer l’application uniquement après la réussite d’un test d’écriture sur l’hôte
Écrivez, synchronisez, lisez et supprimez un fichier temporaire dans le chemin de l’hôte, puis répétez l’opération avec un conteneur de test éphémère utilisant la même déclaration de montage et le même utilisateur. Vérifiez que le système de fichiers attendu reste monté après un redémarrage.
Le guide ZimaSpace consacré à la recherche d’une dépendance responsable du redémarrage d’un conteneur constitue la prochaine vérification si l’application continue de redémarrer en boucle après que le stockage est redevenu accessible en écriture.
La réparation est terminée uniquement lorsque le système de fichiers de l’hôte est sain, que le montage Docker réellement appliqué est conçu pour être accessible en lecture-écriture, que l’application peut mettre à jour ses fichiers persistants et qu’aucune nouvelle erreur d’E/S ou du système de fichiers n’apparaît lors d’une utilisation prolongée.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
