Une monture liée ?

Qu'est-ce qu'un "montage lié" ? Comment en faire un ? À quoi ça sert ?

On m'a dit d'utiliser une monture de liaison pour quelque chose, mais je ne comprends pas ce que c'est ni comment l'utiliser.

Réponse acceptée :

Qu'est-ce qu'un montage lié ?

Une monture liée est une autre vue d'une arborescence de répertoires. Classiquement, le montage crée une vue d'un périphérique de stockage sous la forme d'une arborescence de répertoires. Un montage lié prend à la place une arborescence de répertoires existante et la réplique sous un point différent. Les répertoires et les fichiers du montage lié sont les mêmes que ceux d'origine. Toute modification d'un côté est immédiatement répercutée sur l'autre côté, puisque les deux vues affichent les mêmes données.

Par exemple, après avoir émis la commande Linux-

mount --bind /some/where /else/where

les répertoires /some/where et /else/where ont le même contenu, qui est le contenu de /some/where . (Si /else/where n'était pas vide, son contenu précédent est maintenant masqué.)

Contrairement à un lien physique ou à un lien symbolique, un montage lié n'affecte pas ce qui est stocké sur le système de fichiers. C'est une propriété du système en direct.

Comment créer un montage lié ?

bindfs

Le bindfs filesystem est un système de fichiers FUSE qui crée une vue d'une arborescence de répertoires. Par exemple, la commande

bindfs /some/where /else/where

rend /else/where un point de montage sous lequel le contenu de /some/where sont visibles.

Puisque bindfs est un système de fichiers séparé, les fichiers /some/where/foo et /else/where/foo apparaissent comme des fichiers différents pour les applications (le système de fichiers bindfs a son propre st_dev valeur). Tout changement d'un côté est "magiquement" reflété de l'autre côté, mais le fait que les fichiers sont les mêmes n'est apparent que lorsque l'on sait comment fonctionne bindfs.

Bindfs n'a aucune connaissance des points de montage, donc s'il y a un point de montage sous /some/where , il apparaît comme un autre répertoire sous /else/where . Monter ou démonter un système de fichiers sous /some/where apparaît sous /else/where comme un changement du répertoire correspondant.

Bindfs peut modifier certaines des métadonnées des fichiers :il peut afficher de fausses autorisations et la propriété des fichiers. Voir le manuel pour plus de détails et voir ci-dessous pour des exemples.

Un système de fichiers bindfs peut être monté en tant qu'utilisateur non root, vous n'avez besoin que du privilège pour monter les systèmes de fichiers FUSE. Selon votre distribution, cela peut nécessiter d'être dans le fuse groupe ou être autorisé à tous les utilisateurs. Pour démonter un système de fichiers FUSE, utilisez fusermount -u au lieu de umount , par exemple

fusermount -u /else/where

nullfs

FreeBSD fournit le nullfs système de fichiers qui crée une vue alternative d'un système de fichiers. Les deux commandes suivantes sont équivalentes :

mount -t nullfs /some/where /else/where
mount_nullfs /some/where /else/where

Après avoir émis l'une ou l'autre des commandes, /else/where devient un point de montage auquel le contenu de /some/where sont visibles.

Puisque nullfs est un système de fichiers séparé, les fichiers /some/where/foo et /else/where/foo apparaissent comme des fichiers différents pour les applications (le système de fichiers nullfs a son propre st_dev valeur). Tout changement d'un côté est "magiquement" reflété de l'autre côté, mais le fait que les fichiers soient identiques n'est apparent que lorsque l'on sait comment fonctionne nullfs.

Contrairement au bindfs FUSE, qui agit au niveau de l'arborescence des répertoires, le nullfs de FreeBSD agit plus profondément dans le noyau, donc les points de montage sous /else/where ne sont pas visibles :uniquement l'arborescence qui fait partie du même point de montage que /some/where est reflété sous /else/where .

Le système de fichiers nullfs peut être utilisable sous d'autres variantes de BSD (OS X, OpenBSD, NetBSD), mais il n'est pas compilé dans le cadre du système par défaut.

Montage de liaison Linux

Sous Linux, les montages liés sont disponibles en tant que fonctionnalité du noyau. Vous pouvez en créer un avec le mount commande, en passant soit la commande --bind l'option de ligne de commande ou l'option bind option de montage. Les deux commandes suivantes sont équivalentes :

mount --bind /some/where /else/where
mount -o bind /some/where /else/where

Ici, le "device" /some/where n'est pas une partition de disque comme dans le cas d'un système de fichiers sur disque, mais un répertoire existant. Le point de montage /else/where doit être un répertoire existant comme d'habitude. Notez qu'aucun type de système de fichiers n'est spécifié dans les deux cas :faire un montage lié n'implique pas de pilote de système de fichiers, il copie les structures de données du noyau à partir du montage d'origine.

mount --bind prend également en charge le montage d'un non-répertoire sur un non-répertoire :/some/where peut être un fichier normal (auquel cas /else/where doit également être un fichier normal).

Un montage de liaison Linux est généralement impossible à distinguer de l'original. La commande df -T /else/where affiche le même périphérique et le même type de système de fichiers que df -T /some/where . Les fichiers /some/where/foo et /else/where/foo sont indiscernables, comme s'il s'agissait de liens physiques. Il est possible de démonter /some/where , auquel cas /else/where reste monté.

Avec les noyaux plus anciens (je ne sais pas exactement quand, je pense jusqu'à une version 3.x), les montages liés étaient vraiment impossibles à distinguer de l'original. Les noyaux récents suivent les montages liés et exposent les informations via PID /mountinfo, qui permet findmnt pour indiquer le montage lié en tant que tel.

 
 Vous pouvez mettre des entrées de montage liées dans /etc/fstab . Incluez simplement bind (ou rbind etc.) dans les options, ainsi que toutes les autres options souhaitées. Le « périphérique » est l'arborescence existante. La colonne filesystem peut contenir none ou bind (il est ignoré, mais utiliser un nom de système de fichiers serait source de confusion). Par exemple :
 /some/where /readonly/view none bind,ro
 
 S'il y a des points de montage sous /some/where , leur contenu n'est pas visible sous /else/where . Au lieu de bind , vous pouvez utiliser rbind , répliquez également les points de montage sous /some/where . Par exemple, si /some/where/mnt est un point de montage alors
 mount --rbind /some/where /else/where
 
 est équivalent à
 mount --bind /some/where /else/where
mount --bind /some/where/mnt /else/where/mnt
 
 De plus, Linux permet de déclarer les montages comme partagés , esclave , privé ou non contraignant . Cela affecte si cette opération de montage est reflétée sous un montage lié qui réplique le point de montage. Pour plus de détails, consultez la documentation du noyau.
 
 Linux fournit également un moyen de déplacer les montages :où --bind copies, --move déplace un point de montage.
 
 Il est possible d'avoir différentes options de montage dans deux répertoires montés par liaison. Il y a cependant une bizarrerie :la création du montage lié et la définition des options de montage ne peuvent pas être faites de manière atomique, elles doivent être deux opérations successives. (Les anciens noyaux ne le permettaient pas.) Par exemple, les commandes suivantes créent une vue en lecture seule, mais il y a une petite fenêtre de temps pendant laquelle /else/where est en lecture-écriture :
 mount --bind /some/where /else/where
mount -o remount,ro,bind /else/where
 Je n'arrive pas à faire fonctionner les montages liés !
 
 Si votre système ne prend pas en charge FUSE, une astuce classique pour obtenir le même effet consiste à exécuter un serveur NFS, faites-le exporter les fichiers que vous souhaitez exposer (permettant l'accès à localhost ) et montez-les sur la même machine. Cela a une surcharge importante en termes de mémoire et de performances, donc les montages liés ont un avantage certain lorsqu'ils sont disponibles (ce qui est le cas sur la plupart des variantes Unix grâce à FUSE).
 Connexe :Comment déboguer un script bash ? Cas d'utilisation
 Affichage en lecture seule
 
 Il peut être utile de créer une vue en lecture seule d'un système de fichiers, soit pour des raisons de sécurité, soit simplement comme couche de sécurité pour vous assurer que vous ne le modifierez pas accidentellement.
 
 Avec bindfs :
 bindfs -r /some/where /mnt/readonly
 
 Avec Linux, le moyen le plus simple :
 mount --bind /some/where /mnt/readonly
mount -o remount,ro,bind /mnt/readonly
 
 Cela laisse un court intervalle de temps pendant lequel /mnt/readonly est en lecture-écriture. S'il s'agit d'un problème de sécurité, créez d'abord le montage de liaison dans un répertoire auquel seul root peut accéder, rendez-le en lecture seule, puis déplacez-le vers un point de montage public. Dans l'extrait ci-dessous, notez qu'il est important que /root/private (le répertoire au-dessus du point de montage) est privé ; les autorisations d'origine sur /root/private/mnt ne sont pas pertinents car ils sont cachés derrière le point de montage.
 mkdir -p /root/private/mnt
chmod 700 /root/private
mount --bind /some/where /root/private/mnt
mount -o remount,ro,bind /root/private/mnt
mount --move /root/private/mnt /mnt/readonly
 Remapper les utilisateurs et les groupes
 
 Les systèmes de fichiers enregistrent les utilisateurs et les groupes par leur ID numérique. Parfois, vous vous retrouvez avec plusieurs systèmes qui attribuent différents ID utilisateur à la même personne. Ce n'est pas un problème avec l'accès au réseau, mais cela rend les ID utilisateur sans signification lorsque vous transférez des données d'un système à un autre sur un disque. Supposons que vous ayez un disque créé avec un système de fichiers multi-utilisateurs (par exemple, ext4, btrfs, zfs, UFS, …) sur un système où Alice a l'ID utilisateur 1000 et Bob a l'ID utilisateur 1001, et vous voulez rendre ce disque accessible sur un système où Alice a l'ID utilisateur 1001 et Bob a l'ID utilisateur 1000. Si vous montez le disque directement, les fichiers d'Alice apparaîtront comme appartenant à Bob (car l'ID utilisateur est 1001) et les fichiers de Bob apparaîtront comme appartenant à Alice (car le l'ID utilisateur est 1000).
 
 Vous pouvez utiliser bindfs pour remapper les ID utilisateur. Montez d'abord la partition de disque dans un répertoire privé, où seul root peut y accéder. Créez ensuite une vue bindfs dans une zone publique, avec un remappage d'ID d'utilisateur et d'ID de groupe qui échange les ID d'utilisateur et les ID de groupe d'Alice et de Bob.
 mkdir -p /root/private/alice_disk /media/alice_disk
chmod 700 /root/private
mount /dev/sdb1 /root/private/alice_disk
bindfs --map=1000/1001:1001/1000:@1000/1001:@1001/1000 /root/private/alice_disk /media/alice_disk
 
 Voir Comment accéder de manière autorisée aux fichiers du dossier de départ de l'utilisateur du système non démarré ? et mount –bind autre utilisateur comme moi-même un autre exemple.
 Montage dans une prison ou un conteneur
 
 Une prison chroot ou un conteneur exécute un processus dans une sous-arborescence de l'arborescence de répertoires du système. Cela peut être utile pour exécuter un programme avec un accès restreint, par ex. exécuter un serveur réseau avec accès uniquement à ses propres fichiers et aux fichiers qu'il dessert, mais pas aux autres données stockées sur le même ordinateur). Une limitation de chroot est que le programme est confiné à un sous-arbre :il ne peut pas accéder à des sous-arbres indépendants. Les montages liés permettent de greffer d'autres sous-arbres sur cet arbre principal. Cela les rend fondamentaux pour l'utilisation la plus pratique des conteneurs sous Linux.
 
 Par exemple, supposons qu'une machine exécute un service /usr/sbin/somethingd qui ne devrait avoir accès qu'aux données sous /var/lib/something . La plus petite arborescence de répertoires contenant ces deux fichiers est la racine. Comment confiner le service ? Une possibilité est de créer des liens physiques vers tous les fichiers dont le service a besoin (au moins /usr/sbin/somethingd et plusieurs bibliothèques partagées) sous /var/lib/something . Mais cela est fastidieux (les liens physiques doivent être mis à jour chaque fois qu'un fichier est mis à jour) et ne fonctionne pas si /var/lib/something et /usr sont sur des systèmes de fichiers différents. Une meilleure solution consiste à créer une racine ad hoc et à la remplir à l'aide de montages :
 mkdir /run/something
cd /run/something
mkdir -p etc/something lib usr/lib usr/sbin var/lib/something
mount --bind /etc/something etc/something
mount --bind /lib lib
mount --bind /usr/lib usr/lib
mount --bind /usr/sbin usr/sbin
mount --bind /var/lib/something var/lib/something
mount -o remount,ro,bind etc/something
mount -o remount,ro,bind lib
mount -o remount,ro,bind usr/lib
mount -o remount,ro,bind usr/sbin
chroot . /usr/sbin/somethingd &
 
 Les espaces de noms de montage de Linux généralisent les chroots. Les montages de liaison permettent de remplir les espaces de noms de manière flexible. Voir Faire en sorte qu'un processus lise un fichier différent pour le même nom de fichier pour un exemple.
 Exécuter une distribution différente
 
 Une autre utilisation des chroots consiste à installer une distribution différente dans un répertoire et à y exécuter des programmes, même lorsqu'ils nécessitent des fichiers sur des chemins codés en dur qui ne sont pas présents ou qui ont un contenu différent sur le système de base. Cela peut être utile, par exemple, pour installer une distribution 32 bits sur un système 64 bits qui ne prend pas en charge les packages mixtes, pour installer des versions plus anciennes d'une distribution ou d'autres distributions pour tester la compatibilité, pour installer une version plus récente pour tester les dernières fonctionnalités tout en conservant un système de base stable, etc. Voir Comment exécuter des programmes 32 bits sur une Debian/Ubuntu 64 bits ? pour un exemple sur Debian/Ubuntu.
 
 Supposons que vous ayez une installation des derniers packages de votre distribution sous le répertoire /f/unstable , où vous exécutez des programmes en basculant vers ce répertoire avec chroot /f/unstable . Pour rendre les répertoires personnels disponibles à partir de ces installations, liez-les dans le chroot :
 mount --bind /home /f/unstable/home
 
 Le programme schroot le fait automatiquement.
 Accéder aux fichiers cachés derrière un point de montage
 
 Lorsque vous montez un système de fichiers sur un répertoire, cela masque ce qui se cache derrière le répertoire. Les fichiers de ce répertoire deviennent inaccessibles jusqu'à ce que le répertoire soit démonté. Parce que BSD nullfs et les montages de liaison Linux fonctionnent à un niveau inférieur à l'infrastructure de montage, un montage nullfs ou un montage de liaison d'un système de fichiers expose des répertoires qui étaient cachés derrière des sous-montages dans l'original.
 En relation :Mettre à jour les valeurs d'un fichier à l'aide des informations d'un autre fichier ? 
 Par exemple, supposons que vous ayez un système de fichiers tmpfs monté sur /tmp . S'il y avait des fichiers sous /tmp lorsque le système de fichiers tmpfs a été créé, ces fichiers peuvent encore rester, effectivement inaccessibles mais occupant de l'espace disque. Exécuter
 mount --bind / /mnt
 
 (Linux) ou
 mount -t nullfs / /mnt
 
 (FreeBSD) pour créer une vue du système de fichiers racine dans /mnt . Le répertoire /mnt/tmp est celui du système de fichiers racine.
 Exportations NFS sur différents chemins
 
 Certains serveurs NFS (tels que le serveur NFS du noyau Linux avant NFSv4) annoncent toujours l'emplacement réel du répertoire lorsqu'ils exportent un répertoire. Autrement dit, lorsqu'un client demande server:/requested/location , le serveur sert l'arborescence à l'emplacement /requested/location . Il est parfois souhaitable de permettre aux clients de demander /request/location mais servent en fait les fichiers sous /actual/location . Si votre serveur NFS ne prend pas en charge le service d'un autre emplacement, vous pouvez créer un montage de liaison pour la requête attendue, par exemple
 /requested/location *.localdomain(rw,async)
 
 dans /etc/exports et ce qui suit dans /etc/fstab :
 /actual/location /requested/location bind bind
 Un substitut aux liens symboliques
 
 Parfois, vous souhaitez créer un lien symbolique pour créer un fichier /some/where/is/my/file apparaissent sous /else/where , mais l'application qui utilise file développe les liens symboliques et rejette /some/where/is/my/file . Un montage lié peut contourner ce problème :bind-mount /some/where/is/my vers /else/where/is/my , puis realpath rapportera /else/where/is/my/file être sous /else/where , pas sous /some/where .
 Effets secondaires des montages liés
 Parcours récursifs de répertoires
 
 Si vous utilisez des montages liés, vous devez prendre soin des applications qui traversent l'arborescence du système de fichiers de manière récursive, telles que les sauvegardes et l'indexation (par exemple, pour créer une base de données de localisation).
 
 Habituellement, les montages liés doivent être exclus des traversées de répertoires récursives, de sorte que chaque arborescence de répertoires ne soit traversée qu'une seule fois, à l'emplacement d'origine. Avec bindfs et nullfs, configurez l'outil de traversée pour ignorer ces types de système de fichiers, si possible. Les montages de liaison Linux ne peuvent pas être reconnus en tant que tels :le nouvel emplacement est équivalent à l'original. Avec les montages de liaison Linux ou avec des outils qui ne peuvent exclure que des chemins et non des types de système de fichiers, vous devez exclure les points de montage pour les montages de liaison.
 
 Traversées qui s'arrêtent aux limites du système de fichiers (par exemple, find -xdev , rsync -x , du -x , …) s'arrêteront automatiquement lorsqu'ils rencontreront un point de montage bindfs ou nullfs, car ce point de montage est un système de fichiers différent. Avec les montages liés Linux, la situation est un peu plus compliquée :il n'y a une limite de système de fichiers que si le montage lié greffe un système de fichiers différent, pas s'il greffe une autre partie du même système de fichiers.
 Aller au-delà des montages liés
 
 Les montages liés fournissent une vue d'une arborescence de répertoires à un emplacement différent. Ils exposent les mêmes fichiers, éventuellement avec des options de montage différentes et (avec bindfs) des propriétés et des autorisations différentes. Les systèmes de fichiers qui présentent une vue modifiée d'une arborescence de répertoires sont appelés systèmes de fichiers superposés ou systèmes de fichiers empilables . Il existe de nombreux autres systèmes de fichiers superposés qui effectuent des transformations plus avancées. Voici quelques exemples courants. Si votre cas d'utilisation souhaité n'est pas couvert ici, consultez le référentiel des systèmes de fichiers FUSE.
  loggedfs — enregistre tous les accès au système de fichiers à des fins de débogage ou de surveillance (syntaxe du fichier de configuration, est-il possible de savoir quel programme ou script a créé un fichier donné ?, répertorie les fichiers auxquels un programme a accédé)
 
 Filtrer les fichiers visibles
   
 clamfs - exécute les fichiers via un antivirus lorsqu'ils sont lus
 
  
 filterfs — masque des parties d'un système de fichiers
 
  
 rofs — une vue en lecture seule. Similaire à bindfs -r , juste un peu plus léger.
 
  
 Montages Union - présentent plusieurs systèmes de fichiers (appelés branches ) sous un seul répertoire :si tree1 contient foo et tree2 contient bar alors leur vue d'union contient à la fois foo et bar . Les nouveaux fichiers sont écrits dans une branche spécifique, ou dans une branche choisie selon des règles plus complexes. Il existe plusieurs implémentations de ce concept, notamment :
  aufs – Implémentation du noyau Linux, mais plusieurs fois rejeté en amont
 funionfs – Implémentation de FUSE
 mhddfs — FUSE, écrit des fichiers dans une branche en fonction de l'espace libre
 overlay – Implémentation du noyau Linux, fusionné en amont dans Linux v3.18
 unionfs-fuse — FUSE, avec des fonctionnalités de mise en cache et de copie sur écriture
 
 
 
 Modifier les noms de fichiers et les métadonnées
  ciopfs – noms de fichiers insensibles à la casse (peut être utile pour monter des systèmes de fichiers Windows)
 convmvfs — convertit les noms de fichiers entre les jeux de caractères (exemple)
 posixovl - stocke les noms de fichiers Unix et d'autres métadonnées (autorisations, propriété, ...) sur des systèmes de fichiers plus restreints tels que VFAT (exemple)
 
 Afficher le contenu du fichier modifié
  avfs — pour chaque fichier d'archive, présente un répertoire avec le contenu de l'archive (exemple, plus d'exemples). Il existe également de nombreux systèmes de fichiers FUSE qui exposent des archives spécifiques sous forme de répertoires.
 fuseflt — exécute des fichiers via un pipeline lors de leur lecture, par ex. pour recoder des fichiers texte ou des fichiers multimédia (exemple)
 lzopfs — décompression transparente des fichiers compressés
 mp3fs - transcode les fichiers FLAC en MP3 lorsqu'ils sont lus (exemple)
 scriptfs — exécute des scripts pour servir du contenu (une sorte de CGI local) (exemple)
 
 Modifier la façon dont le contenu est stocké
  chironfs :réplique les fichiers sur plusieurs stockages sous-jacents (RAID-1 au niveau de l'arborescence des répertoires)
 copyfs — conserve des copies de toutes les versions des fichiers
 encfs - chiffre les fichiers
 pcachefs :couche de cache sur disque pour les systèmes de fichiers distants lents
 simplecowfs :stocke les modifications via la vue fournie en mémoire, en laissant les fichiers d'origine intacts
 wayback :conservez des copies de toutes les versions des fichiers