il y a 1 an

Montage sous Linux : rattacher disques, ISO et partages au bon endroit

Sous Windows, un nouveau volume reçoit souvent une lettre : C:, D:, E:… Une méthode simple, efficace et vaguement comparable à la distribution de tickets dans une administration.

Linux préfère une autre philosophie.

Il existe une seule grande arborescence qui commence à la racine :

Les disques, partitions, clés USB, systèmes de fichiers réseau et autres ressources viennent ensuite se rattacher à cette arborescence à l’endroit choisi.

Cette opération s’appelle le montage.

Monter un système de fichiers consiste à rendre son contenu accessible depuis un répertoire de l’arborescence Linux.

Le concept est simple.

La mise en œuvre l’est également, jusqu’au moment où l’on monte un partage réseau indispensable au démarrage sur un serveur qui n’a justement pas encore de réseau.

C’est là que l’administration système commence réellement.

Le principe du montage

Un système de fichiers peut exister parfaitement sur un disque sans être directement accessible dans votre arborescence.

Prenons une partition :

/dev/sdb1

Elle contient un système de fichiers ext4.

On crée un répertoire :

sudo mkdir -p /mnt/data

Puis on demande au noyau de rattacher le système de fichiers à cet emplacement :

sudo mount /dev/sdb1 /mnt/data

Dès cet instant, le contenu de /dev/sdb1 devient visible sous :

/mnt/data

Pour les applications, il s’agit simplement d’un répertoire supplémentaire.

Les programmes n’ont pas besoin de savoir si les fichiers qu’ils y trouvent proviennent :

d’un disque SATA ;
d’un SSD NVMe ;
d’une clé USB ;
d’un serveur NFS situé à l’autre bout du bâtiment ;
d’un partage SMB ;
d’une image ISO ;
d’un système de fichiers temporaire en mémoire ;
ou d’une machinerie de stockage tellement compliquée que même lsblk demande quelques secondes de réflexion.

Le VFS : pourquoi tout ressemble à un fichier

Cette uniformité est rendue possible notamment par la couche VFS — Virtual File System du noyau Linux.

Le VFS fournit une interface commune permettant à des systèmes de fichiers très différents de coexister dans la même arborescence.

Un programme peut donc effectuer des opérations classiques comme :

open()
read()
write()
close()

sans nécessairement connaître les détails physiques du stockage situé derrière.

C’est l’une des grandes élégances d’Unix :

Vous ouvrez un fichier.
Le noyau se charge de déterminer combien de couches de sorcellerie sont nécessaires pour réellement vous le fournir.

Le point de montage

Le répertoire auquel on rattache un système de fichiers est appelé point de montage.

Par exemple :

/mnt/data
/mnt/usb
/srv/backups
/media/cdrom

Le répertoire doit normalement exister avant le montage lorsqu’on utilise la commande classique.

Par exemple :

sudo mkdir -p /mnt/usb
sudo mount /dev/sdb1 /mnt/usb

Que devient le contenu déjà présent dans le répertoire ?

Supposons que /mnt/data contienne déjà :

/mnt/data/fichier-important.txt

Puis vous montez un autre système de fichiers sur :

/mnt/data

Le fichier original n’est pas supprimé.

Il devient simplement masqué par le système de fichiers monté.

Après :

sudo umount /mnt/data

le contenu original réapparaît.

C’est un mécanisme très pratique.

C’est également une excellente manière de passer vingt minutes à rechercher des fichiers « disparus » qui n’ont jamais quitté leur place.

/mnt et /media : où monter ?

Deux emplacements apparaissent souvent.

/mnt

/mnt est traditionnellement utilisé pour les montages temporaires effectués par l’administrateur.

Par exemple :

/mnt/usb
/mnt/iso
/mnt/test

/media

/media est traditionnellement destiné aux supports amovibles.

Les environnements graphiques peuvent notamment y créer automatiquement des points de montage lorsqu’un utilisateur branche une clé USB.

On rencontre par exemple :

/media/alice/USB-DATA

/srv

Pour du stockage destiné à être utilisé durablement par des services, un emplacement sous :

/srv

peut être plus cohérent.

Par exemple :

/srv/data
/srv/backups
/srv/www

Il n’existe donc pas une obligation universelle de monter tous les disques sous /mnt.

Le point de montage doit surtout avoir un sens dans l’organisation de la machine.

Identifier avant de monter

Avant de monter aveuglément /dev/sdb1, vérifiez ce que représente réellement /dev/sdb1.

Afficher les périphériques bloc

lsblk

Une version plus informative :

lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS,MODEL

Par exemple :

NAME   SIZE TYPE FSTYPE LABEL  MOUNTPOINTS
sda    1.8T disk
└─sda1 1.8T part ext4   DATA   /srv/data
sdb    931G disk
└─sdb1 931G part exfat  USB

Afficher les systèmes de fichiers

lsblk -f

ou :

sudo blkid

Ces commandes permettent notamment d’identifier :

le type du système de fichiers ;
son UUID ;
son label ;
son état de montage.

Une habitude beaucoup plus sûre que :

« Je crois que le disque externe est sdb. »

Les sauvegardes ont été inventées pour ceux qui prononcent régulièrement cette phrase.

