3

Подходы к автоматическому монтированию устройств в Linux постоянно меняются, и поиск в Google дает довольно много решений с различной степенью применимости для современных системных систем.

Существуют следующие подходы:

  1. изменение /etc/fstab для добавления монтирования на диск по UUID.
  2. правила udev (очевидно, «сырые правила» могут конфликтовать с существующими политиками systemd)
  3. udisks2 работает как сервис systemd или через udiskie
  4. udevil
  5. usbmount
  6. автомонтирование обеспечивается рабочими средами, т.е. на XFCE через thunar + thunar-volman пакеты или nautilus автомонтирование в Gnome с пакетом gnome-volume-manager ( по- видимому , они полагаются на udisks).
  7. autofs kernel automounter
  8. системное монтирование systemd , пример использования: automount-usb

Как всегда в Linux, выбор немного ошеломляющий, и неясно, какой подход рекомендуется использовать в настоящее время. Более того, кажется, что разные подсистемы автоматического монтирования могут конфликтовать друг с другом, что приводит к ситуациям, когда раздел монтируется одним инструментом, а затем в течение нескольких секунд автоматически демонтируется другим инструментом.

Для систем с окружением рабочего стола это просто, так как большинство из них автоматически обрабатывают USB-подключение, поэтому никаких дополнительных действий не требуется, кроме включения опции автоматического подключения в настройках.

Каков нынешний подход для безголовой системы, которая в основном работает в текстовом режиме?

Обновить

После работы со всеми параметрами я обнаружил, что usbmount просто работает после того, как я отредактировал /lib/systemd/system/systemd-udevd.service и изменил MountFlags=slave на MountFlags=shared как описано в этом выпуске. Нет необходимости вручную добавлять какие-либо UUID или метки к любым файлам конфигурации. Недостатком является то, что он создает точки монтирования в /media/usbN что не идеально, поэтому я переключился на automount-usb который был удивительно прост в настройке (просто запустил скрипт configure.sh ) и который создает папки монтирования, такие как /media/<device>_<disk_label> например, как /media/sda2_mylabel .

Соответствующие ссылки:

2 ответа2

1

Записи в /etc/fstab прежнему должны учитываться в системе на основе systemd.

Вместо этого можно использовать единицу .mount, и ее следует считать эквивалентной записи в fstab.

Блок .automount может использоваться, если монтирование не требуется при запуске или постоянно; systemd размонтирует его после истечения периода простоя, указанного в файле модуля.

Подробности смотрите в systemd.mount(5) и systemd.automount(5) .

1

неясно, какой сейчас «официально» поддерживаемый подход.

Официально поддерживается кем? Если, например, GNOME включает в себя функцию автомонтирования на основе udisks, вы можете быть уверены, что она официально поддерживается GNOME.

Меня больше интересует второе (т.е. любое запоминающее устройство USB), поскольку для первого я могу просто добавить записи в /etc/fstab .

Для этого нет "стандартного способа". В лучшем случае большинство существующих систем решили добавить автоматизацию поверх udisks2 . Сам по себе udisks вообще ничего не монтирует, но это "бэкэнд", используемый многими графическими средами рабочего стола (по крайней мере, в GNOME и Xfce его используют; в KDE и Enlightenment я уверен только на 80%).

(Таким образом, ваш вариант 3 будет «udisks2 + automount by udiskie», а вариант 4 будет «udisks2 + automount by desktop desktop».)


Что касается правил udev: будь то монтирование файловых систем или запуск служб, краткий ответ - «не делай этого» (по разным причинам); но длинный ответ таков: «не делайте этого напрямую, но вы можете попросить init сделать это». Поэтому было бы не страшно запускать systemd-mount из правила udev, которое затем просто передает запрос на монтирование init, как если бы модуль .mount ...

Однако следует ожидать, что это вызовет системную ошибку /wart /misfeature: поскольку udev сообщает, что устройство готово только после обработки правил, вы можете в конечном итоге автоматически отключить init из-за того, что устройство еще не создано.

Вместо этого udevil будет работать лучше, так как он ничего не запускает через правила, а только реагирует на события "готовности устройства", генерируемые udev.


Записи в fstab ориентированы на статические устройства. Однако их можно использовать для разных USB-накопителей, используя /dev/disk/by-path/... , что соответствует физическому пути устройства (например, PCI-слот 3, USB-порт 1, раздел 1). ..) Таким образом, вы можете написать запись fstab, которая соответствует любому диску, подключенному к тому же порту USB.


Автомонтировщик ядра autofs, как и udisks, - это просто бэкэнд, на котором пользовательские пространства могут реализовывать различные автомонтирования . Как только монтирование autofs настроено, все попытки получить к нему доступ сообщаются соответствующему демону. Наиболее распространенные реализации являются традиционными (карты на основе) в autofs а в последнее время systemd с .automount единиц.

Таким образом, "динамическая" логика USB-устройства все еще должна быть реализована в пользовательском пространстве, и в любом случае это больше, чем просто использование udisks.

  • С простой системой systemd, ваш единственный вариант - построить поверх вышеописанного хакера fstab "by-path". После того, как вы напишите запись fstab для нужного USB-порта, вы можете пометить ее как x-systemd.automount,x-systemd.idle-timeout=300 чтобы использовать автомонтировщик autofs. (Или, конечно, создайте автономные единицы .mount + .automount для того же результата.)

    Если вы хотите динамически генерировать автомонтирование для всех USB-дисков на всех портах, systemd не сможет сделать это без сторонних скриптов.

  • Я не знаю, может ли autofsd делать то, что вы хотите, но я помню, что он поддерживает некоторые виды динамических карт (для домашних каталогов пользователей). Возможно, сработает program map-type (и скрипт, который перечисляет все подключенные диски).

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .