Linux sans magie #40 — mount et umount : monter, démonter et comprendre « target is busy »

Dans le #39, nous avons utilisé /etc/fstab pour rendre un montage persistant.

Mais avant de rendre quoi que ce soit automatique, il faut comprendre l’opération élémentaire : attacher un filesystem à l’arborescence Linux, puis le détacher proprement.

C’est le rôle de mount et umount.

Ces commandes paraissent simples jusqu’au jour où umount répond :

target is busy

Ce message n’est pas un obstacle à contourner avec une option « force ». Il indique généralement que le kernel constate encore une utilisation du filesystem.

L’objectif de cet article est de comprendre le cycle complet : monter, observer, utiliser, identifier les dépendances actives et démonter proprement.

Contexte : un filesystem n’est pas directement « une lettre de lecteur »

Sous Linux, un filesystem devient accessible lorsqu’il est attaché à un emplacement de l’arborescence.

Prenons :

/dev/sdb1

qui contient un filesystem existant.

Pour accéder à son contenu via :

/mnt/data

il faut créer une relation entre cette source et ce point de montage.

Conceptuellement :

filesystem
    ↓
/dev/sdb1
    ↓ mount
/mnt/data

Une fois monté, le contenu du filesystem apparaît sous /mnt/data.

Lorsque le filesystem est démonté, /mnt/data reste un répertoire de l’arborescence, mais le contenu du filesystem n’y est plus attaché.

mount ne déplace pas les données

Une commande comme :

sudo mount /dev/sdb1 /mnt/data

ne copie pas les fichiers vers /mnt/data.

Elle demande au kernel de rendre le filesystem accessible à cet endroit de l’arborescence.

Cette distinction est fondamentale.

Si le répertoire /mnt/data contient déjà des fichiers avant le montage, ceux-ci ne sont pas supprimés. Ils deviennent simplement masqués par le filesystem monté tant que celui-ci reste attaché à ce point.

Après démontage, les fichiers du répertoire sous-jacent redeviennent visibles.

Cette propriété explique pourquoi il faut vérifier un point de montage avant de l'utiliser.

Prérequis

Le lab suppose :

• un système GNU/Linux ;
• util-linux avec mount, umount et findmnt ;
• un filesystem existant et non critique ;
• un point de montage dédié ;
• des privilèges administrateur pour effectuer le montage.

L’article ne crée ni partition ni filesystem.

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

Nous utiliserons :

<DEVICE>

pour représenter la source réelle, par exemple :

/dev/sdb1

et :

<MOUNTPOINT>

pour le point de montage, par exemple :

/mnt/data

Étape 1 — Identifier la source

Commencez par observer les block devices :

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

Repérez le filesystem à utiliser.

Il faut notamment vérifier :

• le périphérique ;
• son FSTYPE ;
• son UUID ;
• ses éventuels points de montage actuels.

N’utilisez pas un périphérique si vous n’êtes pas certain de son rôle.

Vous pouvez également rechercher un filesystem par UUID :

findmnt --source UUID=<FILESYSTEM_UUID>

L’absence de résultat peut simplement signifier que ce filesystem n’est actuellement pas monté.

Étape 2 — Préparer le point de montage

Vérifiez d’abord le répertoire :

ls -ld <MOUNTPOINT>

S’il n’existe pas :

sudo mkdir -p <MOUNTPOINT>

Avant de monter quoi que ce soit, vérifiez qu’il n’est pas déjà utilisé comme point de montage :

findmnt --target <MOUNTPOINT>

Vous pouvez également utiliser :

mountpoint <MOUNTPOINT>

mountpoint permet précisément de déterminer si un fichier ou un répertoire constitue un point de montage.

Étape 3 — Monter le filesystem

Pour un montage temporaire explicite :

sudo mount <DEVICE> <MOUNTPOINT>

Par exemple :

sudo mount /dev/sdb1 /mnt/data

Dans cette forme, mount détermine généralement le type du filesystem à partir des informations disponibles.

Il est également possible de préciser le type lorsque le contexte l’exige :

sudo mount -t ext4 <DEVICE> <MOUNTPOINT>

Il ne faut cependant pas indiquer arbitrairement ext4. Le type doit correspondre au filesystem réellement présent.

Étape 4 — Vérifier le montage

Ne vous contentez pas de l’absence de message d’erreur.

Interrogez l’état réel :

findmnt <MOUNTPOINT>

Pour obtenir les principales informations :

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS <MOUNTPOINT>

Le résultat permet de vérifier :

TARGET  → emplacement dans l’arborescence
SOURCE  → source réellement montée
FSTYPE  → type de filesystem
OPTIONS → options actives

Vous pouvez aussi comparer avec :

lsblk -o NAME,FSTYPE,UUID,MOUNTPOINTS

findmnt est particulièrement adapté à ce travail car il peut exploiter les informations de montage maintenues par le kernel dans /proc/self/mountinfo.

Montage par UUID

Après le #38, nous savons qu’un nom tel que :

/dev/sdb1

n’est pas nécessairement l’identifiant le plus stable.

mount accepte également des identifiants comme :

sudo mount UUID=<FILESYSTEM_UUID> <MOUNTPOINT>

Cette syntaxe permet de cibler le filesystem par son UUID.

Pour une configuration persistante dans /etc/fstab, c’est précisément ce principe que nous avons utilisé dans le #39.

Que fait umount ?

Pour retirer proprement le filesystem de l’arborescence :

sudo umount <MOUNTPOINT>

Par exemple :

sudo umount /mnt/data

La commande s’appelle bien :

umount

et non unmount.

Il est généralement préférable de désigner le point de montage plutôt que le block device.

Un même device peut en effet intervenir dans plusieurs montages, alors que la cible indique explicitement l’attachement que l’on souhaite supprimer.

Après l’opération :

findmnt <MOUNTPOINT>

ne doit plus montrer ce montage.

Vous pouvez également vérifier :

mountpoint <MOUNTPOINT>

Comprendre « target is busy »

Supposons maintenant que nous exécutions :

sudo umount /mnt/data

et obtenions un message équivalent à :

umount: /mnt/data: target is busy.

Le kernel refuse le démontage parce que le filesystem est encore utilisé.

Les causes courantes comprennent :

• un fichier ouvert ;
• un processus dont le working directory se trouve dans le filesystem ;
• un programme exécuté depuis ce filesystem ;
• un fichier utilisé via un mapping mémoire ;
• un autre filesystem monté sous ce point ;
• un swap file actif dans ce filesystem.

Le bon réflexe est donc :

identifier l’utilisation avant de décider quoi faire.

Cas simple : votre propre shell bloque le démontage

Considérons :

cd /mnt/data

puis :

sudo umount /mnt/data

Votre shell possède maintenant son répertoire courant dans le filesystem.

Le démontage peut donc échouer.

Revenez ailleurs :

cd /

puis réessayez :

sudo umount /mnt/data

Cette situation très simple illustre le sens réel de « busy » : un processus conserve encore une référence vers le filesystem.

Identifier les processus avec fuser

L’outil fuser peut afficher les processus utilisant des fichiers ou un filesystem.

Pour inspecter un point de montage :

sudo fuser -vm <MOUNTPOINT>

Par exemple :

sudo fuser -vm /mnt/data

L’option -m considère l’argument comme appartenant à un filesystem monté et recherche les processus qui l’utilisent.

Le mode verbose peut également indiquer le type d’accès.

Par exemple, la documentation de fuser utilise notamment :

c

pour un current directory et :

f

pour un fichier ouvert.

Cette information aide à comprendre pourquoi le processus empêche le démontage.

fuser peut ne fournir que des informations partielles lorsqu’il n’a pas les permissions nécessaires. L’exécuter avec les privilèges adaptés peut donc être nécessaire pour un diagnostic complet.

Utiliser lsof lorsque nécessaire

lsof signifie historiquement « list open files ».

