Linux sans magie #39 — /etc/fstab : rendre un montage persistant sans piéger le prochain démarrage

Dans l’article précédent, nous avons distingué UUID, LABEL et PARTUUID des noms de périphériques comme /dev/sda1.

Ces identifiants deviennent particulièrement utiles lorsqu’un filesystem doit être retrouvé automatiquement après un redémarrage.

Sous Linux, cette configuration passe traditionnellement par /etc/fstab.

Mais une erreur dans ce fichier ne se résume pas à une faute de frappe anodine. Une mauvaise source, un mauvais point de montage ou des options inadaptées peuvent empêcher un filesystem de se monter comme prévu et perturber le démarrage du système.

L’objectif de cet article est donc de comprendre fstab, de savoir lire ses six champs et surtout d’apprendre à vérifier une modification avant de redémarrer.

Contexte et problème

Un montage réalisé manuellement avec mount appartient à l’état courant du système.

Après un redémarrage, Linux doit disposer d’une configuration permettant de savoir :

• quelle source utiliser ;
• où monter le filesystem ;
• quel type de filesystem employer ;
• quelles options appliquer ;
• comment intégrer éventuellement ce filesystem aux mécanismes de vérification au démarrage.

Le fichier /etc/fstab, pour filesystem table, fournit ces informations.

Il ne constitue cependant pas simplement une liste de commandes mount.

Il décrit des filesystems que différents composants peuvent exploiter. Les outils mount, umount, fsck et, sur les systèmes concernés, systemd peuvent notamment utiliser ces informations.

C’est pourquoi il faut comprendre la structure du fichier avant de le modifier.

Concept : les six champs d’une ligne fstab

Prenons une ligne conceptuelle :

UUID=<FILESYSTEM_UUID>  /data  ext4  defaults  0  2

Elle comporte six champs.

1. La source

Le premier champ indique le filesystem ou la ressource concernée.

On pourrait rencontrer un périphérique comme :

/dev/sdb1

mais pour un filesystem local classique, il est généralement préférable d’utiliser un identifiant stable :

UUID=<FILESYSTEM_UUID>

ou, selon le besoin :

LABEL=<FILESYSTEM_LABEL>

PARTUUID= et PARTLABEL= sont également pris en charge dans les contextes appropriés.

L’intérêt est opérationnel : un nom comme /dev/sdb1 dépend de la détection des périphériques et peut changer lorsque le matériel ou l’ordre de découverte change. Un UUID de filesystem reste associé au filesystem lui-même.

C’est exactement la distinction construite dans le #38.

2. Le point de montage

Le deuxième champ indique la cible dans l’arborescence :

/data

Le répertoire doit correspondre à l’endroit où le contenu du filesystem doit devenir accessible.

Un point de montage n’est pas le disque et n’est pas le filesystem. C’est un emplacement de l’arborescence Linux auquel le filesystem sera attaché.

3. Le type de filesystem

Le troisième champ indique le type :

ext4

On peut également rencontrer xfs, btrfs, vfat, nfs, cifs, tmpfs et d’autres types selon l’environnement.

Ce champ doit correspondre à la ressource réellement utilisée.

4. Les options de montage

Le quatrième champ contient une liste d’options séparées par des virgules.

Un exemple très courant est :

defaults

Il faut éviter d’interpréter defaults comme une liste universelle et figée d’options. Le comportement par défaut dépend notamment du kernel et du filesystem.

D’autres options existent pour répondre à des besoins précis.

Par exemple :

noauto

indique qu’une entrée ne doit pas être montée par mount -a.

Une autre option souvent rencontrée est :

nofail

Elle permet notamment d’indiquer qu’une ressource absente ne doit pas être traitée de la même manière qu’un filesystem indispensable.

Sur un système utilisant systemd, certaines options influencent aussi les dépendances générées pour les mount units. Elles ne doivent donc pas être ajoutées mécaniquement sans comprendre leur effet.

5. Le champ dump

Le cinquième champ, souvent :

0

est historiquement utilisé par dump.

Sur de nombreux systèmes modernes, on rencontre donc fréquemment la valeur 0.

Cela ne signifie pas pour autant que ce champ n’existe plus : il fait toujours partie du format fstab.

6. L’ordre de vérification fsck

Le sixième champ participe à l’organisation des vérifications de filesystem avec fsck.

Les valeurs typiques sont :

0
1
2

Conceptuellement :

