What Is udev in Linux? A Beginners Guide to udev Rules

Updated: 10 October 2026 · Applies to: udev in systemd 252 to 259 on Debian 13, Ubuntu 24.04 and 26.04, AlmaLinux and Rocky Linux 9 and 10, Fedora 44

udev is the part of Linux that reacts when you plug in or remove a device. It sets up the device's entry in /dev, adds easy names for it and decides who may use it, following rules you can write yourself. It runs in the background as a service called systemd-udevd.

Think of a school office: when a new student joins, it gives them an ID card, a roll number and a class, following the rules for that kind of student. udev does the same for a new device.

A udev rule is one line in a text file that says "if a device looks like this, do that". Your rules go in /etc/udev/rules.d/.

What happens when you plug in a USB drive

The kernel (the core of Linux that controls the hardware) notices the new device and loads a driver, a small program for that kind of device.
The kernel names the drive, for example sdb (see finding a USB drive name), and /dev/sdb appears. /dev is a folder of special files, one per device.
The kernel sends an event (a uevent): a short message that says "this device was added", with details.
systemd-udevd receives the event and checks its rules, file by file, in order.
Matching rules add symlinks (shortcut files that point to another file), such as a link in /dev/disk/by-id/ with the drive's model and serial number. It stays the same even if sdb becomes sdc next time.
Rules set permissions: on Debian 13 every disk gets the group disk.
udev tells other programs, such as a desktop file manager, that the device is ready.

Some commands below need root, the administrator account; sudo in front of a command runs it as root.

1. Watch events with udevadm monitor

udevadm is the udev control tool. monitor prints events as they happen (Ctrl+C stops it):

$ sudo udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL lines come from the kernel; UDEV lines come after udev has applied its rules. Our test server has no USB drive, so in a test container (without a udev service) we ran udevadm monitor --kernel and added and removed a virtual network device:

KERNEL[908293.406125] add      /devices/virtual/net/demo0 (net)
KERNEL[908294.409649] remove   /devices/virtual/net/demo0 (net)
(output shortened)

Each line shows the sender, seconds since boot, the action, the device path and its subsystem (device family) in brackets. A USB drive gives a burst of lines, including one for the disk (subsystem block).

2. Look up a device with udevadm info

info shows what udev knows about a device, named by its /dev file or its path in /sys (where the kernel shows device details):

$ udevadm info /sys/block/sda
P: /devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:0/0:0:0:0/block/sda
U: block
N: sda
E: DEVTYPE=disk
(output shortened)

P: is the path in /sys, U: the subsystem, N: the name in /dev and E: a property that rules can check.

Rules also need attributes: small facts such as a maker code. --attribute-walk (or -a) lists them for the device and each parent (the bigger device it belongs to). Our test server has a virtual USB tablet (a pointing device):

$ udevadm info --attribute-walk /sys/class/input/event4
...
  looking at device '/devices/pci0000:00/0000:00:01.2/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input5/event4':
    KERNEL=="event4"
    SUBSYSTEM=="input"
...
  looking at parent device '/devices/pci0000:00/0000:00:01.2/usb1/1-1':
    SUBSYSTEMS=="usb"
    ATTRS{idProduct}=="0001"
    ATTRS{idVendor}=="0627"
    ATTRS{product}=="QEMU USB Tablet"
(output shortened)

The lines are already in rule format: idVendor is the maker code, idProduct the model code. The note at the top of the output says one rule may combine the device's attributes with those of one parent.

3. What udev rules look like

A rule is a comma-separated list of KEY, operator and "value":

Match keys (the "if" part) use == (is equal) or != (is not equal), for example SUBSYSTEM=="input".
Assignment keys (the "then" part) use = (set), += (add to a list, such as one more symlink) or := (set and lock against later rules).

In values, * matches any characters and ? exactly one. According to the systemd documentation, udev cannot rename a device file such as /dev/sdb, only add symlinks; only network interfaces can be renamed.

The main rule folders are:

/usr/lib/udev/rules.d/: rules from your Linux packages. Do not edit them; updates replace them.
/etc/udev/rules.d/: your rules. A file here replaces a file with the same name in /usr/lib/udev/rules.d/.
/run/udev/rules.d/: temporary rules, lost at reboot.

All files are sorted together by name, whatever their folder, and read in that order. Names must end with .rules. (Old guides say /lib/udev/rules.d; on Debian 13 /lib links to /usr/lib.)

4. Write and test your first rule

This rule gives our test tablet the extra name /dev/my-tablet.