Pour inspecter les fichiers ouverts sous une arborescence, on peut notamment rencontrer :

sudo lsof +D <MOUNTPOINT>

Cette recherche descend récursivement dans l’arborescence et peut être coûteuse sur un filesystem volumineux.

Elle est donc utile comme outil de diagnostic, pas comme commande à lancer systématiquement sur n’importe quel stockage.

Dans beaucoup de cas de démontage, commencez par :

sudo fuser -vm <MOUNTPOINT>

puis approfondissez uniquement si nécessaire.

Ne pas utiliser immédiatement fuser -k

fuser possède également une option :

-k

capable d’envoyer un signal aux processus utilisant la ressource.

Une commande du type :

sudo fuser -km <MOUNTPOINT>

peut donc arrêter plusieurs processus.

Ce n’est pas une commande de diagnostic.

Elle modifie activement l’état du système et peut interrompre une application, un service ou un traitement en cours.

La méthode normale est :

1. identifier les PID ;
2. comprendre les processus concernés ;
3. arrêter proprement le service ou l’application si nécessaire ;
4. revérifier ;
5. démonter.

Par exemple :

sudo fuser -vm <MOUNTPOINT>

puis :

ps -fp <PID>

permet d’identifier le processus avant toute action.

Vérifier les sous-montages

Un filesystem peut également contenir d’autres points de montage.

Inspectez la hiérarchie :

findmnt -R <MOUNTPOINT>

Si plusieurs filesystems sont montés sous la cible, il faut comprendre cette hiérarchie avant de démonter le parent.

Forcer aveuglément le démontage du niveau supérieur n’est pas une bonne stratégie.

Pourquoi umount -l n’est pas une solution universelle

On rencontre souvent :

sudo umount -l <MOUNTPOINT>

-l signifie lazy unmount.

Le filesystem est détaché de l’arborescence immédiatement pour les nouveaux accès, mais les références existantes sont nettoyées ultérieurement lorsque le filesystem cesse d’être occupé.

Cela peut donner l’impression que le problème est résolu alors que certaines références existent encore.

La documentation util-linux recommande notamment ce mécanisme pour certains cas de partage réseau inaccessible, par exemple lorsqu’un démontage normal bloque pendant l’arrêt du système.

Pour un filesystem local simplement occupé par un processus que vous pouvez identifier, mieux vaut comprendre et supprimer proprement la cause.

Pourquoi umount -f mérite encore plus de prudence

Une autre option est :

sudo umount -f <MOUNTPOINT>

-f signifie force.

Elle est notamment prévue pour certaines situations où un filesystem réseau, comme un serveur NFS inaccessible, pose problème.

Elle ne constitue pas une méthode générique pour résoudre :

target is busy

Le mécanisme kernel correspondant peut demander au filesystem d’abandonner des requêtes en attente, avec un risque potentiel de perte de données.

De plus, tous les types de filesystems ne prennent pas nécessairement en charge ce comportement de la même façon.

Le principe à retenir est donc :

busy
↓
diagnostiquer
↓
arrêter proprement l'utilisation
↓
umount normal

et non :

busy
↓
-f

Procédure de diagnostic reproductible

Lorsqu’un démontage échoue, utilisez une séquence comme celle-ci.

1. Confirmer le montage

findmnt <MOUNTPOINT>

2. Examiner les sous-montages

findmnt -R <MOUNTPOINT>

3. Identifier les processus utilisateurs

sudo fuser -vm <MOUNTPOINT>

4. Identifier les PID intéressants

ps -fp <PID>

5. Quitter les shells situés dans le filesystem

Dans les terminaux concernés :

cd /

6. Arrêter proprement l’application ou le service responsable

La méthode dépend du processus identifié.

Si un service systemd est réellement responsable, utilisez son unité réelle, par exemple :

sudo systemctl stop <SERVICE>

Ne devinez pas le nom du service.

7. Vérifier à nouveau

sudo fuser -vm <MOUNTPOINT>

8. Démonter normalement

