Linux sans magie #53 — Filesystem en lecture seule : comprendre et diagnostiquer

Une application fonctionnait normalement puis échoue à écrire : Read-only file system. Le service s'arrête, ses journaux cessent de progresser et un administrateur découvre que le volume est monté en lecture seule. Faut-il lancer immédiatement mount -o remount,rw ? Non : la lecture seule peut être une protection activée après une erreur, et forcer l'écriture sans comprendre l'incident risque d'aggraver la situation.

Après le #52 consacré aux filesystems pleins, ce guide propose un diagnostic sans écriture volontaire sur le volume affecté : localiser le montage, identifier les messages du noyau, distinguer une configuration intentionnelle d'une erreur du support, puis préparer une reprise contrôlée. L'exemple porte sur un filesystem ext4 local ; les vérifications doivent être adaptées à XFS, Btrfs, NFS, volumes cloud ou systèmes conteneurisés.

Comprendre ce que signifie « read-only »

Un filesystem en lecture seule permet généralement de lire des fichiers, mais empêche les opérations qui exigent de modifier ses métadonnées ou son contenu. Le noyau peut renvoyer EROFS, traduit en pratique par Read-only file system. Ce n'est pas le même diagnostic qu'un manque de droits (Permission denied) ni qu'une saturation (No space left on device).

Il existe plusieurs niveaux distincts :

Application → chemin /srv/data/rapport.txt
                 ↓
        Point de montage /srv/data
        options VFS : ro ou rw
                 ↓
        Superblock du filesystem ext4
        état et options du filesystem
                 ↓
        Périphérique bloc /dev/mapper/data
        éventuellement déclaré read-only
                 ↓
        LVM / dm-crypt / RAID / disque physique

Un montage ro peut être volontaire (image, instantané, montage de secours, conteneur restreint) ou consécutif à un incident. De plus, des bind mounts peuvent être en lecture seule alors que le filesystem sous-jacent est accessible en écriture par un autre point de montage. La documentation mount(8) distingue les options VFS et celles du filesystem ; ne les confondez pas.

Pourquoi un filesystem bascule en lecture seule

Pour ext4, une politique d'erreur peut demander errors=remount-ro : lorsqu'une erreur pertinente est détectée, le noyau peut remonter le filesystem en lecture seule pour limiter de nouveaux dommages. D'autres choix existent (errors=continue, errors=panic), mais aucun changement de cette politique ne constitue une réparation.

Les causes possibles incluent :

une incohérence des métadonnées ou un problème de journal ;
des erreurs d'entrée/sortie, des timeouts ou la disparition d'un périphérique ;
un défaut de connexion, contrôleur, stockage réseau ou hyperviseur ;
un montage explicitement configuré avec l'option ro ;
une politique de l'environnement d'exécution, par exemple un bind mount ou un filesystem de conteneur en lecture seule ;
un support ou une couche bloc présentée comme non inscriptible.

Le message « read-only » décrit donc un symptôme, pas sa cause racine. Un simple changement d'option de montage peut masquer la protection sans résoudre les erreurs à l'origine de l'incident.

Première décision : préserver les données et le contexte

Avant d'exécuter une commande de modification, relevez l'heure de la première erreur, le nom du service, le chemin exact qui échoue et les dernières opérations de maintenance. Vérifiez la criticité du volume, son rôle éventuel dans le démarrage et l'existence de sauvegardes récentes dont la restauration a déjà été testée.

Si l'application conserve des données uniquement sur le volume concerné, envisagez une limitation contrôlée des opérations plutôt qu'un enchaînement de redémarrages. Sur un volume potentiellement endommagé, la priorité peut être la préservation des données et des preuves, non le retour immédiat à l'écriture.

Ne faites pas à ce stade de remount en rw, de fsck -y, de e2fsck, de xfs_repair, d'écriture forcée ni de redémarrage improvisé. Le choix d'une réparation dépend du type de filesystem et de sa couche de stockage.

Étape 1 — Identifier précisément le montage

Adaptez le chemin de l'exemple à celui mentionné par l'application :

findmnt --target /srv/data/rapport.txt -o TARGET,SOURCE,FSTYPE,VFS-OPTIONS,FS-OPTIONS
findmnt -o TARGET,SOURCE,FSTYPE,VFS-OPTIONS,FS-OPTIONS
lsblk -o NAME,PATH,FSTYPE,TYPE,RO,MOUNTPOINTS
df -hT /srv/data

findmnt --target recherche le filesystem qui contient le chemin demandé ; si le fichier n'existe pas encore, utilisez un répertoire parent existant, par exemple /srv/data. findmnt distingue les options de montage VFS et du filesystem lorsque la version de l'outil fournit ces colonnes.

