Provided by: manpages-fr-dev_4.25.1-1_all 
NOM
mount - Monter un système de fichiers
BIBLIOTHÈQUE
Bibliothèque C standard (libc, -lc)
SYNOPSIS
#include <sys/mount.h>
int mount(const char *source, const char *target,
const char *filesystemtype, unsigned long mountflags,
const void *_Nullable data);
DESCRIPTION
mount() attache le système de fichiers indiqué par source (qui est généralement un nom de périphérique,
mais peut aussi être un répertoire ou un objet fictif) à un emplacement (un répertoire ou un fichier)
indiqué par le chemin dans target.
Des privilèges appropriés (sous Linux : la capacité CAP_SYS_ADMIN) sont nécessaires pour monter des
systèmes de fichiers.
Les valeurs de l'argument filesystemtype prises en charge par le noyau sont listées dans
/proc/filesystems (par exemple « btrfs » « ext4 », « jfs », « xfs », « vfat », « fuse », « tmpfs »,
« cgroup », « proc », « mqueue », « nfs », « fifs », « iso9660 »). Des types supplémentaires peuvent être
disponibles lorsque les modules appropriés sont chargés.
L'argument data est interprété différemment suivant le type de système de fichiers. Généralement, c'est
une chaîne d'options comprises par le système de fichiers, séparées par des virgules. Consultez mount(8)
pour des détails sur les options disponibles pour chaque type de système de fichiers. Ce paramètre peut
valoir NULL s'il n'y a pas d'option.
Un appel à mount() effectue un des nombreux types généraux d'opération en fonction des bits indiqués dans
mountflags. Le choix de l'opération à effectuer se fait en testant l'ensemble de bits mountflags, les
tests étant menés dans l'ordre indiqué ici :
- Remonter un montage existant : mountflags inclut MS_REMOUNT.
- Créer un montage miroir : mountflags inclut MS_BIND.
- Modifier le type de propagation d'un montage existant : mountflags inclut MS_SHARED, MS_PRIVATE,
MS_SLAVE ou MS_UNBINDABLE.
- Déplacer un point de montage existant vers un nouvel endroit : mountflags inclut MS_MOVE.
- Créer un nouveau montage : mountflags n'inclut aucun des attributs ci-dessus.
Chacune de ces opérations est détaillée plus tard dans cette page. D'autres attributs peuvent être
indiqués dans mountflags pour modifier le comportement de mount(), comme décrits ci-dessous.
Attributs de montage supplémentaires
La liste ci-dessous décrit les attributs supplémentaires qui peuvent être indiqués dans mountflags.
Remarquez que certains types d'opération ignorent tout ou partie de ces autres attributs, comme décrit
plus loin dans cette page.
MS_DIRSYNC (depuis Linux 2.5.19)
Rendre synchrones les modifications sur les répertoires du système de fichiers. (Cette propriété
peut être obtenue pour les répertoires individuels ou les sous‐arborescences en utilisant
chattr(1).)
MS_LAZYTIME (depuis Linux 4.0)
Réduire les mises à jour sur disque des horodatages d'inœuds (atime, mtime, ctime) en gardant
seulement en mémoire ces changements. Les horodatages sur le disque sont mis à jour quand :
- l'inœud doit être mis à jour pour certains changements non liés aux horodatages du fichier ;
- l'application utilise fsync(2), syncfs(2) ou sync(2) ;
- un inœud non effacé est évincé de la mémoire ;
- plus de 24 heures sont passées depuis que l'inœud a été écrit sur le disque.
Cette option de montage réduit significativement les écritures nécessaires pour mettre à jour les
horodatages de l'inœud, surtout mtime et atime. Cependant, si un système plante, les champs atime
et mtime du disque pourraient être périmés jusqu'à un maximum de 24 heures.
Parmi les exemples de charge de travail où cette option peut représenter un grand intérêt, on
trouve les écritures aléatoires fréquentes dans des fichiers préalloués, ainsi que les cas où
l'option de montage MS_STRICTATIME est également activée (l'avantage de combiner MS_STRICTATIME et
MS_LAZYTIME est que stat(2) renverra l'atime correctement mis à jour, mais les mises à jour atime
ne seront envoyées sur le disque que dans les cas listés ci-dessus).
MS_MANDLOCK
Autoriser les verrouillages impératifs sur les fichiers de ce système de fichiers (le verrouillage
impératif devra toutefois être validé fichier par fichier, comme décrit dans fcntl(2)). Depuis
Linux 4.5, cette option de montage exige la capacité CAP_SYS_ADMIN et un noyau configuré avec
l'option CONFIG_MANDATORY_FILE_LOCKING. Le verrouillage impératif est complètement obsolète depuis
Linux 5.15, cet attribut devrait donc être considéré comme tel.
MS_NOATIME
Ne pas mettre à jour les dates d'accès pour (tous) les fichiers du système de fichiers.
MS_NODEV
Ne pas autoriser l’accès aux périphériques (fichiers spéciaux) sur le système de fichiers.
MS_NODIRATIME
Ne pas mettre à jour les dates d'accès pour les répertoires du système de fichiers. Cet attribut
fournit un sous-ensemble de la fonctionnalité fournie par MS_NOATIME ; c'est-à-dire, MS_NOATIME
implique MS_NODIRATIME.
MS_NOEXEC
Ne pas permettre l'exécution de programmes depuis le système de fichiers.
MS_NOSUID
Ne pas honorer les bits set-user-ID et set-group-ID ou les capacités de fichier lorsque des
programmes s'exécutent à partir de ce système de fichiers. En outre, les transitions de domaine
SELinux exigent le droit nosuid_transition, qui doit à son tour avoir la capacité
nnp_nosuid_transition.
MS_RDONLY
Monter le système de fichiers en lecture seule.
MS_REC (depuis Linux 2.4.11)
Utilisé avec MS_BIND pour créer un montage miroir récursif, et ajouté aux attributs de type de
propagation, pour modifier récursivement le type de propagation de tous les montages d'une
sous-arborescence. Voir ci-dessous pour plus de détails.
MS_RELATIME (depuis Linux 2.6.20)
Lorsqu'un fichier sur ce système de fichiers est utilisé, ne mettre à jour sa date d'accès (atime)
que si la valeur actuelle de atime est inférieure ou égale à sa date de dernière modification
(mtime) ou de changement d'état (ctime). Cette option est utile pour les programmes tels que
mutt(1) qui veulent savoir si un fichier a été lu depuis sa dernière modification. Depuis
Linux 2.6.30, les noyaux suivent le comportement fourni par cet attribut (à moins que MS_NOATIME
soit indiqué), et l’attribut MS_STRICTATIME est nécessaire pour avoir la sémantique
traditionnelle. De plus, depuis Linux 2.6.30, la date du dernier accès à un fichier est toujours
mise à jour s'il est plus ancien qu'un jour.
MS_SILENT (depuis Linux 2.6.17)
Supprimer l'affichage de certains messages d'avertissement (printk()) dans le journal noyau. Cet
attribut remplace l'attribut MS_VERBOSE qui avait un mauvais nom et est obsolète (il était
disponible depuis Linux 2.4.12), et qui a la même signification.
MS_STRICTATIME (depuis Linux 2.6.30)
Toujours mettre à jour la date du dernier d'accès (atime) lorsque des fichiers sur le système de
fichiers sont lus (c'était le comportement par défaut avant Linux 2.6.30). Indiquer cet attribut
annule l'effet des attributs MS_NOATIME et MS_RELATIME.
MS_SYNCHRONOUS
Rendre synchrones les écritures sur le système de fichiers (comme si l'option O_SYNC de open(2)
était indiquée à chaque appel sur ce système de fichiers).
MS_NOSYMFOLLOW (depuis Linux 5.10)
Ne pas suivre les liens symboliques lors de la résolution des chemins. Des liens symboliques
peuvent toujours être créés et readlink(1), readlink(2), realpath(1) ainsi que realpath(3)
fonctionneront encore correctement.
De Linux 2.4 jusqu'à aujourd'hui, certains des attributs ci-dessus sont positionnables sur une base par
montage, tandis que d'autres s'appliquent au superbloc du système de fichier monté, ce qui veut dire que
tous les montages du même système de fichiers partagent ces attributs (précédemment, tous les attributs
étaient sur une base par superbloc).
Les attributs par point de montage sont les suivants :
- Depuis Linux 2.4 : les attributs MS_NODEV, MS_NOEXEC et MS_NOSUID sont positionnables sur une base par
point de montage.
- En outre, depuis Linux 2.6.20 : MS_RELATIME et MS_NODIRATIME.
- De plus, depuis Linux 2.6.20 : MS_RELATIME.
Les attributs suivants fonctionnent par superbloc : MS_DIRSYNC, MS_LAZYTIME, MS_MANDLOCK, MS_SILENT et
MS_SYNCHRONOUS. Les réglages initiaux de ces attributs sont déterminés lors du premier montage du système
de fichiers et seront partagés par tous les montages suivants du même système de fichiers. Par
conséquent, les réglages des attributs peuvent être modifiés à l'aide d'une opération de remontage (voir
ci-dessous). De telles modifications seront visibles à l'aide de tous les points de montage associés au
système de fichiers.
Depuis Linux 2.6.16, MS_RDONLY peut être positionné ou effacé sur une base par point de montage ou par
superbloc du système de fichiers sous-jacent. Le système de fichiers monté ne sera accessible en écriture
que si ni lui, ni le point de montage, n'ont l’attribut de lecture seule.
Remontage d'un montage existant
Un montage existant peut être remonté en utilisant MS_REMOUNT dans mountflags. Cela permet de modifier
mountflags et data du montage existant sans être obligé de démonter et de remonter le système de
fichiers. target devrait valoir la même valeur que celle indiquée dans l'appel mount() initial.
Les arguments source et filesystemtype sont ignorés.
Les arguments mountflags et data devraient correspondre aux valeurs utilisées dans l'appel mount()
originel, sauf ceux qui seront délibérément modifiés.
Les mountflags suivants peuvent être modifiés : MS_LAZYTIME, MS_MANDLOCK, MS_NOATIME, MS_NODEV,
MS_NODIRATIME, MS_NOEXEC, MS_NOSUID, MS_RELATIME, MS_RDONLY, MS_STRICTATIME (dont l'effet est de vider
les attributs MS_NOATIME et MS_RELATIME) et MS_SYNCHRONOUS. Les tentatives de modification des attributs
MS_DIRSYNC et MS_SILENT lors d'un remontage sont ignorées silencieusement. Remarquez que les
modifications d'attributs par superbloc se voient à travers les montages de tous les systèmes de fichiers
associés (parce que l'attribut par superbloc est partagé par tous les montages).
Depuis Linux 3.17, si ni MS_NOATIME, ni MS_NODIRATIME, ni MS_RELATIME, ni MS_STRICTATIME n'est indiqué
dans mountflags, l'opération de remontage préserve les valeurs existantes de ces attributs (au lieu de
revenir à MS_RELATIME par défaut).
Depuis Linux 2.6.26, l'attribut MS_REMOUNT peut être utilisé avec MS_BIND pour ne modifier que les
attributs sur la base des points de montage. Cela est particulièrement utile pour positionner ou effacer
l'attribut « read-only » d'un montage sans modifier le système de fichiers sous-jacent. Si on indique
mountflags ainsi :
MS_REMOUNT | MS_BIND | MS_RDONLY
donnera accès à ce point de montage en lecture seule, sans modifier les autres montages.
Créer un montage miroir
Si mountflags comprend MS_BIND (disponible depuis Linux 2.4), effectuer un montage miroir. Un montage
miroir rend visible un fichier ou la sous-arborescence d'un répertoire à un autre endroit d'une même
hiérarchie de répertoires. Les montages miroir peuvent franchir les limites du système de fichiers et
outrepasser les verrous chroot(2).
Les paramètres filesystemtype et data sont ignorés.
Les autres bits (sauf MS_REC décrit ci-dessous) du paramètre mountflags sont ignorés également (le
montage miroir a les mêmes options de montage que celui sous-jacent). Cependant, consultez le point sur
le remontage ci-dessus pour une méthode permettant de rendre un montage miroir en lecture seule.
Par défaut, quand un répertoire est monté en miroir, seul ce répertoire est monté ; s'il y a des
sous-montages dans l'arborescence de répertoires, ils ne sont pas montés en miroir. Si l'attribut MS_REC
est indiqué également, une opération de montage miroir récursif est effectuée : tous les sous-montages de
la sous-arborescence de source (sauf les montages qu'il n'est pas possible de monter en miroir) sont
également montés en miroir à l'endroit correspondant dans la sous-arborescence target.
Modifier le type de propagation d'un montage existant
Si mountflags comprend MS_SHARED, MS_PRIVATE, MS_SLAVE ou MS_UNBINDABLE (disponibles depuis
Linux 2.6.15), le type de propagation d'un montage existant est modifié. Si plus d'un de ces attributs
est indiqué, cela provoque une erreur.
Les seuls autres attributs qui peuvent être indiqués pendant un changement de type de propagation sont
MS_REC (décrit ci-dessous) et MS_SILENT (qui est ignoré).
Les paramètres source, filesystemtype et data sont ignorés.
Voici la signification des attributs de types de propagation :
MS_SHARED
Rendre le montage partagé. Les événements de montage et de démontage se produisant immédiatement
dans ce montage seront propagés à tous les montages membres de ce groupe de montages pairs. Une
propagation signifie ici que le même montage et le même démontage se produiront automatiquement
sur tous les montages du groupe. Inversement, les événements de montage et de démontage qui se
produiront dans les montages pairs se propageront à ce montage.
MS_PRIVATE
Rendre ce point de montage privé. Les événements de montage et de démontage ne se propageront pas
à ce montage ou à d'autres.
MS_SLAVE
S'il s'agit d'un montage partagé membre d'un groupe de pairs qui contient d'autres membres, le
convertir en montage esclave. S'il s'agit d'un montage partagé membre d'un groupe qui n'en
contient pas d'autres, le convertir en montage privé. Sinon, le type de propagation du montage est
inchangé.
Lorsqu'un montage est esclave, les événements de montage et de démontage se propagent à ce montage
depuis le groupe de pairs partagé (maître) dont il était membre. Les événements de montage et de
démontage de ce montage ne se propagent à aucun autre pair.
Un montage peut être esclave d'un autre groupe de pairs en même temps qu'il partage les événements
de montage et de démontage avec un autre groupe de pairs dont il est membre.
MS_UNBINDABLE
Rendre impossible un montage en miroir. C'est comme un montage privé mais en plus, il n'est pas
possible de monter ce montage en miroir. Quand un montage miroir (mount() avec les attributs
MS_BIND et MS_REC) récursif est effectué dans une sous-arborescence de répertoire, tous les points
de montage qu'il n'est pas possible de monter en miroir dans la sous-arborescence sont
automatiquement éliminés (c'est-à-dire non répliqués) lors de la réplication de cette
sous-arborescence pour générer la sous-arborescence cible.
Par défaut, la modification du type de propagation ne concerne que le montage target. Si l'attribut
MS_REC est aussi indiqué dans mountflags, le type de propagation de tous les montages de target est aussi
modifié.
Pour plus de détails sur les types de propagation des montages (notamment celui par défaut affecté aux
nouveaux montages), voir mount_namespaces(7).
Déplacer un montage
Si mountflags contient l'attribut MS_MOVE (disponible depuis linux 2.4.18), déplacer une
sous-arborescence : source indiquant un montage existant et target le nouvel emplacement où replacer le
point de montage. Le déplacement est atomique : à aucun moment la sous-arborescence n'est démontée.
Les autres bits du paramètre mountflags sont ignorés, ainsi que les paramètres filesystemtype et data.
Créer un nouveau montage
Si ni MS_REMOUNT, ni MS_BIND, ni MS_MOVE, ni MS_SHARED, ni MS_PRIVATE, ni MS_SLAVE ou ni MS_UNBINDABLE ne
sont indiqués dans mountflags, mount() opère son action par défaut : créer un nouveau montage. source
indique la source du nouveau montage et target indique le répertoire où créer le point de montage.
Les paramètres filesystemtype et data sont utilisés et d'autres bits peuvent être indiqués dans
mountflags pour modifier le comportement de l'appel.
VALEUR RENVOYÉE
En cas de succès, zéro est renvoyé. En cas d'erreur, -1 est renvoyé et errno est définie pour préciser
l'erreur.
ERREURS
Les erreurs détaillées ici sont indépendantes du type de système de fichiers. Chaque type de système peut
avoir des codes d'erreurs spécifiques, et un comportement particulier. Consultez les sources du noyau
Linux pour plus de détails.
EACCES Un élément du chemin d'accès ne permet pas le parcours (consultez aussi path_resolution(7)).
EACCES Le montage d'un système de fichiers en lecture seule a été tenté sans donner l'attribut MS_RDONLY.
Le système de fichiers peut être en lecture seule pour diverses raisons, dont : il réside sur un
disque optique en lecture seule ; il se trouve sur un périphérique possédant un commutateur
physique positionné sur lecture seule ; l'implémentation du système de fichiers a été compilée
avec la prise en charge de la lecture seulement ; ou des erreurs ont été détectées lors du montage
initial du système de fichiers. Il est donc marqué en lecture seule et ne peut pas être remonté en
lecture-écriture (jusqu'à ce que les erreurs soient corrigées).
Certains systèmes de fichiers renvoient plutôt l'erreur EROFS si on essaie de monter un système de
fichiers en lecture seule.
EACCES Le périphérique bloc source se trouve sur un système de fichiers monté avec l'option MS_NODEV.
EBUSY Tentative d'empiler un nouveau montage directement sur un point de montage existant créé dans cet
espace de noms montage avec la même source et la même target.
EBUSY source ne peut pas être remonté en lecture seule car il a encore des fichiers ouverts en écriture.
EFAULT L'un des arguments pointe en dehors de l'espace d'adressage accessible.
EINVAL source avait un superbloc non valable.
EINVAL Tentative d'une opération de remontage (MS_REMOUNT) mais source n'était pas déjà monté sur target.
EINVAL Tentative d'une opération de déplacement (MS_MOVE), mais l'arborescence de montage sous source
comprend des montages impossibles à monter en miroir et target est un montage dont le type de
propagation est MS_SHARED.
EINVAL Tentative d'une opération de déplacement (MS_MOVE), mais le montage parent du montage source a un
type de propagation MS_SHARED.
EINVAL Tentative d'opération de déplacement (MS_MOVE) mais source n'était pas un montage ou il valait
« / ».
EINVAL Une opération miroir (MS_BIND) a été demandée alors que source renvoyait à un lien magique
d'espace de noms de montage (c'est-à-dire à un lien magique /proc/pid/ns/mnt ou à un montage
miroir vers un tel lien) et le type de propagation du montage parent de target était MS_SHARED,
mais la propagation du montage miroir demandée créerait une dépendance circulaire qui pourrait
empêcher l'espace de noms de montage d'être libéré.
EINVAL mountflags comprend plus d'un MS_SHARED, MS_PRIVATE, MS_SLAVE ou MS_UNBINDABLE.
EINVAL mountflags comprend un MS_SHARED, MS_PRIVATE, MS_SLAVE ou MS_UNBINDABLE ainsi qu'un autre attribut
que MS_REC ou MS_SILENT.
EINVAL Tentative de monter en miroir un montage impossible à monter ainsi.
EINVAL Dans un espace de noms montage non privilégié (c'est-à-dire appartenant à un espace de noms
utilisateur créé par un utilisateur non privilégié), tentative d'opération de montage en miroir
(MS_BIND) sans indiquer MS_REC, qui aurait révélé une arborescence de système de fichiers
en-dessous d'un des sous-montages du répertoire à refléter.
ELOOP Trop de liens rencontrés dans la résolution du chemin d'accès.
ELOOP Tentative d'une opération de déplacement ou target est un descendant de source.
EMFILE (Dans le cas où un périphérique bloc n'est pas nécessaire :) Table de périphériques factices
pleine.
ENAMETOOLONG
Un des arguments est plus long que MAXPATHLEN.
ENODEV filesystemtype n'est pas configuré dans le noyau.
ENOENT Un des chemins est vide ou a un composant inexistant.
ENOMEM Le noyau n'a pas pu allouer suffisamment de mémoire.
ENOTBLK
source n'est pas un périphérique bloc (et un périphérique était nécessaire).
ENOTDIR
target ou un préfixe de source n'est pas un répertoire.
ENXIO Le nombre majeur du périphérique bloc source est non autorisé.
EPERM L'appelant n'a pas les privilèges appropriés.
EPERM Tentative de modifier (MS_REMOUNT) l'attribut MS_RDONLY, MS_NOSUID ou MS_NOEXEC ou un des
attributs « atime » (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) d'un montage existant mais le montage
est verrouillé ; voir mount_namespaces(7).
EROFS Tentative de montage d'un système de fichiers en lecture seule sans donner l'attribut MS_RDONLY.
Voir EACCES ci-dessus.
STANDARDS
Linux.
HISTORIQUE
Les définitions de MS_DIRSYNC, MS_MOVE, MS_PRIVATE, MS_REC, MS_RELATIME, MS_SHARED, MS_SLAVE,
MS_STRICTATIME et MS_UNBINDABLE ont été ajoutées aux en-têtes de la glibc depuis la version 2.12.
Depuis Linux 2.4 un même système de fichiers peut être visible en différents points, et plusieurs
montages peuvent être empilés au même point.
L'argument mountflags peut avoir le nombre magique 0xC0ED (MS_MGC_VAL) dans ses 16 bits de poids fort
(tous les autres attributs abordés dans DESCRIPTION sont dans les 16 bits de poids faible de mountflags).
L'indication de MS_MGC_VAL était obligatoire dans les noyaux des versions antérieure à 2.4, mais depuis
ne l'est plus et est ignoré si vous le faites.
L'attribut original MS_SYNC a été renommé MS_SYNCHRONOUS dans Linux 1.1.69 car un MS_SYNC différent a été
ajouté dans <mman.h>.
Avant Linux 2.4, une tentative d'exécution d'un programme Set-UID ou Set-GID sur un système de fichiers
monté avec l'attribut MS_NOSUID échouait avec l'erreur EPERM. Depuis Linux 2.4 les bits Set-UID et
Set-GID sont simplement ignorés silencieusement dans ce cas.
NOTES
Espaces de noms montage
À partir du noyau 2.4.19, Linux fournit des espaces de noms montage. Un espace de noms montage est un
ensemble de montages de systèmes de fichiers qui sont visibles par un processus. Les espaces de noms
montage peuvent être (ils le sont généralement) partagés entre différents processus et les modifications
de l'espace de noms (c'est-à-dire les montages et démontages) par un processus sont visibles pour tous
les autres processus qui partagent le même espace de noms (la situation des versions antérieures à 2.4.19
de Linux peut être considérée comme l'utilisation d'un unique espace de noms partagé par tous les
processus du système).
Un processus enfant créé avec fork(2) partage l'espace de noms montage de son parent ; l'espace de noms
montage est préservé au travers d'un execve(2).
Un processus peut obtenir un espace de noms montage privé si : il a été créé en utilisant l'attribut
CLONE_NEWNS de clone(2), dans ce cas son nouvel espace de noms est initialisé comme une copie de l'espace
de noms du processus qui a appelé clone(2) ; ou il appelle unshare(2) avec l'attribut CLONE_NEWNS, ce qui
provoque l'obtention d'une copie privée de l'environnement de l'appelant, qui était auparavant partagé
avec d'autres processus, de telle sorte que les montages ou démontages futurs de l'appelant ne seront pas
visibles des autres processus (à l'exception des processus enfants que le processus pourrait créer), et
vice-versa.
Pour plus de détails sur les espaces de noms montage, voir mount_namespaces(7).
Relation de parenté entre les montages
Chaque montage a un montage parent. La relation de parenté entre tous les montages définit la seule
hiérarchie de répertoires que voient les processus à l'intérieur d'un espace de noms montage.
Le parent d'un nouveau montage est défini quand le montage est créé. En général, le parent d'un nouveau
montage est le montage du système de fichiers qui contient le répertoire ou le fichier sur lequel est
rattaché le montage. Si un nouveau montage est empilé sur un montage existant, le parent du nouveau
montage est le montage précédent empilé à cet endroit.
La relation de parenté entre les montages peut être examinée dans le fichier /proc/pid/mountinfo (voir
ci-dessous).
/proc/pid/mounts et /proc/pid/mountinfo
Le fichier /proc/pid/mounts spécifique à Linux présente la liste des montages dans l'espace de noms
montage du processus ayant l'identifiant indiqué. Le fichier /proc/pid/mountinfo présente encore plus
d'informations sur les montages, notamment le type de propagation et les informations d'identification du
montage, ce qui permet de visualiser la relation de parenté entre les montages. Voir proc(5) et
mount_namespaces(7) pour plus de détails sur ce fichier.
VOIR AUSSI
mountpoint(1), chroot(2), FS_IOC_SETFLAGS(2const), mount_setattr(2), pivot_root(2), umount(2), mount_namespaces(7), path_resolution(7), findmnt(8), lsblk(8), mount(8), umount(8)
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud
<tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard
<fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau
<jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François
<nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard
<simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot
<david@tilapin.org> et Jean-Philippe MENGUAL <jpmengual@debian.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License
version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ concernant les conditions de copie et de
distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à
⟨debian-l10n-french@lists.debian.org⟩.