sudo umount <MOUNTPOINT>

9. Confirmer

findmnt <MOUNTPOINT>

puis :

mountpoint <MOUNTPOINT>

Cette démarche fournit un diagnostic plutôt qu’un contournement.

Cas particulier de /etc/fstab

Si le filesystem est déclaré dans /etc/fstab, son démontage manuel ne supprime pas cette configuration persistante.

Vous pouvez faire :

sudo umount /data

et le filesystem peut malgré tout être remonté lors d’un démarrage ultérieur ou par un mécanisme utilisant fstab.

Il faut donc distinguer :

état actuel du montage

de :

configuration persistante

C’est précisément la séparation entre ce #40 et le #39.

Sécurité

mount et umount touchent à l’organisation des filesystems du système et requièrent généralement des privilèges adaptés.

Avant un démontage, assurez-vous que la cible est correcte :

findmnt <MOUNTPOINT>

Cette vérification est particulièrement importante sur une machine de production.

Évitez également de tuer automatiquement tous les processus retournés par fuser.

Un PID peut appartenir à :

• une base de données ;
• un service applicatif ;
• une sauvegarde ;
• un shell administrateur ;
• un traitement d’écriture.

Un arrêt brutal peut provoquer une interruption de service ou une perte de travail non synchronisé.

La règle reste : observer avant d’agir.

Coûts

mount, umount, findmnt et les mécanismes kernel associés n’impliquent pas de coût logiciel particulier.

Dans un environnement cloud, le volume sous-jacent peut naturellement rester facturé même lorsqu’il n’est pas monté dans le système d’exploitation.

Démonter un filesystem n’équivaut pas à détacher ou supprimer un volume cloud.

Limites et points de vigilance

Cet article se concentre sur le montage dans le namespace courant d’un système Linux classique.

Les mount namespaces peuvent modifier la visibilité des montages entre processus, notamment avec :

• les conteneurs ;
• certains environnements d’isolation ;
• des outils utilisant les Linux namespaces.

Un montage visible depuis un processus n’est donc pas nécessairement visible de façon identique depuis un autre namespace.

Les filesystems réseau introduisent également d’autres problématiques :

• serveur inaccessible ;
• DNS ;
• réseau ;
• timeouts ;
• authentification ;
• état des connexions.

Ils feront appel à des méthodes de diagnostic complémentaires.

Rollback et nettoyage

Un montage temporaire réalisé avec :

sudo mount <DEVICE> <MOUNTPOINT>

peut normalement être annulé par :

sudo umount <MOUNTPOINT>

Vérifiez ensuite :

findmnt <MOUNTPOINT>

Si le répertoire avait été créé uniquement pour ce lab et qu’il est vide :

rmdir <MOUNTPOINT>

N’utilisez pas :

rm -rf <MOUNTPOINT>

comme méthode de nettoyage d’un point de montage.

Avant toute suppression de répertoire, confirmez d’abord qu’aucun filesystem n’y est encore monté :

mountpoint <MOUNTPOINT>

Références officielles

• mount(8) — mount a filesystem — util-linux
• umount(8) — unmount filesystems — util-linux
• findmnt(8) — find a filesystem — util-linux
• umount(2) — unmount filesystem — Linux man-pages
• mountpoint(1) — see if a directory is a mountpoint — util-linux
• fuser(1) — identify processes using files or sockets — psmisc
• lsof(8) — list open files — lsof project

Conclusion

mount et umount deviennent beaucoup plus simples lorsqu’on les considère comme des opérations d’attachement et de détachement dans l’arborescence Linux.

La partie la plus importante n’est pas de mémoriser une option permettant de contourner target is busy.

C’est de savoir répondre à la question :

« Qui utilise encore ce filesystem, et pourquoi ? »

Avec findmnt, fuser et une vérification méthodique, la majorité des situations peuvent être comprises avant toute action forcée.

La suite logique du bloc stockage sera de descendre d’un niveau : comprendre ce qui organise les partitions elles-mêmes avec GPT et MBR.

---