• 0 : ne pas demander cette vérification via ce mécanisme ;
• 1 : généralement réservé au filesystem racine ;
• 2 : autres filesystems devant être vérifiés.

La valeur correcte dépend du filesystem et de la stratégie du système. Il ne faut donc pas recopier 2 mécaniquement sur toutes les lignes.

Prérequis

Le lab suppose :

• un système GNU/Linux ;
• les outils findmnt et lsblk de util-linux ;
• un filesystem déjà existant ;
• un point de montage identifié ;
• des privilèges administrateur uniquement pour la modification réelle de /etc/fstab.

L’objectif n’est pas de créer une partition ni un filesystem.

Aucune commande fdisk, parted ou mkfs n’est nécessaire.

Avant toute modification, identifiez la ressource avec une commande d’observation :

lsblk -o NAME,TYPE,FSTYPE,UUID,LABEL,MOUNTPOINTS

Puis observez les montages actuels :

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Mise en pratique : préparer un montage persistant

Prenons le cas d’un filesystem existant que nous souhaitons rendre accessible sur :

/data

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

Commencez par :

lsblk -o NAME,TYPE,FSTYPE,UUID,LABEL,MOUNTPOINTS

Repérez :

• le bon block device ;
• son FSTYPE ;
• son UUID ;
• son éventuel point de montage actuel.

Ne recopiez pas un UUID provenant d’un autre périphérique.

Le placeholder utilisé ensuite sera :

<FILESYSTEM_UUID>

Étape 2 — Vérifier le point de montage

Contrôlez l’existence du répertoire :

ls -ld /data

S’il n’existe pas, sa création modifie le système. Elle doit donc être volontaire :

sudo mkdir -p /data

Avant d’utiliser ce chemin, vérifiez également qu’un autre filesystem n’y est pas déjà monté :

findmnt /data

L’absence de résultat indique qu’aucun montage correspondant n’a été trouvé par cette interrogation.

Étape 3 — Sauvegarder fstab

Avant modification :

sudo cp -a /etc/fstab /etc/fstab.backup

Vérifiez la sauvegarde :

ls -l /etc/fstab /etc/fstab.backup

Cette copie ne protège pas contre toutes les erreurs possibles, mais fournit un moyen simple de revenir au contenu précédent.

Étape 4 — Ajouter l’entrée

Éditez le fichier avec l’outil habituel de votre environnement, par exemple :

sudoedit /etc/fstab

Pour un filesystem ext4, une entrée pédagogique pourrait ressembler à :

UUID=<FILESYSTEM_UUID>  /data  ext4  defaults  0  2

Ne copiez pas cette ligne telle quelle.

Vous devez remplacer :

<FILESYSTEM_UUID>

par l’UUID réellement observé et confirmer que ext4 correspond bien au filesystem concerné.

Étape 5 — Vérifier fstab avant tout redémarrage

C’est l’étape la plus importante du lab.

Exécutez :

sudo findmnt --verify --verbose

findmnt --verify analyse notamment la parsabilité et l’utilisabilité de la table de montage.

Une erreur signalée ici doit être corrigée avant de poursuivre.

Cette vérification est beaucoup plus sûre qu’une stratégie consistant à modifier fstab, redémarrer immédiatement et découvrir ensuite que le système ne se comporte plus comme prévu.

Étape 6 — Recharger systemd si nécessaire

Sur un système basé sur systemd, après modification de /etc/fstab, rechargez la configuration du manager :

sudo systemctl daemon-reload

systemd-fstab-generator traduit les entrées de /etc/fstab en unités systemd lors du démarrage et lors du rechargement de la configuration du manager.

Cette commande ne signifie pas que tous les nouveaux filesystems seront instantanément montés.

Étape 7 — Tester uniquement le montage concerné

Plutôt que de tester immédiatement toutes les entrées de fstab, ciblez le point de montage concerné :

sudo mount /data

Lorsque seul le point de montage est fourni, mount peut utiliser l’entrée correspondante de fstab.

Cette approche limite le test à la configuration que vous venez d’ajouter.

Résultat attendu

La commande suivante :

findmnt /data

doit afficher une entrée correspondant au filesystem attendu.

Vous pouvez ensuite contrôler les informations utiles :

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /data

Le résultat doit permettre de relier :

TARGET  → /data
SOURCE  → filesystem attendu
FSTYPE  → type attendu
OPTIONS → options réellement appliquées

Vérification avant redémarrage

Avant de considérer la configuration comme terminée, vérifiez au minimum :