Create the file with an editor such as nano (sudo nano /etc/udev/rules.d/99-my-tablet.rules), add these lines and save (# starts a comment):
```
# Friendly name for the QEMU USB tablet
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{idVendor}=="0627", ATTRS{idProduct}=="0001", SYMLINK+="my-tablet", MODE="0640"
```
The rule reads: an input device, whose name starts with event, with a parent that has maker code 0627 and model code 0001; then add the link my-tablet and set mode 0640 (owner may read and write, group may read, others nothing).

Check it (needs systemd 254 or newer; AlmaLinux and Rocky Linux 9 have 252):

$ sudo udevadm verify /etc/udev/rules.d/99-my-tablet.rules

1 udev rules files have been checked.
  Success: 1
  Fail:    0

Practice run: udevadm test pretends the device was just added and shows what each rule would do:

$ sudo udevadm test /sys/class/input/event4
...
event4: /etc/udev/rules.d/99-my-tablet.rules:2 MODE 0640
event4: /etc/udev/rules.d/99-my-tablet.rules:2 Added SYMLINK 'my-tablet'
...
This program is for debugging only, it does not run any program
specified by a RUN key.
...
Device node symlinks: (priority=0)
  /dev/my-tablet
(output shortened)

Line 2 of your file matched. On systemd 258 and newer, -v also shows each check.

Apply it:
```
sudo udevadm control --reload
sudo udevadm trigger
```
The first line makes udev reread its rules; according to the systemd documentation, that alone does not change devices already plugged in. The second asks the kernel to resend events, so the rule is applied now (replugging the device also works). ls -l /dev/my-tablet then shows the link.

For a USB drive or USB serial adapter, put your own codes in place of abcd, 1234 and 5678 (both lines passed udevadm verify):

SUBSYSTEM=="block", KERNEL=="sd?", ATTRS{idVendor}=="abcd", ATTRS{idProduct}=="1234", SYMLINK+="backup-drive"
SUBSYSTEM=="tty", ATTRS{idVendor}=="abcd", ATTRS{idProduct}=="5678", SYMLINK+="my-serial", GROUP="dialout", MODE="0660"

sd? matches the disk (sdb), not its partitions (sdb1). GROUP="dialout" with MODE="0660" lets the dialout group use the adapter. More examples: custom device names, device owner and group, device detection with udev.

5. Network interface names

A name such as enp5s0 comes from where the card sits: en means Ethernet and p5s0 PCI bus 5, slot 0 (according to the systemd naming scheme documentation). Old eth0 names depended on detection order. For your own name, the systemd documentation points to a .link file, numbered before 99-default.link, for example /etc/systemd/network/10-lan0.link with your card's MAC (hardware) address:

[Match]
MACAddress=00:11:22:33:44:55

[Link]
Name=lan0

Test it without changing anything:

$ sudo udevadm test-builtin net_setup_link /sys/class/net/eth0
eth0: Config file /etc/systemd/network/10-lan0.link is applied
ID_NET_NAME=lan0
(output shortened)

On a remote server, update your network settings before rebooting, or you can lose the connection. See also old ethX names and which port is which interface.

Common mistakes

Wrong file ending: our test file 98-wrong.rule was skipped without a warning.
= instead of ==: udevadm verify reported Invalid operator for SUBSYSTEM.
A number that is too low: later files win. Our 10-early.rules set GROUP="dialout", but 50-udev-default.rules set the group back to input; as 90-late.rules it worked. Use 90 or 99.
Long jobs in RUN: according to the systemd documentation, RUN is for very short tasks; anything still running after the event is killed. Use a systemd service (script on USB attach, script as a service).
Mounting from a rule: the same documentation says programs started by rules may not mount file systems or use the network. Use /etc/fstab or systemd automount.

Key words

Kernel: the core of Linux that controls the hardware.
Device: a piece of hardware, real or virtual.
Driver: code that talks to one kind of device.
/dev: the folder of device files. /sys: where the kernel shows device details.
Event: the kernel's message that a device was added, removed or changed.
Rule: one line saying "if the device matches this, do that".
Attribute: a small fact about a device, such as its maker code.
Symlink: a shortcut file pointing to another file.
root, sudo: root is the administrator; sudo runs one command as root.

Quick summary

udev (systemd-udevd) receives kernel device events and applies rules: symlinks, permissions, network names.
Your rules go in /etc/udev/rules.d/, in files like 99-name.rules.
Find attributes with udevadm info -a; check with udevadm verify and udevadm test.
Apply with udevadm control --reload and udevadm trigger; keep long jobs and mounts out of rules.

Official documentation: udev(7), udevadm(8), systemd.link(5).

Ucartz services for this topic

KVM VPS hosting: NVMe SSD and full root access, with Free Basic Managed Support.
Unmanaged dedicated servers: full root access and free IPMI KVM, with Free Basic Managed Support.
Linux server management: hardening, patching, monitoring and automation for Ubuntu, Debian, RHEL and AlmaLinux.