How to Add Udev Rules in Linux
If you want to know how to add udev rules in linux, the process is straightforward: identify the device attributes you want to match, create a rule file in /etc/udev/rules.d/, reload the rules, and test the rule with udevadm. Udev rules are commonly used to set permissions, create stable device names, or assign a custom symlink without editing system files by hand each time a device appears.
What udev rules do
Udev is the Linux device manager that reacts when hardware is added, removed, or changed. A udev rule tells the system what action to take when a device matches certain conditions. That can include setting ownership, changing permissions, creating a symlink, or running a helper script.
They are useful when device names change between boots or when you want non-root users or specific groups to access a device reliably. For example, a USB serial adapter might appear as /dev/ttyUSB0 one time and /dev/ttyUSB1 another time. A udev rule can create a stable name such as /dev/my_adapter.
Where to add udev rules in Linux
Custom rules normally belong in /etc/udev/rules.d/. This location is intended for local changes and overrides packaged rules. Files in this directory should end in .rules.
Some systems also have distribution-provided rules in /usr/lib/udev/rules.d/ or /lib/udev/rules.d/, depending on the distro layout. In general, do not edit those files directly unless you are sure they are meant to be changed. Put your custom rule in /etc/udev/rules.d/ instead.
Rule order matters. Numeric prefixes help control when a rule runs. For example, 60-custom.rules runs before 99-local.rules if both apply to the same event. If you are overriding or refining another rule, choose a filename that makes sense in the ordering.
How udev rule syntax works
Udev rules use comma-separated matches and assignments. A rule usually looks like this:
KEY=="value", KEY="value", KEY+="value"The most important distinction is between matching and assigning:
- Match keys use
==to compare values. - Assignment keys use
=or+=to set values.
Common match keys include:
KERNEL, to match the device nameSUBSYSTEM, to match the device subsystemATTR, to match attributes of the current deviceATTRS, to match attributes of parent devicesENV, to match environment variables
Common assignment keys include:
NAME, for naming a device node in limited casesSYMLINK, to create an additional stable pathOWNER, to set file ownerGROUP, to set file groupMODE, to set permissionsRUN, to run a helper command when the rule matches
For most custom device workflows, SYMLINK, GROUP, and MODE are safer and more practical than trying to rename the kernel device node directly.
Find the right device attributes
The most common mistake is writing a rule before you know which attributes are stable enough to match. Use udevadm to inspect the device first.
1. Identify the device path
If you already know the device node, such as /dev/sdb1 or /dev/ttyUSB0, you can inspect it directly. If not, use tools like lsblk, blkid, or dmesg to find it.
2. Inspect udev properties
Run:
udevadm info -a -n /dev/ttyUSB0This prints attributes for the device and its parent devices. The output is long, so look for fields that are unique and stable, such as vendor ID, product ID, serial number, or a hardware path.
3. Choose stable match keys
Prefer attributes that do not change between reboots or ports. A serial number is often better than a device number that can change. A USB vendor and product ID may be enough if only one device of that type is present, but a serial number is stronger when available.
| Match key | Use it for | Notes |
|---|---|---|
KERNEL | Device name patterns | Can change across boots for many devices |
SUBSYSTEM | Filtering by class of device | Often used with other keys |
ATTR | Current device attributes | Matches only the device itself |
ATTRS | Parent device attributes | Useful for USB and bus-connected hardware |
ENV | Existing udev properties | Good for values already exported by udev |
ATTR versus ATTRS
ATTR matches an attribute of the device currently being processed. ATTRS matches an attribute on a parent device in the device tree. This distinction matters a lot for USB hardware, where the value you need may belong to a parent rather than the final device node.
If a rule does not match when you expect it to, the issue is often that the attribute is on a parent device and you used ATTR instead of ATTRS, or the reverse.
Create and save the rule file
Once you know the correct match criteria, create a rule file in /etc/udev/rules.d/. A common practice is to use a descriptive filename with a numeric prefix, such as 60-my-device.rules.
Example rule that creates a stable symlink for a USB serial device:
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="my_serial_device", GROUP="dialout", MODE="0660"This example does three things:
- Matches devices in the
ttysubsystem - Checks USB vendor and product IDs on a parent device
- Creates
/dev/my_serial_deviceand sets access permissions
Save the file as:
/etc/udev/rules.d/60-my-device.rulesBe careful with quoting and spacing. Udev rule syntax is strict, and a small typo can prevent the rule from working.
Reload and test the rule
After creating or editing a rule, reload the udev rules so the system reads the new file:
sudo udevadm control --reload-rulesReloading does not always reprocess devices by itself, so you usually need to trigger the device or reconnect it.
Trigger the rule
If the device is removable, unplug it and plug it back in. For devices that cannot be unplugged easily, you can trigger the device manually:
sudo udevadm trigger --subsystem-match=ttyYou can also target a specific device path when needed, but a broad trigger may affect multiple devices, so use it carefully.
Verify the result
Check whether the symlink, permissions, or ownership changed as expected:
ls -l /dev/my_serial_deviceIf you want to confirm what udev sees for the device, inspect it again with:
udevadm info -a -n /dev/ttyUSB0For deeper debugging, you can monitor events while reconnecting the device:
udevadm monitor --udev --environmentThis helps you see whether the device event is actually reaching udev and whether the properties you expected are present.
Example udev rules
Here are a few practical examples of how to add udev rules in linux for common tasks.
Create a stable symlink for a USB drive
KERNEL=="sd?1", ENV{ID_FS_UUID}=="1234-ABCD", SYMLINK+="usb_backup"This creates a predictable link for a partition with a known filesystem UUID. For storage devices, matching on filesystem UUID is often safer than device names such as sdb1.
Set permissions for a serial device
SUBSYSTEM=="tty", KERNEL=="ttyUSB0", GROUP="dialout", MODE="0660"This lets members of the dialout group access the device without changing permissions manually after each reboot. If the device number can change, replace KERNEL with a more stable attribute match.
Allow access to a specific USB peripheral
SUBSYSTEM=="usb", ATTR{idVendor}=="abcd", ATTR{idProduct}=="1234", MODE="0664", GROUP="plugdev"This is useful for a USB device where you want controlled non-root access. Make sure the subsystem and attribute level are correct for the event you are matching.
Common mistakes and fixes
If your rule does not work, the problem is usually one of a few predictable issues.
| Problem | Likely cause | What to do |
|---|---|---|
| Rule never fires | Wrong subsystem or attribute level | Check udevadm info -a and confirm ATTR versus ATTRS |
| Rule loads but has no effect | Filename order or syntax problem | Use a numeric prefix and verify commas, quotes, and operators |
| Wrong device gets matched | Match criteria too broad | Add a serial number or a more specific attribute |
| Symlink appears and disappears | Device reconnects or multiple rules conflict | Check for competing rules in other rule files |
| Permissions still look unchanged | Rule targeted the wrong node | Confirm the event path and inspect the final device node, not just the parent |
Other useful checks:
- Make sure the rule file ends with
.rules - Confirm you reloaded rules after editing
- Reconnect the hardware or trigger the correct subsystem
- Look for conflicting packaged rules in
/usr/lib/udev/rules.d/or/lib/udev/rules.d/
Safe checklist before you rely on a new rule
- Identify the device with
udevadm info -a - Choose stable match keys, preferably serial numbers or unique IDs
- Put the rule in
/etc/udev/rules.d/ - Use a clear filename with a numeric prefix
- Reload rules with
udevadm control --reload-rules - Trigger or reconnect the device
- Verify the symlink, owner, group, or mode
How to choose the right rule approach
Not every device needs a complex rule. If your only goal is persistent identification, a symlink based on a stable attribute may be enough. If your goal is access control, changing GROUP and MODE is usually cleaner than running a command after every attach event.
Use the simplest rule that solves the problem. Shorter rules are easier to debug, and they are less likely to break when hardware changes.
Frequently Asked Questions About how to add udev rules in linux
Where do I put udev rules in Linux?
Put custom rules in /etc/udev/rules.d/. That location is meant for local changes and overrides.
How do I reload udev rules after editing them?
Run sudo udevadm control --reload-rules, then reconnect the device or trigger it manually so the new rule is applied.
How can I test if a udev rule works?
Use udevadm info -a -n /dev/device to inspect attributes, then monitor events with udevadm monitor --udev --environment while you reconnect the device.
What is the difference between ATTR and ATTRS in udev?
ATTR matches attributes of the current device, while ATTRS matches attributes on parent devices. If the value you need is not on the final node, ATTRS is often the correct choice.
How do I find the right device attributes for a udev rule?
Use udevadm info -a -n /dev/device and look for stable properties such as vendor ID, product ID, serial number, or filesystem UUID. Match on values that are unlikely to change.
Why does my udev rule not work after I save it?
The most common reasons are a syntax error, the wrong attribute level, a filename ordering issue, or forgetting to reload the rules. Recheck the file, reload, and retest the device event.
Conclusion
Adding udev rules in Linux is mainly a matter of three steps: inspect the device, write a precise rule in /etc/udev/rules.d/, and reload plus test it. If you match on stable attributes and keep the rule simple, you can reliably create persistent device names, set permissions, or assign ownership without manual intervention.
When in doubt, start with udevadm info, keep the match conditions specific, and verify the result after reloading. That approach prevents most of the common mistakes and makes your rule much easier to maintain.