udev 규칙 작성법, 장치 이름과 권한을 어떻게 고정하나

Short answer: In Linux systems, udev dynamically manages device nodes and permissions. By writing custom udev rules, you can safely fix device names and access permissions by creating specific symbolic links (SYMLINK+=) or automatically assigning the appropriate owner and permissions (GROUP=, MODE=) when specific hardware is connected.

This post covers only where userspace udev rule files live, how to use ATTR/KERNEL matching keys, and how to verify rules with udevadm.

Where do udev rules live?

Short answer: udev rule files live in fixed directories such as /usr/lib/udev/rules.d/ and /etc/udev/rules.d/, processed in lexicographic order, with /etc/udev/rules.d/ taking the highest priority.

udev rule files are located in directories like /usr/lib/udev/rules.d/, /usr/local/lib/udev/rules.d/, /run/udev/rules.d/, and /etc/udev/rules.d/.

The rules are sorted and processed in lexicographic order, and files with identical filenames replace each other.

Among these, /etc/udev/rules.d/ has the highest priority and is primarily used by administrators to override system default rules.

How do ATTR and KERNEL matching work?

Short answer: Identify a device with matching keys like KERNEL, ATTR, and SUBSYSTEM, then assign SYMLINK+=, GROUP=, MODE=, and similar directives to grant the desired name and permissions.

Use keys like KERNEL, ATTR{filename}, ATTRS (which walks up the parent device tree), and SUBSYSTEM to match the connected device’s characteristics.

Once a device matches, you can assign SYMLINK+=, GROUP=, MODE=, OWNER=, etc., to grant desired permissions or add a symbolic link with a fixed name.

Note that udev rules cannot change the name of the original device node itself; they can only create additional symbolic links.

How do you verify rules with udevadm?

Short answer: Find the attributes you need with udevadm info -a, pre-verify rules with udevadm verify and test, then confirm the real effect with control --reload-rules and trigger.

You can use udevadm info -a or --attribute-walk to walk up the parent device tree and find the necessary attributes (ATTR) for writing your rules.

Verify the syntax of your rules with udevadm verify or simulate their application with udevadm test <syspath>.

If you modify rules, use udevadm control --reload-rules (or -R) to reload them without restarting the daemon. Note that reloading does not immediately apply to already connected devices; you must run udevadm trigger to emit new events for those.

What do people commonly ask?

Question	Answer
Are there other ways to check device attributes besides udevadm info?	You can directly browse the /sys file system (sysfs) to read the contents of the attribute files for your desired device.

What’s the takeaway?

By clearly understanding how udev rules work and thoroughly verifying them with udevadm, you can prevent device recognition issues and stably manage access permissions in embedded systems or server environments.