Monter un système de fichiers et le rendre persistant

Une partition formatée n'est utilisable qu'une fois montée sur un répertoire de l'arborescence ; pour qu'elle revienne après un redémarrage, elle doit figurer dans /etc/fstab. Ce guide montre comment monter avec mount, vérifier avec findmnt, démonter proprement, puis rendre le montage persistant par UUID. Il insiste sur le contrôle avant redémarrage, où mount -a seul ne prouve rien : il faut lui adjoindre findmnt --verify. Pour administrateurs débutants à intermédiaires. Sorties issues d'un test AlmaLinux 10.

Ce que vous allez apprendre

• Monter et démonter un système de fichiers (mount, umount)
• Vérifier un montage avec findmnt
• Écrire une entrée /etc/fstab fiable par UUID
• Contrôler le fichier avant de redémarrer avec mount -a, findmnt --verify et systemctl daemon-reload
• Éviter un démarrage bloqué grâce à nofail

Prérequis

• Une partition formatée (ext4, XFS...) et le bon disque identifié
• Un accès sudo

Monter manuellement une partition

Le point de montage est un répertoire existant où le système de fichiers devient accessible. Créez-le, puis montez :

sudo mkdir -p /mnt/data1
sudo mount /dev/sda1 /mnt/data1

Vérifiez avec findmnt, plus lisible que mount car il ne montre que ce qui vous intéresse :

findmnt /mnt/data1

TARGET     SOURCE    FSTYPE OPTIONS
/mnt/data1 /dev/sda1 ext4   rw,relatime,seclabel

La colonne SOURCE confirme le bon périphérique, FSTYPE le système de fichiers et OPTIONS les options actives. Ce montage est temporaire : il disparaît au prochain redémarrage tant qu'il n'est pas inscrit dans /etc/fstab.

Ne vous inquiétez pas si votre liste d'options est plus longue que celle-ci : elle dépend du système de fichiers et de la distribution. Le seclabel ci-dessus vient de SELinux, actif par défaut sur AlmaLinux et RHEL. Un volume XFS en affiche bien davantage, toutes posées automatiquement par le noyau :

TARGET     SOURCE    FSTYPE OPTIONS
/mnt/data1 /dev/sda1 xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

Ces options supplémentaires ne signalent aucune configuration particulière : ce sont les valeurs par défaut de XFS. Inutile de chercher d'où elles sortent.

Démonter proprement

Avant de débrancher un disque externe, démontez pour garantir que toutes les écritures sont terminées :

sudo umount /mnt/data1

umount, pas unmount

La commande s'écrit umount (sans le premier n). Si elle échoue avec target is busy, c'est qu'un processus utilise le point de montage. Identifiez-le :

sudo fuser -vm /mnt/data1   # ou : lsof /mnt/data1

Quittez le répertoire ou arrêtez le processus, puis recommencez.

Rendre le montage persistant avec /etc/fstab

Le fichier /etc/fstab (file systems table) liste les systèmes de fichiers montés au démarrage. La règle d'or : référencer par UUID, jamais par /dev/sdX (qui peut changer si l'ordre des disques bouge). Récupérez l'UUID :

sudo blkid /dev/sda1

/dev/sda1: UUID="16ef4b6e-8295-414a-8450-1e84ce52ca1d" TYPE="ext4"

Ajoutez une ligne à /etc/fstab. Ses six colonnes : périphérique, point de montage, type, options, dump, passe de vérification.

UUID=16ef4b6e-8295-414a-8450-1e84ce52ca1d  /mnt/data1  ext4  defaults  0 2

• UUID : identifiant stable du système de fichiers.
• Point de montage : /mnt/data1, qui doit exister.
• Type : ext4, xfs...
• Options : defaults, ou une liste (defaults,noatime).
• Dump : 0 (sauvegarde héritée, désactivée).
• Passe : ordre de vérification par fsck au démarrage.

La passe mérite un mot, parce qu'on lit partout deux règles qui se contredisent : « 1 pour la racine, 2 pour le reste » d'un côté, « 0 pour XFS » de l'autre. Le critère est simple : la passe vaut 0 dès que le système de fichiers ne se vérifie pas par fsck au démarrage, ce qui est le cas de XFS et de Btrfs, qui ont leurs propres outils. Pour les systèmes qui s'y prêtent, comme ext4, on met 1 sur la racine et 2 ailleurs.