La commande mount

La forme générale est :

mount [options] source point_de_montage

Dans la plupart des opérations administratives sur des périphériques bloc, il faut utiliser les privilèges root :

sudo mount /dev/sdb1 /mnt/data

Lorsque le type du système de fichiers peut être détecté automatiquement, il n’est généralement pas nécessaire de préciser -t.

Le noyau et les outils de montage reconnaissent normalement le système de fichiers à partir de ses métadonnées.

Monter une partition ext4

Créons d’abord le point de montage :

sudo mkdir -p /mnt/data

Puis :

sudo mount /dev/sdb1 /mnt/data

Vérifiez :

findmnt /mnt/data

ou :

df -hT /mnt/data

Monter explicitement un type de système de fichiers

L’option :

-t

permet de préciser le type.

Par exemple :

sudo mount -t ext4 /dev/sdb1 /mnt/data

Pour exFAT :

sudo mount -t exfat /dev/sdb1 /mnt/usb

Dans beaucoup de cas, ceci suffit toutefois :

sudo mount /dev/sdb1 /mnt/usb

Préciser manuellement le type n’est donc pas toujours nécessaire.

Monter en lecture seule

Pour empêcher normalement les écritures sur le système de fichiers :

sudo mount -o ro /dev/sdb1 /mnt/lecture

ro signifie read-only.

L’option inverse est :

rw

pour read-write.

Un montage en lecture seule est particulièrement intéressant :

pour examiner un volume suspect ;
pour certaines opérations de récupération ;
pour éviter des modifications accidentelles ;
pour des médias qui n’ont de toute façon aucune raison d’être modifiés.

Si votre objectif est de récupérer des données sur un système de fichiers endommagé, éviter les écritures inutiles est généralement une excellente idée.

La première étape d’une récupération ne devrait pas être de donner au système quinze nouvelles occasions de modifier le disque.

Monter une image ISO

Une image ISO est un fichier représentant généralement un système de fichiers optique.

Créons un point de montage :

sudo mkdir -p /mnt/iso

Puis :

sudo mount -o loop,ro fichier.iso /mnt/iso

L’option loop utilise un loop device, c’est-à-dire un mécanisme permettant de présenter un fichier comme un périphérique bloc.

Le contenu devient alors accessible sous :

/mnt/iso

Une image ISO classique étant normalement destinée à être lue, le montage en lecture seule est parfaitement naturel.

Voir les loop devices

losetup -a

Vous pourrez voir quelque chose comme :

/dev/loop0: (...) (/home/alice/debian.iso)

Votre fichier est devenu, pour quelques instants, suffisamment convaincant pour que Linux le traite comme un disque.

Monter un CD ou DVD

Lorsque le périphérique existe par exemple sous :

/dev/sr0

on peut faire :

sudo mkdir -p /mnt/cdrom
sudo mount /dev/sr0 /mnt/cdrom

On rencontre également parfois le lien :

/dev/cdrom

permettant :

sudo mount /dev/cdrom /mnt/cdrom

Les systèmes optiques modernes ne sont peut-être plus exactement au sommet de leur carrière, mais l’informatique d’entreprise dispose d’une remarquable capacité à maintenir en vie des supports que le grand public a oubliés depuis quinze ans.

Démonter un système de fichiers

La commande est :

umount

sans n.

Par exemple :

sudo umount /mnt/usb

ou :

sudo umount /dev/sdb1

Les deux approches fonctionnent lorsque l’identification du montage ne prête pas à confusion.

Pourquoi faut-il démonter proprement ?

Les écritures ne sont pas nécessairement envoyées immédiatement et physiquement au support.

Linux utilise des caches afin d’améliorer les performances.

Lorsque vous démontez proprement un système de fichiers, les données en attente sont synchronisées et les structures nécessaires sont finalisées.

Arracher une clé USB pendant une écriture n’est donc pas exactement équivalent à :

sudo umount /mnt/usb

Même si, physiquement, les deux opérations se terminent avec la clé sur votre bureau.

Forcer la synchronisation

La commande :

sync

demande notamment au noyau d’écrire les données mises en cache vers les systèmes de fichiers concernés.

Elle peut être utile dans certaines situations, mais ne remplace pas le démontage propre d’un support amovible.

« Target is busy » : quelqu’un refuse de sortir

Lors du démontage :

sudo umount /mnt/data

vous pouvez recevoir :

umount: /mnt/data: target is busy.

Cela signifie qu’un processus utilise toujours le système de fichiers.

Par exemple :

un fichier est ouvert ;
un programme travaille dans ce répertoire ;
un terminal possède son répertoire courant sous le point de montage ;
un service utilise des données présentes sur le volume.

Chercher les processus concernés avec fuser

sudo fuser -vm /mnt/data

Ou avec lsof

sudo lsof +f -- /mnt/data

Parfois, le coupable est tout simplement votre shell :

cd /mnt/data

Vous demandez ensuite à Linux de démonter le répertoire dans lequel vous vous trouvez.

Linux refuse.

Et pour une fois, il est difficile de lui reprocher son manque de coopération.

Le démontage paresseux : umount -l

L’option :

