Я ничего не знаю об этом ограничении systemd, так как имя каталога точки монтирования преобразуется в имя файла systemd. Самый простой ответ может заключаться в том, чтобы удалить записи из fstab и написать крошечный скрипт для монтирования по запросу:
#!/bin/bash
( mount -U xxxx-xxxx /media/strontium -t vfat -o rw,exec ||
mount -U yyyy-yyyy /media/strontium -t vfat -o rw,exec
) && echo ok
Не забудьте после изменения / etc / fstab
выполнить ] sudo systemctl daemon-reload
, чтобы гарантировать, что systemd заметит ваши изменения.
Если вы хотите сохранить записи в / etc / fstab
, вы можете сделать вторую точку монтирования символической ссылкой на первую, например ln -s / media / strontium / media / стронций2
. Когда монтирование завершено, по ссылке переходят, так что она, как обычно, попадает в каталог. В этом случае вы должны добавить опцию noauto
в обе строки, иначе systemd запутается и немедленно отключит то, что считает первой записью.
Вместо символической ссылки вы можете вместо этого использовать реальный каталог, а затем выполнить ручную привязку монтирования , чтобы смонтировать этот каталог в желаемом месте:
mount --bind /media/strontium2 /media/strontium
Вы также должны не забыть размонтировать эту привязку mount как первое крепление.
Раньше вы могли добавить правило udev для явного вызова mount при появлении UUID, например, в /etc/udev/rules.d/92-my.rules
:
ACTION=="add", ENV{ID_FS_UUID}=="xxxx-xxxx", RUN+="/usr/bin/mount /dev/%k /media/strontium"
но это не работает с последними версиями systemd, поскольку он запускает udevd
в
отдельном пространстве имен монтирования, поэтому, хотя он выполняет монтирование, вы его не видите.
Я не делаю этого. пока не знаю причину этого пространства имен, но в принципе вы можете
переопределить эту функцию, создав файл
/ etc / systemd / system / systemd-udevd.service
с 2 строками
.include /usr/lib/systemd/system/systemd-udevd.service
MountFlags=shared
Если вы хотите что-то, что все еще работает автоматически, то альтернативой является отслеживание событий из udevd
, касающихся блочных устройств, и выполнение явного монтирования. Например, запустите постоянно:
#!/bin/bash
# udevadm monitor outputs a stanza ending with a blank line
# UDEV [5291328.3] add /devices/pci0000:00/.../usb3/..../block/sdd (block)
# ACTION=add
# DEVNAME=/dev/sdd
stdbuf -o L udevadm monitor -u -p -s 'block/disk' |
awk -F= '
$0~/^ACTION=/{ action = $2 }
$0~/^DEVNAME=/{ name = $2 }
$0~/^ID_FS_UUID=/{ uuid = $2 }
$0~/^$/{ if(action=="add" && (uuid=="xxxx-xxxx"||uuid=="yyyy-yyyy")
system("sudo mount mount " name " /media/strontium -t vfat -o rw,exec")
uuid=""
}'
is there a way to safely test it?
Вы можете проверить это с помощью сообщения об ошибке команды. Если это то же самое из busybox и при явном вызове, то «приключение» потерпит неудачу.
В моей системе оболочка sash
была бы по-прежнему доступна, если бы она была запущена.
user@ulmus-thomasii:~$ echo mv b | busybox sh
mv: Fehlender Zieldatei‐Operand hinter 'b'
„mv --help“ liefert weitere Informationen.
user@ulmus-thomasii:~$ /bin/mv b
/bin/mv: Fehlender Zieldatei‐Operand hinter 'b'
„/bin/mv --help“ liefert weitere Informationen.
user@ulmus-thomasii:~$ echo mv b | sash
mv: Fehlender Zieldatei‐Operand hinter 'b'
„mv --help“ liefert weitere Informationen.
user@ulmus-thomasii:~$ echo -mv b | sash
usage: -mv srcName... destName
user@ulmus-thomasii:~$