I have the following content in in /etc/udev/rules.d/81-external-disk.rules:

ENV{ID_FS_UUID}=="6826692e-79f4-4423-8467-cef4d5e840c5", RUN{program}+="/bin/mount -o nofail,x-systemd.device-timeout=1 -t ext4 -U 6826692e-79f4-4423-8467-cef4d5e840c5 /backup/external"

After running:

udevadm control --reload ; udevadm trigger /dev/sdb1

It does nothing at all. However if II change the mount command for something such as /bin/touch /tmp/xyz it works.

Versions:

[root@helsinki rules.d]# rpm -qa | grep udev
libgudev1-219-19.el7_2.12.x86_64
python-pyudev-0.15-7.el7_2.1.noarch
[root@helsinki rules.d]# rpm -qa | grep systemd
systemd-libs-219-19.el7_2.12.x86_64
systemd-219-19.el7_2.12.x86_64
systemd-sysv-219-19.el7_2.12.x86_64
[root@helsinki rules.d]# cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 
up vote 9 down vote accepted

This is a systemd feature. The original udev command has been replaced by systemd-udevd (see its man page). One of the differences is that it creates its own filesystem namespace, so your mount is done, but it is not visible in the principle namespace. (You can check this by doing systemctl status systemd-udevd to get the Main PID of the service, then looking through the contents of /proc/<pid>/mountinfo for your filesystem).

If you want to go back to having a shared instead of private filesystem namespace, then create a file /etc/systemd/system/systemd-udevd.service with contents

.include /usr/lib/systemd/system/systemd-udevd.service
[Service]
MountFlags=shared 

or a new directory and file /etc/systemd/system/systemd-udevd.service.d/myoverride.conf with just the last 2 lines, i.e.

[Service]
MountFlags=shared

and restart the systemd-udevd service. I haven't found the implications of doing this.

  • Yes I've applied such a workaround, I wonder if has security implications too. – sebelk Dec 13 '16 at 19:52
  • 1
    Pretty sure this did not work until I added [Service] between those two lines. – goldilocks Oct 15 '17 at 23:10
  • 1
    @goldilocks You are probably right. I added this to the answer, thanks. It might depend on what the last section was in the included file, but it seems systemd now prefers you to use the *.d/*.conf way of making changes, as .include doesnt seem to be documented. – meuh Oct 16 '17 at 7:54

This same problem occurs in Ubuntu 18.04 with the same underlying cause. To fix it we create an override file for systemd-udevd:

sudo systemctl edit systemd-udevd

And insert into it:

[Service]
MountFlags=shared

Save the file and then execute:

sudo systemctl daemon-reload
sudo service systemd-udevd --full-restart

ENV{ID_FS_UUID} is not known before mounting.

You should use an attribute closer to the hardware like ATTR{SerialNumber} or ATTR{Vendor} and ATTR{ProdID}.

usb-devices can help you to find the better way to identify your device.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.