sudo umount -l /mnt/data

effectue un lazy unmount.

Le point de montage est détaché de l’arborescence immédiatement, tandis que les références encore utilisées seront nettoyées lorsqu’elles ne seront plus occupées.

Cela peut être utile dans certaines situations, notamment avec des ressources réseau problématiques.

Mais ce n’est pas une commande magique destinée à remplacer :

« Comprendre pourquoi le système de fichiers est encore utilisé. »

-l est un outil.

Pas un traitement contre l’impatience.

Voir ce qui est monté

La commande :

mount

sans argument affiche les montages connus.

Mais la sortie peut rapidement devenir assez spectaculaire sur un système moderne.

Une commande généralement plus pratique est :

findmnt

Chercher un montage précis

findmnt /srv/data

Afficher source, cible, type et options

findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS

Voir les systèmes de fichiers bloc

lsblk -f

Voir l’espace utilisé

df -hT

Ces outils répondent à des questions légèrement différentes :

Commande	Question
`lsblk`	Quels périphériques bloc et partitions existent ?
`findmnt`	Quels systèmes de fichiers sont montés et où ?
`df`	Quelle capacité est disponible sur les systèmes de fichiers montés ?
`blkid`	Quels UUID, labels et signatures possède le stockage ?

/etc/fstab : rendre un montage permanent

Un montage réalisé avec :

sudo mount /dev/sdb1 /srv/data

ne définit pas à lui seul un montage persistant après redémarrage.

Le fichier traditionnel permettant de décrire les systèmes de fichiers à monter est :

/etc/fstab

fstab signifie historiquement filesystem table.

Chaque ligne décrit normalement un système de fichiers.

Par exemple :

UUID=06fcb18d-7f20-42fe-bd31-15cbe73e11e0  /srv/data  ext4  defaults  0  2

Les six champs de fstab

Champ	Exemple	Rôle
1	`UUID=06fcb...`	Source du système de fichiers
2	`/srv/data`	Point de montage
3	`ext4`	Type du système de fichiers
4	`defaults`	Options de montage
5	`0`	Champ historique utilisé par dump
6	`2`	Ordre de vérification fsck au démarrage

Pourquoi utiliser UUID plutôt que /dev/sdb1 ?

On pourrait écrire :

/dev/sdb1  /srv/data  ext4  defaults  0  2

Mais les noms comme :

/dev/sda
/dev/sdb
/dev/sdc

dépendent de la détection des périphériques.

Un disque appelé sdb aujourd’hui pourrait éventuellement apparaître sous un autre nom après un changement de matériel ou d’ordre de détection.

Un UUID identifie le système de fichiers.

Pour l’obtenir :

sudo blkid /dev/sdb1

ou :

lsblk -f

Exemple :

/dev/sdb1: UUID="06fcb18d-7f20-42fe-bd31-15cbe73e11e0" TYPE="ext4"

Puis :

UUID=06fcb18d-7f20-42fe-bd31-15cbe73e11e0 /srv/data ext4 defaults 0 2

Pour les montages persistants de disques locaux, UUID est généralement préférable au nom /dev/sdX.

Les machines apprécient les identifiants de 36 caractères.

Les humains, curieusement, préfèrent sdb1.

Dans ce cas précis, la machine a probablement raison.

UUID, LABEL, PARTUUID et PARTLABEL

fstab peut utiliser plusieurs types d’identifiants.

Notation	Désigne
`UUID=...`	UUID du système de fichiers
`LABEL=DATA`	Label du système de fichiers
`PARTUUID=...`	Identifiant de la partition
`PARTLABEL=...`	Nom de partition, notamment avec GPT

Un reformatage crée normalement un nouvel UUID de système de fichiers.

Le PARTUUID peut rester inchangé tant que la partition elle-même n’est pas recréée.

Le sixième champ de fstab : 0, 1 ou 2 ?

Le dernier champ contrôle traditionnellement l’ordre de vérification par fsck.

Pour les systèmes de fichiers qui utilisent cette vérification :

0 : ne pas demander de vérification automatique via ce mécanisme ;
1 : normalement réservé au système de fichiers racine ;
2 : autres systèmes de fichiers devant être vérifiés.

On rencontre donc souvent :

UUID=...  /          ext4  defaults  0  1
UUID=...  /home      ext4  defaults  0  2
UUID=...  /srv/data  ext4  defaults  0  2

Mais tous les systèmes de fichiers ne fonctionnent pas de la même manière.

Par exemple, Btrfs n’utilise pas ce mécanisme comme ext4 et est généralement configuré avec un pass à 0.

Modifier fstab sans transformer le prochain redémarrage en surprise

Avant de modifier :

/etc/fstab

une sauvegarde ne coûte presque rien :

sudo cp /etc/fstab /etc/fstab.backup

Modifiez ensuite le fichier.

Sur un système Debian avec systemd, rechargez sa configuration :

sudo systemctl daemon-reload

Vérifier la syntaxe et la cohérence

Utilisez :

findmnt --verify

C’est aujourd’hui la méthode recommandée pour contrôler fstab.

Tester les montages

On utilise également couramment :

sudo mount -a

qui tente de monter les entrées de fstab concernées, à l’exception notamment de celles portant noauto.