C'est le critère qui décide, pas le point de montage. Le /etc/fstab livré par AlmaLinux 10 l'illustre : la racine y est déclarée en XFS avec une passe à 0, malgré la règle du « 1 pour / ».

UUID=1f5fce98-...  /  xfs  defaults  0 0

Tester avant de redémarrer : le réflexe vital

C'est l'étape que l'on oublie, et qui coûte cher. Une ligne /etc/fstab erronée (faute de frappe, UUID inexistant) bloque le démarrage : le système tombe en emergency mode et attend un mot de passe root. Le contrôle à chaud tient en deux commandes, et il en faut bien deux.

sudo mount -a
sudo findmnt --verify

Pourquoi mount -a seul ne suffit pas

C'est le point qui surprend, et c'est celui qui fait perdre des machines. mount -a monte ce qui n'est pas encore monté, rien de plus. Il ne relit pas ce qui l'est déjà, et il ne juge pas la cohérence du fichier. Trois /etc/fstab cassés, mesurés sur AlmaLinux 10, le traversent en code de retour 0 :

/etc/fstab cassé	Ce que fait mount -a
Type de système de fichiers erroné sur un point déjà monté	rc=0, aucun message. La ligne n'est jamais évaluée
Source introuvable avec l'option nofail	rc=0, aucun message, rien n'est monté
Ligne incomplète (deux champs au lieu de six)	parse error at line 15 -- ignored, et rc=0 quand même

Glissez pour voir

Le premier cas est le plus vicieux : tant que le point de montage reste occupé, tout paraît sain. Démontez, relancez mount -a, et la vérité tombe d'un coup :

mount: /mnt/data1: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error.

Sauf qu'au redémarrage, tout est démonté. Le moment où l'erreur apparaît est donc précisément celui où vous n'avez plus la main.

findmnt --verify attrape les trois

findmnt --verify ne monte rien : il relit le fichier et le confronte à l'état réel des périphériques. Les trois cas ci-dessus lui échappent pas.

sudo findmnt --verify

0 parse errors, 0 errors, 2 warnings
/mnt/data1
   [W] xfs does not match with on-disk ext4
   [W] your fstab has been modified, but systemd still uses the old version;
       use 'systemctl daemon-reload' to reload

Deux enseignements dans cette sortie. Le premier, xfs does not match with on-disk ext4, c'est exactement l'erreur que mount -a avait laissée passer : le fichier annonce xfs, le disque porte ext4. Le second est un rappel que le fichier seul ne suffit pas, et il amène la troisième commande.

findmnt --verify sort en 0, même quand il proteste

Le code de retour de findmnt --verify vaut 0 y compris lorsqu'il proteste. Vérifié sur les deux /etc/fstab cassés ci-dessus : celui qui affiche 0 parse errors, 0 errors, 2 warnings comme celui qui affiche 1 parse error, 0 errors, 1 warning sortent l'un et l'autre en 0.

Un script qui teste $? conclut donc à tort que tout va bien. C'est la sortie qu'il faut lire, pas le code de retour. Pour automatiser, cherchez le compte dans la ligne de synthèse plutôt que le statut du processus.

systemd garde sa propre copie du fichier

Éditer /etc/fstab ne suffit pas à en informer systemd, qui en fabrique des unités .mount au démarrage et conserve la version précédente jusqu'à ce qu'on la lui fasse relire :

sudo systemctl daemon-reload

Ce n'est pas une précaution de notre invention : l'en-tête du /etc/fstab livré par AlmaLinux le réclame noir sur blanc, et findmnt --verify le rappelle de lui-même dans sa sortie.

# After editing this file, run 'systemctl daemon-reload' to update systemd

La séquence complète avant un redémarrage est donc : mount -a, puis findmnt --verify dont on lit la sortie, puis systemctl daemon-reload.

nofail sur les disques non essentiels

Pour un disque externe ou un volume secondaire, ajoutez l'option nofail : si le disque est absent au démarrage, le système continue de booter au lieu de tomber en emergency mode. C'est indispensable sur tout ce qui n'est pas le disque système.

