Ansätze für das automatische Einhängen von Geräten in Linux ändern sich ständig. Durch das Googeln werden zahlreiche Lösungen mit unterschiedlichen Anwendbarkeitsebenen für moderne systembasierte Boxen bereitgestellt.
Die folgenden Ansätze scheinen zu existieren:
/etc/fstab, um pro Laufwerks-Mounts nach UUID hinzuzufügen.udev Regeln (anscheinend kollidieren "rohe Regeln" mit bestehenden Systemd-Richtlinien)thunar+ thunar-volman-Pakete, oder das nautilusAutomounting in Gnome mit dem gnome-volume-managerPaket (anscheinend basieren sie auf udisks ).Wie immer unter Linux ist die Auswahl etwas überwältigend und es ist nicht klar, welcher Ansatz derzeit empfohlen wird. Darüber hinaus scheint es, dass verschiedene Subsysteme mit automatischem Mounting zu Konflikten führen können, die zu Situationen führen, in denen eine Partition von einem Tool gemountet wird und dann innerhalb von Sekunden von einem anderen Tool automatisch aufgehoben wird.
Für Systeme mit einer Desktop-Umgebung ist dies unkompliziert, da die meisten von ihnen das USB-Mounting automatisch durchführen. Daher müssen außer den Optionen für das automatische Anbringen der Einstellungen keine weiteren Aktionen ausgeführt werden.
Was wäre der aktuelle Ansatz für ein Headless-System, das meistens im Textmodus arbeitet?
Nach dem Hantieren mit allen Optionen, fand ich usbmountzu gerade arbeiten, nachdem ich bearbeitet /lib/systemd/system/systemd-udevd.serviceund geändert, MountFlags=slaveum, MountFlags=sharedwie beschrieben in dieser Ausgabe . Es ist nicht notwendig, UUIDs oder Labels manuell zu Konfigurationsdateien hinzuzufügen. Der Nachteil ist, dass es die Mount-Punkte erstellt, unter /media/usbNdenen nicht perfekt ist, also habe ich zu dem gewechselt, automount-usbder überraschend einfach einzurichten war (nur das configure.shSkript ausgeführt) und die Mount-Ordner wie /media/<device>_<disk_label>zB erstellt /media/sda2_mylabel.
Relevante Links:
Einträge in /etc/fstabsollten auf einem systemd-basierten System immer noch berücksichtigt werden.
Stattdessen kann eine .mount-Einheit verwendet werden, die einem Eintrag in fstab entspricht.
Eine .automount-Einheit kann verwendet werden, wenn der Mount beim Start oder dauerhaft nicht erforderlich ist; Das Systemd wird nach einer in der Einheitendatei angegebenen Wartezeit vom System abgemeldet.
Siehe die systemd.mount(5)und systemd.automount(5)Mann Seiten.
Es ist nicht klar, welcher der derzeit "offiziell" unterstützte Ansatz ist.
Offiziell von wem unterstützt? Wenn beispielsweise GNOME Automount-Funktionen auf Basis von udisks enthält, können Sie sicher sein, dass sie von GNOME selbst offiziell unterstützt werden.
Ich interessiere mich mehr für das zweite (dh für ein beliebiges USB-Speichergerät), da ich zum ersten Mal die Einträge hinzufügen kann
/etc/fstab.
Dafür gibt es keine "Standardmethode". Im besten Fall hat sich die Mehrheit der vorhandenen Systeme dazu entschlossen, Automatisierung hinzuzufügen udisks2. Für sich alleine macht udisks gar nichts, aber es ist das "Backend", das von vielen grafischen Desktop-Umgebungen verwendet wird (zumindest verwenden GNOME und Xfce es; ich bin nur zu 80% sicher, was KDE und Aufklärung angeht).
(Ihre Option 3 wäre also "udisks2 + automount by udiskie"), und Option 4 wäre "udisks2 + automount nach Desktop-Umgebung".)
Zu den udev-Regeln: Egal ob es um das Anhängen von Dateisystemen oder das Starten von Diensten geht, die kurze Antwort lautet "Don't do it" (aus verschiedenen Gründen). aber die lange Antwort lautet: "Tu es nicht direkt, aber du kannst init bitten, es zu tun". Es wäre also nicht schrecklich, systemd-mountvor einer udev-Regel zu laufen, die dann einfach die mount-Anforderung an init übergibt, genau wie eine .mount-Einheit ...
Erwarten Sie jedoch, dass dies einen systemd Fehler / Warze / Missfeature auslöst: Da udev meldet, dass das Gerät erst nach der Verarbeitung der Regeln betriebsbereit ist, kann es passieren, dass init das Laufwerk automatisch aus dem Laufwerk ausmustert, weil es der Meinung ist, das Gerät sei noch nicht da.
Stattdessen würde udevil besser funktionieren, da es nichts über Regeln ausführt, sondern nur auf "Device Ready" -Ereignisse reagiert, die von udev gesendet werden.
fstab-Einträge sind auf statische Geräte ausgerichtet. Sie können jedoch missbräuchlich für verschiedene USB-Sticks verwendet werden /dev/disk/by-path/..., die dem physischen Pfad eines Geräts entsprechen (z. B. PCI-Steckplatz 3, USB-Port 1, Partition 1 ...). Auf diese Weise können Sie einen fstab-Eintrag schreiben, der passt zu jeder Festplatte, die am selben USB-Port angeschlossen ist.
Der autofs- Kernel- Automounter ist ähnlich wie udisks nur das Backend, auf dem verschiedene Automounts von Userspace implementiert werden können. Sobald ein autofs-Mount eingerichtet ist, werden alle Zugriffsversuche an den entsprechenden Daemon gemeldet. Die gebräuchlichsten Implementierungen sind die traditionellen ( kartenbasierten ) autofsund kürzlich systemddie .automount-Einheiten.
Die "dynamische" USB-Gerätelogik müsste also immer noch im Userspace implementiert werden. In beiden Fällen ist dies mehr Arbeit als nur das Verwenden von udisks.
Bei plain systemd besteht die einzige Möglichkeit darin, auf dem oben genannten fstab "by-path" -Hack aufzubauen. Nachdem Sie einen Fstab-Eintrag für den gewünschten USB-Anschluss geschrieben haben, können Sie ihn mit markieren x-systemd.automount,x-systemd.idle-timeout=300, um den autofs Automounter zu verwenden. (Oder erstellen Sie für das gleiche Ergebnis selbstverständlich eigenständige .mount + .automount-Einheiten.)
Wenn Sie Automounts für alle USB-Festplatten an allen Ports dynamisch generieren möchten, kann systemd dies nicht ohne Scripts von Drittanbietern.
Ich weiß nicht, ob Sie autofsddas tun können, was Sie möchten, aber ich erinnere mich daran, dass es einige Arten dynamischer Karten (für Benutzerverzeichnisse) unterstützt. Möglicherweise würde der programMap-Typ (und ein Skript, das alle verbundenen Festplatten aufführt) funktionieren.