Mais mount -a n’est pas un véritable validateur exhaustif de fichier fstab.

Pour contrôler le fichier lui-même :

findmnt --verify

est préférable.

Cette vérification est particulièrement recommandée avant de redémarrer un serveur situé à 500 kilomètres.

La qualité d’une configuration fstab est directement proportionnelle au coût du trajet nécessaire pour la réparer physiquement.

Les options de montage principales

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

Exemple :

UUID=... /srv/data ext4 defaults,noatime 0 2

defaults

defaults

demande les options considérées comme normales pour le système de fichiers et le noyau.

Ce n’est pas littéralement une macro universelle figée pour toujours : les valeurs par défaut dépendent aussi du noyau et du système de fichiers.

ro

ro

Monte en lecture seule.

rw

rw

Demande un montage en lecture/écriture.

C’est le comportement courant lorsqu’aucune restriction ne l’empêche.

noexec

noexec

empêche l’exécution directe de programmes depuis le montage via les mécanismes habituels.

Par exemple :

UUID=... /srv/uploads ext4 defaults,noexec 0 2

Attention toutefois :

noexec n’est pas une barrière de sécurité absolue.

Un script lisible peut par exemple être fourni explicitement à son interpréteur :

bash /srv/uploads/script.sh

Le fichier n’a alors pas besoin d’être exécuté directement.

noexec est donc une mesure de durcissement utile, mais pas une cape d’invisibilité magique contre le code malveillant.

nosuid

nosuid

désactive notamment l’effet des bits SUID et SGID sur les fichiers du montage.

Cette option est souvent utilisée sur des espaces dans lesquels des utilisateurs ou des données peu fiables peuvent créer des fichiers.

nodev

nodev

empêche l’interprétation de fichiers spéciaux comme périphériques sur le système de fichiers.

On rencontre souvent une combinaison de durcissement comme :

nodev,nosuid,noexec

sur certains volumes de données.

Selon l’usage, évidemment.

Mettre noexec sur un volume qui contient précisément les exécutables que vous devez lancer est une stratégie de sécurité d’une efficacité remarquable, principalement contre vous-même.

noatime

noatime

empêche la mise à jour de la date de dernier accès — atime — à chaque lecture.

Cela peut réduire certaines écritures.

Mais Linux utilise très couramment aujourd’hui relatime, qui limite déjà fortement les mises à jour d’atime.

noatime n’est donc plus l’optimisation miraculeuse que suggèrent certains tutoriels datant de l’époque où un disque dur de 80 Go représentait un patrimoine.

noauto

noauto

empêche le montage automatique par les mécanismes habituels comme mount -a au démarrage.

Le montage reste disponible manuellement.

nofail

nofail

indique qu’une absence ou un échec du périphérique ne doit pas être considéré comme suffisamment critique pour bloquer le démarrage normal.

C’est particulièrement utile pour :

un disque externe ;
un volume facultatif ;
une ressource qui n’est pas indispensable au fonctionnement du système.

Par exemple :

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

Votre ordinateur peut ainsi démarrer même si le disque « ARCHIVE » est resté sur le bureau du comptable.

Les options user et users

Par défaut, les montages système sont principalement une affaire de root.

Dans fstab, l’option :

user

peut permettre à un utilisateur non privilégié de monter une entrée donnée.

Par exemple :

UUID=... /mnt/usb exfat user,noauto 0 0

Les subtilités de user, users, propriétaire du montage et options de sécurité méritent toutefois d’être étudiées avant de transformer un serveur multi-utilisateur en atelier participatif de montage.

Monter par UUID directement

On peut aussi utiliser l’UUID en ligne de commande :

sudo mount UUID=06fcb18d-7f20-42fe-bd31-15cbe73e11e0 /mnt/data

ou le label :

sudo mount LABEL=DATA /mnt/data

Vous n’êtes donc pas obligé d’attendre fstab pour bénéficier d’identifiants persistants.

Montage NFS

NFS — Network File System permet de monter un système de fichiers exporté par une autre machine, très couramment entre systèmes Unix et Linux.

Sur Debian, installez les outils clients si nécessaire :

sudo apt install nfs-common

Créons le point de montage :

sudo mkdir -p /mnt/partage

Puis :

sudo mount -t nfs 192.168.0.42:/partage /mnt/partage

Ou avec un nom DNS :

sudo mount -t nfs nas.example.lan:/partage /mnt/partage

Le contenu distant apparaît alors exactement comme un répertoire local.

La latence réseau, elle, reste parfaitement consciente de la supercherie.

NFS dans fstab

Une entrée simple pourrait ressembler à :

nas.example.lan:/partage /srv/partage nfs defaults 0 0

Pour un montage réseau non essentiel, on peut envisager :

nas.example.lan:/partage /srv/partage nfs defaults,nofail,_netdev 0 0

_netdev

_netdev

indique explicitement que le montage dépend du réseau.

Systemd sait déjà reconnaître de nombreux systèmes de fichiers réseau à partir de leur type, mais _netdev reste utile lorsque cette dépendance ne peut pas être déduite naturellement.

Le message envoyé au système est essentiellement :