UUID=...  /mnt/backup  ext4  defaults,nofail  0 2

Cas courants

Quelques entrées /etc/fstab selon le besoin :

# Disque de données interne (boot dépend de lui)
UUID=...  /data         xfs   defaults              0 2
# Disque externe USB (ne doit pas bloquer le boot)
UUID=...  /mnt/backup   ext4  defaults,nofail,x-systemd.device-timeout=5  0 2
# Volume en lecture seule
UUID=...  /mnt/archive  ext4  ro                    0 2

L'option x-systemd.device-timeout=5 limite l'attente à 5 secondes si le périphérique tarde, utile combinée à nofail.

Dépannage

Les pannes de montage se ressemblent toutes vues de loin : « ça ne remonte pas ». Le tableau ci-dessous les sépare par symptôme observable, parce que c'est ce dont vous disposez au moment où le problème tombe. Les deux premières lignes couvrent le cas le plus coûteux, celui où le contrôle a menti avant le redémarrage.

Symptôme	Cause probable	Solution
Boot en emergency mode après modif fstab	UUID erroné ou option invalide	corriger la ligne, ou la commenter ; mount -a et findmnt --verify avant tout reboot
mount -a muet, mais le boot casse quand même	le point était déjà monté, ou la ligne porte nofail	findmnt --verify : il relit le fichier au lieu de se contenter de monter
umount: target is busy	processus dans le point de montage	fuser -vm <pt>, quitter le répertoire
Disque externe bloque le démarrage	pas de nofail	ajouter nofail à la ligne
Montage absent après reboot	ligne oubliée dans /etc/fstab	ajouter l'entrée, puis mount -a, findmnt --verify et systemctl daemon-reload
Le montage se comporte comme avant l'édition	systemd utilise encore l'ancienne version du fichier	systemctl daemon-reload

Glissez pour voir

Matériel pour pratiquer

Pour vous entraîner à monter et démonter des disques externes (SATA et NVMe), la station d'accueil ICY BOX USB 3.2 Gen 2 accueille des disques 2,5"/3,5" et des SSD M.2, reconnus immédiatement par Linux dès le branchement.

Lien affilié Amazon. Acheter via ce lien soutient le site sans surcoût pour vous.

Mettre en pratique

Une entrée /etc/fstab ne se juge qu'après un redémarrage : c'est exactement ce que le lab vérifie. Vous montez un disque supplémentaire sur /srv/data, référencé par UUID plutôt que par nom de périphérique, et vous validez la ligne avec mount -a puis findmnt --verify avant de prouver que le montage persistant survit au reboot.

Lab pratique

Monter un système de fichiers de façon persistante par UUID

$ dsoxlab run l2-fstab-persist-uuid

Environnement : VM·Durée : ~25 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l2-fstab-persist-uuid
dsoxlab check l2-fstab-persist-uuid

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

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

• Un système de fichiers n'est utilisable qu'une fois monté ; findmnt vérifie le résultat.
• Démontez (umount) avant de débrancher ; fuser -vm trouve ce qui bloque.
• Dans /etc/fstab, référencez par UUID (stable), jamais par /dev/sdX.
• La passe vaut 0 pour les systèmes qui ne se vérifient pas par fsck (XFS, Btrfs), 1 pour une racine ext4 et 2 ailleurs.
• Le contrôle avant redémarrage, c'est mount -a et findmnt --verify : mount -a seul sort en 0 sur au moins trois /etc/fstab cassés.
• findmnt --verify sort en 0 même quand il proteste : lisez sa sortie, ne testez pas $?.
• Après édition, systemctl daemon-reload : systemd garde sinon l'ancienne version du fichier.
• nofail sur les disques non essentiels évite un démarrage en emergency mode.

Pour aller plus loin

• Un serveur bloqué au démarrage : ce qui arrive quand une entrée de /etc/fstab sans nofail pointe vers un disque absent.
• Un système de fichiers en lecture seule : le montage réussit, mais les écritures échouent.
• Capacité et quotas disque : Surveiller df/du et éviter la saturation.

×

📖 Voir la documentation →