I've made this config in udev:

KERNEL=="sdd", SYMLINK+="QUORUML", OWNER="test", GROUP="gtest", MODE="0660"
KERNEL=="sde", SYMLINK+="QUORUMR", OWNER="test", GROUP="gtest", MODE="0660"

and after, I've added other disk and the new disk became the /dev/sde and the old /dev/sde became /dev/sdf, so the udev rule above became wrong since the name of sde has changed to sdf. How can I insure the correct disk? is there some other id? I've tried something like blkid, but since there is no partition it don't return any id.

[root@dbnode1 rules.d]# blkid /dev/sdd
[root@dbnode1 rules.d]#

I look for something like when there is iscsi disks, we can do it using iscsi id:

KERNEL=="sd?1", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$parent", RESULT=="360014054187384e668f45e58d036f19a", SYMLINK+="disk4", OWNER="xxxx", GROUP="xxxx", MODE="0660"
  • is there something useful in ls -l /dev/disk/by-*/* | grep sd[ef]$? Jun 26 at 9:23
  • Yes, there is: lrwxrwxrwx 1 root root 9 Jun 26 05:32 /dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:3:0 -> ../../sde lrwxrwxrwx 1 root root 9 Jun 26 05:32 /dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:4:0 -> ../../sdf
    – Harry
    Jun 26 at 9:35

1 Answer 1


You should be matching on SUBSYSTEM=="block", ENV{ID_SERIAL}=="xxx" (the brand/model AND serial number) anyway. Or ENV{ID_SERIAL_SHORT} (only the serial number). Or ENV{ID_WWN} (a globally unique identifier for the drive). Or maybe ENV{ID_PART_TABLE_UUID}.

I tend to use ID_SERIAL_SHORT because it's unique enough for my needs (drive manufactures tend not to re-use serial numbers and different manufacturers have different styles for their serial numbers), and it's what I print on sticky labels so I can easily identify drives in my hot-swap bays. I don't use the WWNs because IMO they look too much alike, they're hard to distinguish from each other.

Device names are explicitly not guaranteed to persist across reboots - they often do stay the same for months or even years, but it is not safe to rely on that. Kernel developers have documented and stated several times that there is no guarantee that they won't change the next time you boot. Why? Because a drive might die (or just take a little longer to spin up or respond when the kernel scans for devices), you might add or remove a drive, a new kernel version might detect devices in a different order, or any number of other reasons. This is why the advice for many years now has been "Don't use /dev/sdX names in /etc/fstab. Use a UUID or LABEL". The same advice, use a unique identifier, applies to udev rules.

You can find the attributes for any given drive with udevadm info /dev/sdX. There's a whole lot of interesting and useful properties/attributes there, but for now I'm only interested in the serial number.

e.g. I have an 8TB Seagate drive on my system which is currently /dev/sda. I can find its short serial number with:

$ udevadm info -q property --property=ID_SERIAL_SHORT /dev/sda 

To use that with a udev rule would look like:


Note the == for the first two attributes, they're a comparison rather than an assignment (See man 7 udev, especially the Operators sub-section).

If I wanted the full serial number with model etc, I could use the following instead:

$ udevadm info -q property --property=ID_SERIAL /dev/sda 

and a udev rule would be something like this:

SUBSYTEM=="block", ENV{ID_SERIAL}=="ST8000VN0022-2EL112_ZA9EL9YL", SYMLINK+="QUORUML", OWNER="test", GROUP="gtest", MODE="0660"

If I'm making a udev rule for one specific device (or type of device), I find it useful to add a commented out version of the output for udevadm info /dev/name in the rule file, just in case I need it for future reference. Use # for comments.

BTW, if you need to, you can extract the value alone (without the property name) with tools like awk or cut:

$ udevadm info -q property --property=ID_SERIAL_SHORT /dev/sda | awk -F= '{print $2}'

$ udevadm info -q property --property=ID_SERIAL_SHORT /dev/sda | cut -d= -f2
  • Thanks! how I said, I have some local disks, so, instead of using ID_SERIAL I've used ID_PATH (there is no ID_SERIAL for those disks). Is that ok? beside local disks I have iscsi as well, so I've mixed the udev rule, one using ID_SERIAL and other using ID_PATH: SUBSYSTEM=="block",ENV{ID_PATH}=="pci-0000:00:10.0-scsi-0:0:3:0",SYMLINK+="QUORUML",OWNER="test", GROUP="gtest", MODE="0660" SUBSYSTEM=="block",ENV{ID_SERIAL}=="36001405a9510f3f85cb4ef69688999cb",SYMLINK+="QUORUMR",OWNER="test", GROUP="gtest", MODE="0660"
    – Harry
    Jun 27 at 1:20
  • Only to explain better my scenery: there are two servers and each one has a local quorum disk, but the quorum disk of server 1 need be visible on server2 and server2 quorum disk need be visible on server 1, this is why I have local disk and at the same time iscsi disks. Each server has a tgtd daemon running to share the local disks.
    – Harry
    Jun 27 at 1:31
  • 1
    RE: missing ID_SERIAL - that's not uncommon for virtual disks on a VM (mostly because you have to go out of your way to fake them and most people don't bother with a "minor cosmetic detail"), but very wrong for real drives manufactured within the last 10 years or so. I don't use iscsi here and it has been years since I worked with it, so can't confirm, but it's possible that it's not unusual for iscsi remote drives too. Anyway, the important thing is that you have some unique identifier for each drive. Doesn't matter what it is, as long as it won't arbitrarily change on reboot.
    – cas
    Jun 27 at 2:55
  • Yes, the disks are from vmware. Maybe that is the reason there is no ID_SERIAL. I've running with the mixed ID_PATH and ID_SERIAL and seems ok until now, even after reboot and add/remove new disks.
    – Harry
    Jun 27 at 3:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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