« N’essaie pas sérieusement de monter ceci avant d’avoir un réseau. »

Une précision qui semble évidente, mais que le démarrage parallèle moderne apprécie beaucoup.

Monter un partage SMB/CIFS

Pour accéder à un partage Windows ou Samba depuis Linux, on utilise généralement le système de fichiers CIFS.

Installez d’abord :

sudo apt install cifs-utils

Créez le point de montage :

sudo mkdir -p /mnt/partage

Puis :

sudo mount -t cifs //192.168.0.50/partage /mnt/partage -o username=alice

Si aucun mot de passe n’est fourni, l’outil peut le demander interactivement.

Évitez le mot de passe directement dans la commande

On voit fréquemment ceci :

sudo mount -t cifs //192.168.0.50/partage /mnt/partage -o username=alice,password=SuperSecret

Cela fonctionne.

Cela possède également quelques défauts :

le mot de passe peut finir dans l’historique du shell ;
il peut apparaître dans des scripts ;
il risque d’être copié dans de la documentation ou des tickets ;
et un secret écrit en clair finit souvent par développer une vie sociale étonnamment riche.

Utiliser un fichier de credentials

Créez par exemple :

sudo nano /root/.smb-credentials

Avec :

username=alice
password=SuperSecret
domain=EXEMPLE

Le champ domain n’est nécessaire que si votre environnement en a besoin.

Protégez ensuite le fichier :

sudo chmod 600 /root/.smb-credentials

Puis montez :

sudo mount -t cifs //192.168.0.50/partage /mnt/partage -o credentials=/root/.smb-credentials

Dans fstab

//192.168.0.50/partage /mnt/partage cifs credentials=/root/.smb-credentials,_netdev,nofail 0 0

C’est nettement préférable à :

password=monmotdepasse

dans /etc/fstab.

Un fichier protégé n’est évidemment pas une solution cryptographique miraculeuse, mais il évite au moins de tatouer le mot de passe au milieu de la configuration de montage.

Permissions CIFS : uid, gid, file_mode et dir_mode

Un partage SMB ne possède pas nécessairement la même représentation Unix des propriétaires et permissions que votre machine Linux.

On utilise parfois des options comme :

uid=1000,gid=1000,file_mode=0640,dir_mode=0750

Par exemple :

//serveur/partage /srv/share cifs credentials=/root/.smb-credentials,uid=1000,gid=1000,file_mode=0640,dir_mode=0750,_netdev 0 0

Ces options doivent être adaptées à l’architecture d’authentification du partage.

Ne remplacez donc pas systématiquement tous les UID par 1000 simplement parce que c’était le nombre utilisé dans le premier tutoriel Google.

Systemd et fstab

Sur Debian moderne, systemd transforme les entrées de /etc/fstab en unités de montage lors du démarrage.

Une entrée concernant :

/srv/data

correspond conceptuellement à une unité :

srv-data.mount

Vous pouvez l’observer avec :

systemctl status srv-data.mount

Il n’est pas nécessaire d’écrire manuellement ces unités pour les montages classiques : fstab reste généralement la méthode la plus pratique pour une configuration administrée par un humain.

x-systemd.automount : monter seulement lorsqu’on en a besoin

Systemd propose une option particulièrement intéressante :

x-systemd.automount

Elle demande la création d’une unité d’automontage.

Le système de fichiers n’est alors réellement monté que lorsqu’un processus tente d’accéder au point de montage.

Exemple NFS :

nas.example.lan:/partage /srv/partage nfs nofail,_netdev,x-systemd.automount 0 0

Cette approche possède plusieurs intérêts :

ne pas ralentir inutilement le démarrage ;
mieux gérer certains serveurs réseau temporairement indisponibles ;
monter la ressource seulement lorsqu’elle est réellement utilisée.

Au lieu de réveiller le NAS à chaque démarrage :

« Bonjour. Je n’ai besoin de rien, mais je voulais vérifier que vous étiez là. »

Linux attend que quelqu’un ait réellement besoin du partage.

Démonter automatiquement après une période d’inactivité

Avec systemd automount, on peut également utiliser un délai d’inactivité.

Par exemple :

x-systemd.automount,x-systemd.idle-timeout=10min

Une entrée pourrait devenir :

nas.example.lan:/partage /srv/partage nfs nofail,_netdev,x-systemd.automount,x-systemd.idle-timeout=10min 0 0

Après une période suffisante sans utilisation, systemd peut tenter de démonter la ressource.

Le partage réseau devient ainsi légèrement plus civilisé :

il vient quand on l’appelle et repart quand plus personne ne lui parle.

Montage bind : faire apparaître un répertoire ailleurs

Un montage ne doit pas nécessairement avoir un disque comme source.

Un bind mount permet de rendre un répertoire existant accessible à un second endroit.

Exemple :

sudo mkdir -p /srv/web/uploads
sudo mkdir -p /var/www/uploads

sudo mount --bind /srv/web/uploads /var/www/uploads

Les deux chemins montrent alors les mêmes fichiers.

Ce n’est pas une copie.

Ce n’est pas un lien symbolique.

C’est le même sous-arbre du système de fichiers exposé à un autre point de l’espace de noms.

