Un système de fichiers passé en lecture seule

Toutes les écritures échouent : le système de fichiers est passé en lecture seule. Les applications ne peuvent plus écrire leurs logs, la base de données refuse les transactions, et parfois le serveur reste joignable en SSH, ce qui rend le diagnostic d'autant plus déroutant. La question à trancher en premier n'est pas « comment remonter en écriture », mais est-ce voulu ou est-ce subi. Les deux situations n'ont ni la même cause, ni la même réparation, et le message d'erreur les distingue.

Ce que vous allez apprendre

• Distinguer un montage en lecture seule volontaire d'un remount-ro subi après une erreur disque, grâce au message exact
• Lire les erreurs ext4 dans le journal du noyau, la seule source fiable
• Comprendre pourquoi findmnt et tune2fs peuvent vous mentir
• Réparer avec fsck et prouver que l'écriture est revenue

Le message d'erreur désigne la cause

Deux échecs d'écriture, deux messages distincts. Cette distinction est le cœur du diagnostic, et beaucoup d'administrateurs la manquent :

touch /mnt/data/essai

Message obtenu	Code	Ce que ça veut dire
Read-only file system	EROFS	Le montage est en lecture seule volontairement : option ro dans /etc/fstab ou au montage
Input/output error	EIO	Le périphérique a lâché. Le système de fichiers s'est protégé tout seul

Glissez pour voir

« Read-only file system » est une décision. « Input/output error » est un accident. Le premier se corrige en changeant une option de montage. Le second signale une erreur matérielle ou de périphérique, et remonter en écriture sans rien faire d'autre ne ferait que masquer un problème qui reviendra, avec de la corruption de données à la clé.

Cas 1 : la lecture seule est voulue

C'est le cas simple. Le montage porte l'option ro, et il l'assume :

touch /mnt/data/interdit
findmnt -o TARGET,OPTIONS /mnt/data

touch: cannot touch '/mnt/data/interdit': Read-only file system
/mnt/data ro,relatime

Le message dit Read-only file system, et findmnt confirme en affichant ro. Tout est cohérent. Cherchez l'option ro dans /etc/fstab, corrigez-la, puis remontez :

mount -o remount,rw /mnt/data
findmnt -o TARGET,OPTIONS /mnt/data

Si le montage refuse de repasser en écriture alors que fstab est correct, vous n'êtes pas dans ce cas : passez au suivant.

Cas 2 : la lecture seule est subie, et vos outils vous mentent

Ici, personne n'a demandé la lecture seule. Le noyau l'a imposée parce que le périphérique a renvoyé des erreurs. C'est le comportement par défaut d'ext4 sur Debian, Ubuntu et RHEL, réglé par l'option errors=remount-ro :

tune2fs -l /dev/sdb1 | grep -i 'errors behavior'

Errors behavior:          Remount read-only

Ce réglage est une protection, pas une panne. Face à une erreur d'écriture, le système de fichiers a le choix entre continuer (et corrompre les données), paniquer (et arrêter la machine), ou se figer en lecture seule. La troisième option préserve ce qui peut l'être et vous laisse la main. C'est celle qui est active par défaut.

Le piège : rien de ce que vous regardez ne montre la panne

Voici l'état réel d'un serveur dont le disque vient de lâcher :

touch /mnt/data/nouveau
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/data
tune2fs -l /dev/sdb1 | grep -i 'filesystem state'

touch: cannot touch '/mnt/data/nouveau': Input/output error
TARGET    SOURCE                    FSTYPE OPTIONS
/mnt/data /dev/mapper/disque_flakey ext4   rw,relatime
Filesystem state:         clean

Lisez bien ces trois sorties. Les écritures échouent. Et pourtant :

• findmnt affiche rw. Le montage se dit toujours en écriture. Les options affichées dans /proc/mounts n'ont pas été mises à jour par le passage en lecture seule interne du noyau.
• tune2fs affiche clean. L'état du système de fichiers est lu sur le disque, or le noyau n'a pas pu écrire le superbloc pour le marquer en erreur, précisément parce que le disque ne répond plus. L'outil rapporte donc un état périmé.

Ne concluez jamais sur findmnt seul

Un findmnt qui affiche rw pendant que les écritures échouent n'est pas un bug : c'est la conséquence d'une panne qui est survenue après le montage. Si vous vous fiez à cette sortie, vous chercherez le problème dans l'application pendant que le disque agonise sous vos pieds.

La seule source qui dit la vérité : le journal du noyau

journalctl -k | tail -20
# ou, hors systemd :
dmesg | grep -iE 'EXT4-fs|I/O error'

EXT4-fs error (device dm-1): ext4_journal_check_start:84: Detected aborted journal
EXT4-fs (dm-1): I/O error while writing superblock
EXT4-fs (dm-1): Remounting filesystem read-only

Trois lignes, tout le diagnostic. Le noyau a rencontré une erreur d'écriture, il n'a même pas pu mettre à jour le superbloc, il a avorté le journal et remonté le système de fichiers en lecture seule. Le terme aborted journal explique aussi pourquoi vous obtenez Input/output error et non Read-only file system : tant que le journal est avorté, toute opération échoue en EIO, même celles qui devraient simplement être refusées.

Cherchez également des lignes Buffer I/O error on dev, qui pointent le périphérique fautif, et remontez la chaîne : si c'est un disque physique, smartctl -H /dev/sdX donnera son état de santé.

Le disque revient, la panne reste