La colonne RO de lsblk se rapporte aux périphériques blocs, pas directement au mode de tous les montages. Un RO=0 n'exclut pas un filesystem monté ro, et un chemin sous un bind mount peut montrer un résultat différent d'un autre accès au même filesystem.

df aide à écarter une saturation des blocs, mais un filesystem plein n'est pas automatiquement remonté en lecture seule. Si df indique de l'espace disponible et que l'écriture échoue avec EROFS, poursuivez l'enquête sur l'état du montage et les journaux.

Étape 2 — Lire les messages du noyau au moment de l'incident

Les premières traces pertinentes se trouvent fréquemment dans le journal du noyau. Privilégiez un intervalle correspondant au début du problème :

journalctl -k --since "2 hours ago" --no-pager
journalctl -k -b --no-pager -n 200
dmesg --color=never | tail -n 100

journalctl -k affiche les messages noyau lorsque le journal est disponible. L'option -b limite l'affichage au démarrage actuel. dmesg consulte le tampon de messages noyau, dont l'accès peut nécessiter des privilèges.

Cherchez notamment des mentions d'erreurs ext4, d'abandon de journal, d'I/O error, de timeout, de lien réinitialisé, de périphérique absent ou d'un remount read-only. L'ordre des événements compte : une déconnexion de stockage avant une erreur ext4 oriente le diagnostic vers le chemin d'accès plutôt qu'une corruption uniquement logique.

Ne tirez pas de conclusion définitive du seul mot EXT4-fs ou d'un message isolé. Rapprochez les horodatages de ceux des applications, de l'hyperviseur, du contrôleur et des mécanismes de supervision. Un redémarrage peut avoir effacé une partie du contexte s'il n'existe pas de journaux persistants.

Étape 3 — Vérifier le périphérique et ses couches

Une fois le bon filesystem identifié, cartographiez la pile de stockage sans présumer que /dev/sdX est une identité permanente :

lsblk -f
lsblk -o NAME,PATH,MODEL,SERIAL,WWN,TYPE,RO,SIZE
findmnt --target /srv/data -o SOURCE,TARGET,FSTYPE
ls -l /dev/disk/by-id/

Un volume peut se trouver sur une partition, un LV, un mapping LUKS, un ensemble MD ou un volume de plateforme. Si LVM ou RAID est présent, reportez-vous aux commandes d'observation appropriées, par exemple sudo pvs, sudo lvs et cat /proc/mdstat.

Après identification confirmée de la cible, il est possible de lire le statut read-only du périphérique bloc :

# EXEMPLE : remplacer le placeholder uniquement après identification
sudo blockdev --getro /dev/disk/by-id/<peripherique-identifie>

La sortie 1 indique un périphérique bloc read-only, 0 un périphérique considéré inscriptible à cette couche. Cela ne remplace pas le contrôle de findmnt. N'utilisez pas blockdev --setrw comme correction rapide : modifier un drapeau de bloc peut contourner une protection sans résoudre l'origine du défaut.

Étape 4 — Distinguer panne et lecture seule attendue

La distinction conditionne toute décision. Voici quelques scénarios typiques :

Constat	Hypothèse à vérifier	Vérification prioritaire
`ro` dès le démarrage, sans erreur noyau	Choix de configuration ou montage de secours	`/etc/fstab`, options de montage, procédures de démarrage
`rw` auparavant, puis `ro` avec erreurs ext4	Politique de protection après erreur	Journaux du noyau et état des couches bloc
Bind mount en `ro`, source ailleurs en `rw`	Restriction VFS propre au montage	`findmnt` sur les deux chemins
Périphérique bloc signalé read-only	Politique ou incident à une couche inférieure	`lsblk`, `blockdev --getro`, plateforme de stockage
Messages de timeout ou I/O error	Défaut de support ou de connectivité	Journaux noyau, supervision et contrôleur

Sur les environnements virtualisés, un détachement ou basculement du disque côté hyperviseur peut se manifester par une cascade de messages Linux. Sur du stockage réseau, l'analyse doit suivre les garanties et comportements du protocole utilisé : les procédures ext4 locales ne sont pas transposables telles quelles à NFS.

Le système peut parfois exposer plusieurs espaces de noms de montage. Une application dans un conteneur ne voit pas nécessairement les mêmes options que l'hôte. Comparez le contexte du processus qui échoue avant de modifier le montage sur l'hôte.

Étape 5 — Comprendre pourquoi remount,rw est risqué

La commande souvent suggérée lors d'un incident est :

# NE PAS EXÉCUTER SANS DIAGNOSTIC ET PROCÉDURE APPROUVÉE
sudo mount -o remount,rw /srv/data

Elle demande une modification du mode de montage, sans réparer automatiquement les métadonnées, le journal ou le périphérique sous-jacent. Si des erreurs subsistent, le noyau peut refuser l'opération ou le filesystem peut de nouveau devenir read-only. Une réussite apparente n'établit pas la cohérence des données.