Dans fstab

/srv/web/uploads /var/www/uploads none bind 0 0

Les bind mounts sont très utiles pour :

certaines architectures de services ;
des chroots ;
l’exposition contrôlée de répertoires ;
des conteneurs ;
et diverses situations où déplacer physiquement les données serait inutile.

Montage tmpfs : un système de fichiers temporaire en mémoire

Linux peut monter un système de fichiers tmpfs.

Les données résident alors dans la mémoire virtuelle du système et peuvent utiliser RAM et swap selon les circonstances.

Par exemple :

sudo mkdir -p /mnt/ram
sudo mount -t tmpfs -o size=1G tmpfs /mnt/ram

Vous obtenez un espace temporaire plafonné ici à 1 Gio.

Après démontage ou redémarrage :

les données ne sont pas conservées.

C’est important.

Le mot temporaire n’est pas une suggestion marketing.

Dans fstab

tmpfs /mnt/ram tmpfs defaults,size=1G 0 0

tmpfs est utile pour :

des fichiers temporaires ;
certains caches ;
des données éphémères ;
des environnements nécessitant beaucoup d’I/O temporaires.

Il est moins recommandé pour conserver l’unique exemplaire de la comptabilité annuelle.

Les pseudo-systèmes de fichiers

Tous les montages Linux ne correspondent pas à des disques.

Des éléments essentiels comme :

/proc
/sys
/dev

sont également associés à des systèmes de fichiers particuliers.

proc

/proc expose des informations sur les processus et le noyau.

sysfs

/sys expose notamment des informations sur les périphériques et le modèle interne du noyau.

devtmpfs

/dev contient les représentations de nombreux périphériques.

Ces systèmes de fichiers montrent bien que « monter » ne signifie pas simplement :

« Brancher un disque. »

Le mécanisme de montage structure une grande partie de l’espace de noms Linux lui-même.

Remonter un système de fichiers avec d’autres options

Il est parfois possible de changer certaines options sans démonter complètement.

Par exemple, remonter la racine en lecture/écriture :

sudo mount -o remount,rw /

Ou remonter un volume en lecture seule :

sudo mount -o remount,ro /srv/data

Les possibilités exactes dépendent du système de fichiers et des options concernées.

Toutes les propriétés d’un montage ne peuvent pas nécessairement être transformées à chaud simplement parce que l’option remount existe.

Les namespaces de montage : tout le monde ne voit pas forcément la même chose

Linux possède des mount namespaces.

Ils permettent à différents groupes de processus de disposer de vues différentes des montages.

Cette fonction est fondamentale pour :

les conteneurs ;
l’isolation de services ;
certaines fonctions de systemd ;
les technologies comme Docker, Podman ou LXC.

Ainsi, un système de fichiers peut être visible dans un espace de noms et pas dans un autre.

Lorsque vous commencez à déboguer un montage visible dans le shell mais absent d’un conteneur, vous venez d’entrer dans la partie du cours où l’arborescence elle-même cesse d’être une vérité universelle.

Les montages et les permissions Unix

Monter un système de fichiers ne signifie pas automatiquement que tous les utilisateurs peuvent y écrire.

Prenons :

sudo mount /dev/sdb1 /srv/data

Si la racine du système de fichiers appartient à :

root:root

avec des permissions :

un utilisateur ordinaire ne pourra probablement pas créer directement des fichiers à sa racine.

Pour ext4, XFS et autres systèmes de fichiers Unix, les propriétaires et permissions sont stockés dans le système de fichiers.

On peut par exemple créer un répertoire puis définir son propriétaire :

sudo mkdir /srv/data/alice
sudo chown alice:alice /srv/data/alice

Il ne faut donc pas confondre :

« le volume est monté » ;
« l’utilisateur possède les permissions nécessaires ».

Linux adore séparer les problèmes proprement afin de vous permettre d’en rencontrer plusieurs successivement.

FAT, exFAT et les permissions

FAT et exFAT ne possèdent pas le même modèle de permissions Unix qu’ext4.

Lors du montage, on utilise donc souvent des options comme :

uid=
gid=
umask=
fmask=
dmask=

Par exemple :

sudo mount -o uid=1000,gid=1000,umask=022 /dev/sdb1 /mnt/usb

Le système présente alors les fichiers avec les propriétaires et permissions correspondant aux options de montage.

On ne peut pas appliquer exactement la même logique qu’avec ext4 simplement parce que les fichiers apparaissent tous sous /mnt.

Monter automatiquement une clé USB ?

Sur un serveur, on choisit généralement explicitement ce qui doit être monté.

Sur un environnement graphique de bureau, des composants comme udisks et le gestionnaire de fichiers peuvent automatiquement monter des périphériques amovibles lorsque l’utilisateur les branche.

Vous pouvez donc parfaitement utiliser Linux pendant des années sans taper :

mount /dev/sdb1 ...

à chaque clé USB.

La commande reste toutefois indispensable dès qu’on administre des serveurs, des systèmes sans interface graphique ou des scénarios moins automatisés.

Un montage ne monte pas forcément une « partition »

Les sources de montage possibles sont nombreuses :