sudo findmnt --verify --verbose

puis :

findmnt /data

et enfin :

lsblk -o NAME,FSTYPE,UUID,MOUNTPOINTS

L’objectif est de confirmer trois choses différentes :

1. fstab est correctement interprétable ;
2. le filesystem peut effectivement être monté ;
3. la source montée correspond bien au filesystem prévu.

Un redémarrage ne doit pas être utilisé comme premier outil de validation.

Bonnes pratiques

Préférez un identifiant stable comme UUID= à un nom /dev/sdX lorsque le cas d’usage le permet.

Sauvegardez /etc/fstab avant modification.

Vérifiez toujours la configuration avant de redémarrer.

Ne copiez pas aveuglément des options trouvées sur un autre système. Les besoins diffèrent selon le filesystem, le type de stockage, la criticité du montage et la distribution.

Pour un stockage facultatif ou amovible, étudiez précisément les conséquences de nofail, noauto ou des options spécifiques à systemd avant de les appliquer.

Pour un montage réseau, la problématique change également : disponibilité du réseau, DNS, authentification et ordre de démarrage peuvent devenir déterminants.

Ces scénarios méritent un traitement séparé.

Sécurité

Les options de montage participent à la politique de sécurité du système.

Des options comme nosuid, nodev ou noexec peuvent être pertinentes dans certains contextes, mais elles ne doivent pas être appliquées comme une recette universelle.

Leur pertinence dépend du contenu du filesystem et des applications qui l’utilisent.

La modification de /etc/fstab nécessite généralement des privilèges élevés. Limitez donc l’édition aux comptes administratifs autorisés et conservez une trace des changements dans les environnements gérés.

Une entrée incorrecte pointant vers la mauvaise ressource peut aussi rendre accessibles des données à un emplacement inattendu. L’identification préalable du filesystem est donc également une mesure de sécurité.

Coûts

La configuration de /etc/fstab elle-même n’entraîne aucun coût logiciel.

Dans un environnement cloud, le stockage sous-jacent peut en revanche être facturable. Cet article ne demande ni création ni agrandissement d’un disque et ne modifie donc pas directement les ressources cloud existantes.

Limites et points de vigilance

Cet article reste volontairement centré sur un filesystem local simple.

Il ne traite pas encore en détail :

• des montages NFS ou CIFS ;
• des options avancées de systemd ;
• de x-systemd.automount ;
• des volumes chiffrés avec crypttab ;
• de LVM ;
• du swap ;
• des bind mounts ;
• des scénarios initramfs.

Autre point important : fstab et systemd ne sont pas deux mécanismes complètement indépendants sur un système systemd. systemd-fstab-generator interprète fstab et génère dynamiquement les unités nécessaires.

Il existe donc quelques différences entre la sémantique documentée par util-linux et les comportements spécifiques à systemd. Lorsqu’une option systemd est utilisée, sa documentation doit être consultée explicitement.

Rollback

Si le nouveau montage a été activé et doit être retiré, commencez par vous assurer qu’aucun processus nécessaire n’utilise le filesystem.

Démontez ensuite uniquement le point concerné :

sudo umount /data

Restaurez le fichier sauvegardé :

sudo cp -a /etc/fstab.backup /etc/fstab

Sur un système systemd :

sudo systemctl daemon-reload

Puis contrôlez de nouveau :

sudo findmnt --verify --verbose

Attention : un filesystem occupé ne peut pas nécessairement être démonté immédiatement. Il faut alors identifier les processus ou usages actifs au lieu de forcer aveuglément le démontage.

Références officielles

• fstab(5) — filesystem table — util-linux / Linux man-pages
• findmnt(8) — find a filesystem — util-linux / Linux man-pages
• mount(8) — mount a filesystem — util-linux / Linux man-pages
• umount(8) — unmount filesystems — util-linux / Linux man-pages
• systemd-fstab-generator(8) — systemd
• systemd.mount(5) — systemd

Conclusion

/etc/fstab devient beaucoup moins mystérieux lorsqu’on le lit comme une description structurée : source, cible, type, options et paramètres de vérification.

La règle opérationnelle essentielle est simple : identifier la bonne ressource, sauvegarder, modifier, vérifier, puis seulement envisager le redémarrage.

Le prochain article pourra logiquement approfondir mount et umount eux-mêmes : ce qu’ils font réellement, comment tester un montage manuellement et comment diagnostiquer un filesystem qui refuse de se démonter.

---