Sur ext4, un montage en lecture seule n'implique pas systématiquement zéro écriture physique : suivant l'état du journal et les options de montage, le noyau peut effectuer une récupération de journal lors du montage. C'est une raison supplémentaire d'utiliser une procédure de préservation appropriée en cas de suspicion de corruption ou d'expertise forensic.

Changer errors=remount-ro en errors=continue pour garder les écritures actives supprime une protection potentielle. Ce n'est pas une réponse standard à un incident et ce guide ne le recommande pas.

Étape 6 — Préparer une éventuelle réparation hors ligne

Si l'investigation pointe vers une incohérence ext4, la préparation doit tenir compte de l'arrêt du service, de la sauvegarde, de la disponibilité de la couche bloc et d'un filesystem non monté pour une réparation réelle.

L'outil e2fsck sert aux filesystems ext2/ext3/ext4, mais sa documentation avertit qu'il n'est généralement pas sûr de le lancer sur un filesystem monté. Même un contrôle utilisant -n sur un filesystem monté peut produire des résultats non fiables. Il n'est pas acceptable de traiter un fsck interactif sur un volume en production comme une simple commande de diagnostic.

La réparation du volume racine nécessite souvent une maintenance hors système actif, par exemple via un environnement de secours ou une procédure de démarrage dédiée. Pour XFS, Btrfs et d'autres types de filesystem, les outils et les exigences diffèrent. L'article #55 détaillera les outils de vérification et leurs risques ; aucune commande de réparation n'est proposée à exécuter ici.

En cas d'erreurs matérielles persistantes, une réparation logique seule peut échouer ou aggraver le problème. L'investigation de la chaîne de stockage et la protection des données doivent précéder tout écrit correctif.

Vérifier une reprise approuvée

Une fois la cause traitée dans le cadre d'une intervention validée, les commandes d'observation suivantes aident à contrôler le résultat :

findmnt --target /srv/data -o TARGET,SOURCE,FSTYPE,VFS-OPTIONS,FS-OPTIONS
lsblk -o NAME,PATH,TYPE,RO,MOUNTPOINTS
journalctl -k --since "30 minutes ago" --no-pager
df -hT /srv/data

Une reprise ne se limite pas à voir rw dans findmnt. Vérifiez aussi l'absence de nouvelles erreurs d'I/O, la présence des volumes attendus, la santé des services et une écriture applicative contrôlée dans un chemin approuvé. Ne créez pas de fichier de test sur un volume suspect avant d'avoir validé la phase de reprise.

Consignez les événements, la cause probable, les éléments encore incertains, la sauvegarde utilisée le cas échéant et les alertes à surveiller. Si les erreurs réapparaissent, cessez les essais répétés et escaladez la récupération.

Bonnes pratiques et sécurité

Surveillez l'état des montages, les erreurs noyau et la santé des chemins de stockage, et corrélez leurs alertes. Une bonne supervision peut signaler les anomalies de blocs avant qu'une application ne constate EROFS.

Documentez la topologie stockage → filesystem → services, les procédures de mise en maintenance et les points de contact. Des sauvegardes indépendantes et régulièrement restaurées sont essentielles : ni le RAID, ni LVM, ni un snapshot local ne remplacent à eux seuls une stratégie de restauration.

Ne changez pas les options de montage par automatisme. Les systèmes immuables, conteneurs ou dispositifs de récupération utilisent parfois volontairement la lecture seule ; la « correction » recherchée peut en réalité contredire une politique de sécurité.

Limites et retour arrière

Les commandes de diagnostic citées n'impliquent pas de modification volontaire des données du volume. Leur exécution peut néanmoins lire intensément des ressources ou dépendre de journaux incomplets. Les méthodes décrites concernent principalement un filesystem local ext4 : sur des systèmes distribués, un simple état ro peut signifier autre chose.

Il n'existe pas de rollback universel après une écriture forcée sur un filesystem endommagé ou une réparation exécutée sur la mauvaise cible. Avant une intervention, définissez critères d'arrêt, plan de restauration, fenêtre d'indisponibilité et validation du propriétaire de l'application. En cas de doute, préserver les données prime sur une tentative de remount.

Références officielles

Conclusion

Un filesystem passé en lecture seule n'est pas un simple problème de permissions. L'ordre sûr est de localiser le montage, lire les messages noyau, vérifier les couches de stockage, distinguer une politique volontaire d'une réaction à une erreur, puis décider d'une reprise contrôlée. Un remount,rw n'est ni un diagnostic ni une réparation.

Dans le #54, nous reviendrons sur un autre incident trompeur : les inodes épuisés, lorsque le disque semble disposer d'espace mais refuse la création de nouveaux fichiers.