Source	Exemple
Partition physique	`/dev/sdb1`
Logical Volume LVM	`/dev/vgdata/lvbackup`
RAID logiciel	`/dev/md0`
Volume chiffré ouvert	`/dev/mapper/secret`
Image disque	`fichier.iso` via loop
NFS	`serveur:/export`
SMB/CIFS	`//serveur/partage`
Répertoire existant	bind mount
Mémoire	tmpfs

La commande mount est donc moins un « outil pour monter les partitions » qu’un outil permettant d’assembler l’espace de noms des systèmes de fichiers.

Attention aux supports suspects

Brancher un support inconnu et commencer immédiatement à explorer son contenu n’est pas forcément la meilleure idée.

Pour examiner un support non fiable, on peut envisager selon le contexte :

un montage en lecture seule ;
noexec ;
nosuid ;
nodev ;
une machine isolée ou un environnement prévu pour l’analyse.

Par exemple :

sudo mount -o ro,noexec,nosuid,nodev /dev/sdb1 /mnt/suspect

Encore une fois, ces options réduisent certains risques mais ne transforment pas le système de fichiers en objet inoffensif.

Des vulnérabilités peuvent exister dans des parseurs, systèmes de fichiers ou logiciels qui ouvrent les données.

Une clé USB trouvée sur le parking n’est pas un cadeau de bienvenue de l’équipe informatique.

Et si elle contient salaires_direction_2026.xlsx, c’est probablement encore moins bon signe.

Diagnostiquer un montage qui échoue

Vous lancez :

sudo mount /dev/sdb1 /mnt/data

et Linux refuse.

Quelques vérifications permettent de procéder proprement.

1. Le point de montage existe-t-il ?

ls -ld /mnt/data

Sinon :

sudo mkdir -p /mnt/data

2. Le périphérique existe-t-il ?

lsblk

3. Quel système de fichiers contient-il ?

lsblk -f /dev/sdb1

ou :

sudo blkid /dev/sdb1

4. Est-il déjà monté ?

findmnt -S /dev/sdb1

5. Le support du système de fichiers est-il disponible ?

Pour CIFS :

sudo apt install cifs-utils

Pour le client NFS :

sudo apt install nfs-common

Pour certains systèmes de fichiers, des outils supplémentaires peuvent également être nécessaires.

6. Que dit le noyau ?

Après un échec :

dmesg | tail -n 50

ou avec journalctl :

journalctl -k -n 50

Le noyau peut fournir des informations beaucoup plus précises qu’un simple :

« Ça ne marche pas. »

7. Pour une unité systemd

systemctl status srv-data.mount

et :

journalctl -u srv-data.mount

Cas pratique : monter durablement un nouveau disque ext4

Supposons qu’un disque possède une partition ext4 :

/dev/sdb1

1. Identifier le volume

lsblk -f

2. Créer le point de montage

sudo mkdir -p /srv/data

3. Tester manuellement

sudo mount /dev/sdb1 /srv/data

4. Vérifier

findmnt /srv/data

5. Trouver l’UUID

sudo blkid /dev/sdb1

Supposons :

UUID="06fcb18d-7f20-42fe-bd31-15cbe73e11e0"

6. Ajouter dans /etc/fstab

UUID=06fcb18d-7f20-42fe-bd31-15cbe73e11e0 /srv/data ext4 defaults 0 2

7. Recharger systemd

sudo systemctl daemon-reload

8. Vérifier fstab

findmnt --verify

9. Tester

sudo umount /srv/data
sudo mount /srv/data

Lorsque la source et les options figurent dans fstab, il suffit généralement de préciser le point de montage :

sudo mount /srv/data

10. Vérifier une dernière fois

findmnt /srv/data

À ce stade, le volume est configuré pour être monté automatiquement selon les règles de fstab.

Vous pouvez maintenant redémarrer avec un niveau d’anxiété raisonnable.

Cas pratique : partage NFS à la demande

Supposons :

nas.example.lan:/backups

à monter sous :

/srv/backups

Installation :

sudo apt install nfs-common
sudo mkdir -p /srv/backups

Test :

sudo mount -t nfs nas.example.lan:/backups /srv/backups

Puis fstab :

nas.example.lan:/backups /srv/backups nfs nofail,_netdev,x-systemd.automount,x-systemd.idle-timeout=10min 0 0

Rechargez :

sudo systemctl daemon-reload

Vérifiez :

findmnt --verify

Le partage pourra alors être monté à la demande lorsque quelque chose tente d’accéder à :

/srv/backups

Une solution souvent plus agréable qu’un démarrage bloqué pendant que le serveur attend désespérément un NAS actuellement redémarré pour mise à jour.

Cas pratique : partage SMB persistant

Installation :

sudo apt install cifs-utils

Point de montage :

sudo mkdir -p /srv/compta

Credentials :

sudo nano /root/.smb-compta

Contenu :

username=svc-linux
password=MotDePasse
domain=ENTREPRISE

Permissions :

sudo chmod 600 /root/.smb-compta

Test :

sudo mount -t cifs //fileserver/compta /srv/compta -o credentials=/root/.smb-compta

Puis :

//fileserver/compta /srv/compta cifs credentials=/root/.smb-compta,_netdev,nofail,x-systemd.automount 0 0

