Les approches de montage automatique des périphériques sous Linux ne cessent de changer, et googler renvoie de nombreuses solutions avec différents degrés d'applicabilité pour les boîtiers modernes basés sur systemd.
Les approches suivantes semblent exister:
/etc/fstab
pour ajouter des montages par lecteur par UUID/label/périphérique.udev
(apparemment, des "règles brutes" pourraient entrer en conflit avec les politiques systemd existantes)thunar
+ thunar-volman
, ou le montage automatique nautilus
dans Gnome avec le package gnome-volume-manager
(apparemment, ils s'appuient sur disks ).Les choix peuvent être accablants et il n’est pas clair quelle est l’approche actuellement recommandée. De plus, il semble que différents sous-systèmes à montage automatique puissent entrer en conflit, ce qui peut conduire à des situations dans lesquelles une partition est montée par un outil, puis en quelques secondes, est automatiquement démontée par un autre outil.
Pour les systèmes avec un environnement de bureau, cela est simple, car la plupart d’entre eux gèrent le montage USB automatiquement. Aucune action supplémentaire n’est donc nécessaire, à part l’activation de l’option de montage automatique dans les paramètres.
Quelle serait l'approche actuelle pour un système sans tête fonctionnant principalement en mode texte?
Après avoir bidouillé avec toutes les options que j'ai trouvées usbmount
à , je ne fais que travailler après avoir modifié /lib/systemd/system/systemd-udevd.service
et changé MountFlags=slave
en MountFlags=shared
comme décrit dans ce problème . Il n'est pas nécessaire d'ajouter manuellement des UUID ou des étiquettes à des fichiers de configuration. L'inconvénient est qu'il crée les points de montage sous /media/usbN
qui n'est pas parfait. Je suis donc passé à automount-usb
qui était étonnamment facile à configurer (vient d'exécuter le script configure.sh
) et crée des dossiers de montage comme /media/<device>_<disk_label>
par exemple comme /media/sda2_mylabel
.
Liens pertinents:
Les entrées dans /etc/fstab
doivent toujours être prises en compte sur un système basé sur systemd.
Une unité .mount peut être utilisée à la place et doit être considérée comme équivalente à une entrée dans fstab.
Une unité .automount peut être utilisée si le montage n’est pas requis au démarrage ou de manière permanente; systemd le démontera une fois la période d'inactivité indiquée dans le fichier d'unité écoulée.
Consultez les pages de manuel systemd.mount(5)
et systemd.automount(5)
pour plus de détails.
il n'est pas clair quelle est l'approche actuelle "officiellement" prise en charge.
Officiellement soutenu par qui? Si par exemple GNOME inclut des fonctionnalités de montage automatique basées sur des udisks, vous pouvez donc être sûr qu’elles sont officiellement prises en charge par GNOME.
Je suis plus intéressé par le second (c'est-à-dire quel que soit le périphérique de stockage USB), car pour le premier, je peux simplement ajouter les entrées à
/etc/fstab
.
Il n'y a pas de "moyen standard" pour le faire. Au mieux, la majorité des systèmes existants ont opté pour l’automatisation en plus de udisks2
. En soi, disks ne monte rien automatiquement du tout - mais c'est le "backend" utilisé par de nombreux environnements de bureau graphiques (au moins, GNOME et Xfce l'utilisent; je ne suis sûr que de 80% KDE et Lumières).
(Ainsi, votre option 3 serait "udisks2 + automount par udiskie" et l'option 4 serait "udisks2 + automount par environnement de bureau".)
Concernant les règles d'udev: qu'il s'agisse de monter des systèmes de fichiers ou de démarrer des services, la réponse courte est "ne le faites pas" (pour diverses raisons); mais la réponse longue est: "ne le faites pas directement, mais vous pouvez demander à init de le faire". Donc, il ne serait pas horrible d'exécuter systemd-mount
à partir d'une règle udev, qui passe alors simplement la demande de montage à init, comme le ferait une unité .mount ...
Cependant, attendez-vous à ce que cela déclenche un bogue systemd/wart/raté: comme udev rapporte que le périphérique est prêt uniquement après en traitant les règles, vous pourriez vous retrouver avec init en démontant automatiquement le disque car il pense que le périphérique n'est pas encore là.
Au lieu de cela, devil fonctionnerait mieux, car il n’exécute rien via les règles mais ne réagit qu’aux événements "device ready" émis par udev.
les entrées fstab sont orientées vers les périphériques statiques. Cependant, ils peuvent être en quelque sorte abusés pour diverses clés USB en utilisant /dev/disk/by-path/...
, qui correspond au chemin physique d'un périphérique (par exemple, emplacement PCI 3, port USB 1, partition 1, etc.). Ainsi, vous pouvez écrire une entrée fstab qui correspond à tout disque branché sur le même port USB.
Autofs kernel automounter est, comme les udisks, le backend sur lequel différents montages automatiques peuvent être implémentés par l'espace utilisateur. Une fois qu'un montage autofs est configuré, toutes les tentatives pour y accéder sont signalés au démon correspondant. Les implémentations les plus courantes sont les suivantes: autofs
(basé sur des cartes), et récemment systemd
avec les unités .automount.
Ainsi, la logique de périphérique USB "dynamique" devrait encore être mise en œuvre dans l'espace utilisateur, et de toute façon, cela demande plus de travail que d'utiliser simplement des disques optiques.
Avec plain systemd, votre seule option est de construire sur le hack "par-chemin" de fstab ci-dessus. Une fois que vous avez écrit une entrée fstab pour le port USB souhaité, vous pouvez la marquer avec x-systemd.automount,x-systemd.idle-timeout=300
pour utiliser le compteur automatique autofs. (Ou bien sûr, créez des unités .mount + .automount autonomes pour le même résultat.)
Si vous souhaitez générer de manière dynamique des montages automatiques pour tous les disques USB sur tous les ports, systemd ne peut pas le faire sans scripts tiers.
Je ne sais pas si autofsd
peut faire ce que vous voulez, mais je me souviens qu'il prend en charge certains types de cartes dynamiques (pour les répertoires de départ de l'utilisateur). Peut-être que le type de carte program
(et un script énumérant tous les disques connectés) fonctionnerait.