Un point contre-intuitif, et lourd de conséquences. Même quand le périphérique refonctionne parfaitement, le système de fichiers ne revient pas tout seul en écriture :

dd if=/dev/mapper/disque_flakey of=/dev/null bs=4k count=1
touch /mnt/data/apres_hoquet

4096 bytes (4.1 kB, 4.0 KiB) copied, 1.1602e-05 s, 353 MB/s
touch: cannot touch '/mnt/data/apres_hoquet': Input/output error

Le disque lit à 353 Mo/s : il va très bien. L'écriture échoue toujours. Un mount -o remount,rw ne suffit pas dans cet état, car le journal reste avorté. Il faut démonter et réparer.

Réparer

La réparation suit trois temps, dans cet ordre. Traiter d'abord la cause matérielle si elle existe : réparer un système de fichiers sur un disque qui meurt ne fait que retarder l'échéance.

1. Démonter

On ne répare jamais un système de fichiers monté. Si le démontage est refusé parce que des processus tiennent des fichiers ouverts, identifiez-les avec lsof +f -- /mnt/data, arrêtez-les, et n'utilisez umount -l (démontage paresseux) qu'en dernier recours.

umount /mnt/data

Si le système de fichiers concerné est la racine, le démontage est impossible : il faut redémarrer sur un système de secours, ou forcer une vérification au prochain démarrage. Voir Arrêter, redémarrer, récupérer.

2. Vérifier et réparer avec fsck

fsck.ext4 -fy /dev/sdb1 ; echo "exit=$?"

e2fsck 1.47.2 (1-Jan-2025)
/dev/mapper/disque_flakey: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 5: Checking group summary information
Free inodes count wrong (32756, counted=32755).
Fix? yes
***** FILE SYSTEM WAS MODIFIED *****
exit=1

-f force la vérification même si le système de fichiers se croit propre (souvenez-vous qu'il se dit clean), et -y répond oui à toutes les questions.

fsck qui renvoie 1 n'est pas un échec

Le code de sortie 1 signifie « des erreurs ont été corrigées ». C'est le résultat attendu après un incident. Le 0 signifie « rien à corriger ». Ce sont les codes 4 et plus qui indiquent des erreurs non corrigées et qui doivent vous inquiéter.

3. Remonter et prouver que l'écriture est revenue

mount /dev/sdb1 /mnt/data
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/data
echo "reparation" > /mnt/data/verif.txt && echo "ecriture de nouveau possible"

/mnt/data /dev/mapper/disque_flakey ext4   rw,relatime
ecriture de nouveau possible

Constater l'absence d'erreur ne suffit pas : écrivez réellement un fichier. C'est la seule preuve que le service qui tournait sur ce montage pourra fonctionner.

Dépannage

Symptôme	Cause probable	Vérification	Correction
Read-only file system	Montage ro volontaire	findmnt -o OPTIONS affiche ro	Corriger /etc/fstab, mount -o remount,rw
Input/output error	Erreur disque, journal avorté	journalctl -k | grep EXT4-fs	Démonter, fsck -fy, remonter
findmnt dit rw mais rien ne s'écrit	Remount-ro interne après erreur	Le journal du noyau, jamais findmnt	fsck après démontage
tune2fs dit clean alors que tout casse	Superbloc non écrit (disque muet)	journalctl -k	Ne pas se fier à tune2fs en pleine panne
remount,rw ne change rien	Journal avorté	journalctl -k : aborted journal	Démonter et fsck, un remount ne suffit pas
umount refusé (target is busy)	Processus tenant des fichiers ouverts	lsof +f -- /mnt/data	Arrêter les processus, umount -l en dernier recours
La racine / est en lecture seule	Disque système en erreur	Console, journalctl -k	Redémarrer en mode secours

Glissez pour voir

Prévention

Un errors=remount-ro qui se déclenche est un symptôme, pas la maladie. Deux réflexes évitent la récidive. Surveiller la santé des disques avec smartctl et une supervision qui remonte les erreurs d'entrée-sortie : le disque a presque toujours donné des signes avant de lâcher. Et surveiller le journal du noyau : les lignes Buffer I/O error apparaissent souvent des jours avant la panne franche, sans qu'aucune application ne s'en plaigne encore.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Le message d'erreur désigne la cause : Read-only file system (EROFS) est un montage ro voulu, Input/output error (EIO) est une panne subie.
• errors=remount-ro est une protection, pas un bug : ext4 se fige pour éviter de corrompre vos données.
• findmnt peut afficher rw alors que le système de fichiers est bloqué. Les options de montage ne sont pas mises à jour par le passage en lecture seule interne.
• tune2fs peut afficher clean pendant la panne : il lit le superbloc sur un disque qui ne répond plus.
• Le journal du noyau est la seule source fiable : journalctl -k ou dmesg, et cherchez EXT4-fs error, aborted journal, Buffer I/O error.
• Le disque qui refonctionne ne répare pas le montage. Il faut démonter, fsck, remonter.
• fsck qui renvoie 1 a corrigé des erreurs : c'est un succès, pas un échec.
• Prouvez la réparation en écrivant un fichier, ne vous contentez pas d'une absence de message d'erreur.

Pour aller plus loin

• ext4 : le système de fichiers en détail, et l'usage complet de fsck.
• Monter et rendre persistant : les options de /etc/fstab, dont errors et nofail.
• Identifier les disques : retrouver quel périphérique physique est en cause.
• Lire les journaux (journalctl) : filtrer le journal du noyau efficacement.

×

📖 Voir la documentation →