Enfin :

sudo systemctl daemon-reload
findmnt --verify

La comptabilité est désormais disponible via Linux.

La responsabilité de comprendre les fichiers Excel reste malheureusement hors du périmètre de mount.

Les erreurs classiques

« J’ai monté le disque mais je ne vois pas mes anciens fichiers du répertoire »

Le montage masque temporairement le contenu qui se trouvait déjà sous le point de montage.

Démontez pour le revoir.

« Mon utilisateur ne peut pas écrire sur le disque »

Vérifiez :

le type de système de fichiers ;
le propriétaire ;
les permissions ;
les ACL ;
et les options de montage.

mount rend le système de fichiers accessible.

Il ne distribue pas automatiquement les droits de propriété comme des confettis.

« Le disque ne revient pas après redémarrage »

Avez-vous configuré :

/etc/fstab

« Le serveur ne démarre plus normalement depuis que j’ai ajouté un disque USB »

Pour un stockage facultatif, vous auriez probablement apprécié :

nofail

« Mon partage réseau bloque le démarrage »

Examinez :

_netdev
nofail
x-systemd.automount

selon le besoin.

« J’ai mis le mot de passe SMB dans fstab »

Utilisez un fichier de credentials protégé.

Le mot de passe de production n’a pas besoin de devenir une décoration murale dans /etc/fstab.

« umount dit target is busy »

Cherchez le processus avant de sortir l’artillerie :

sudo fuser -vm /point/de/montage

« J’ai modifié fstab, je redémarre pour voir »

Non.

D’abord :

sudo systemctl daemon-reload
findmnt --verify

Puis testez le montage concerné.

Le redémarrage n’est pas un validateur syntaxique.

C’est simplement une manière très lente et très engageante de découvrir une faute de frappe.

Quelques commandes à retenir

Commande	Fonction
`lsblk -f`	Afficher périphériques, systèmes de fichiers, UUID et montages
`blkid`	Afficher les signatures et identifiants des systèmes de fichiers
`mount`	Monter un système de fichiers
`umount`	Démonter un système de fichiers
`findmnt`	Examiner les montages actifs
`findmnt --verify`	Vérifier la cohérence de fstab
`df -hT`	Voir espace et types des systèmes de fichiers montés
`mount -o ro`	Monter en lecture seule
`mount -o loop`	Monter une image via un loop device
`mount --bind`	Exposer un répertoire à un autre emplacement
`mount -t nfs`	Monter un partage NFS
`mount -t cifs`	Monter un partage SMB/CIFS
`fuser -vm`	Chercher les processus utilisant un montage
`systemctl daemon-reload`	Recharger notamment la configuration systemd après modification de fstab

Résumé : quelle commande pour quel besoin ?

Besoin	Exemple
Monter une partition	`mount /dev/sdb1 /mnt/data`
Monter en lecture seule	`mount -o ro /dev/sdb1 /mnt/data`
Monter une ISO	`mount -o loop,ro image.iso /mnt/iso`
Monter NFS	`mount -t nfs serveur:/partage /mnt/nfs`
Monter SMB	`mount -t cifs //serveur/partage /mnt/smb`
Monter un répertoire ailleurs	`mount --bind /source /destination`
Créer un montage temporaire en mémoire	`mount -t tmpfs tmpfs /mnt/ram`
Démonter	`umount /mnt/data`
Rendre permanent	`/etc/fstab`
Automonter à l’accès	`x-systemd.automount`

Conclusion : monter, c’est construire l’arborescence

Le montage sous Linux est beaucoup plus qu’une commande permettant d’accéder à une clé USB.

C’est l’un des mécanismes fondamentaux qui permettent de construire l’espace de fichiers visible par le système.

Un disque local peut apparaître sous :

/srv/data

un NAS sous :

/srv/backups

une image ISO sous :

/mnt/iso

et un répertoire existant peut être réexposé ailleurs grâce à un bind mount.

Pour l’utilisateur et les applications, tout cela forme pourtant une seule arborescence.

Les règles essentielles restent simples :

identifiez la source avant de la monter ;
choisissez un point de montage cohérent ;
utilisez UUID pour les volumes locaux persistants ;
utilisez des options adaptées aux ressources réseau ;
ne stockez pas les mots de passe SMB en clair dans les commandes ;
démontez proprement les supports ;
et vérifiez fstab avant de redémarrer.

Un bon montage est celui auquel personne ne pense.

Le disque est là, les applications trouvent leurs fichiers et le serveur démarre normalement.

Un mauvais montage, lui, se manifeste généralement à 3 h du matin sous la forme d’un service bloqué, d’un partage réseau inaccessible et d’un message :

Dependency failed for /srv/data

À cet instant, toute la philosophie Unix tient en une seule question :

« Mais qu’est-ce que j’ai encore mis dans fstab ? »

Montez proprement, vérifiez avant de redémarrer, et votre arborescence pourra continuer à prétendre que tous ces systèmes de fichiers différents ne forment qu’un seul monde cohérent.

Linux ne distribue pas de lettres. Il vous donne un arbre. Évitez simplement de scier la branche sur laquelle / est monté.

Post Views: 24