udev规则不能直接实现自动挂载，仅负责设备节点管理；挂载需由udisks2、systemd-mount或自定义脚本配合完成，且必须先用udevadm获取设备唯一标识（如id_serial_short、id_vendor_id+id_model_id或id_fs_uuid）才能编写可靠规则。
udev 规则不能直接实现自动挂载，它只负责设备节点创建、命名和权限设置；挂载必须由其他机制（如 udisks2、systemd-mount 或自定义 RUN 脚本）配合完成。
怎么查清设备的唯一标识信息
不先拿到 vendor ID、product ID、serial 或 UUID，写的规则大概率匹配错设备或失效。别靠 ls /dev/sd* 猜，得用内核暴露的真实属性：
- 插上设备后立即运行
udevadm info --name=/dev/sdb --query=property（把/dev/sdb换成你实际看到的节点） - 如果设备还没被识别，用
udevadm monitor --subsystem-match=block --property监听热插拔事件，再插拔一次看输出 - 关键字段优先级：有
ID_SERIAL_SHORT就用它；没有就看ID_VENDOR_ID和ID_MODEL_ID组合；U 盘类存储设备更推荐用ENV{ID_FS_UUID}（需文件系统已存在）
怎么写一条可靠的 USB 存储设备固定命名规则
目标是让某块 U 盘无论插哪个口、重启几次，都映射为 /dev/myusb。注意这不是“重命名设备节点”，而是加 symlink：
- 规则文件放在
/etc/udev/rules.d/60-my-usb.rules（数字 60 避开系统默认规则） - 内容示例：
SUBSYSTEM=="block", ATTRS{idVendor}=="0781", ATTRS{idProduct}=="5567", SYMLINK+="myusb" - 别用
NAME覆盖内核名（如sdb），那会破坏系统其他依赖；SYMLINK+=是安全做法 - 测试前先重载规则：
sudo udevadm control --reload-rules，再触发事件：sudo udevadm trigger --subsystem-match=block - 验证是否生效：
ls -l /dev/myusb应该指向真实的/dev/sdX
为什么 RUN 执行挂载脚本容易失败
udev 进程在早期用户空间阶段运行，此时 /mnt 可能未挂载、网络未就绪、dbus 服务未启动，导致 RUN+="/path/to/mount.sh" 报错或静默失败：
- 常见错误现象：
mount: /mnt: wrong fs type, bad option, bad superblock或脚本根本没执行（查journalctl -u systemd-udevd） - 真正可行的做法是：用
ENV{ID_FS_UUID}匹配设备，然后通过systemd-mount提交一个单元（unit），例如：RUN+="/bin/sh -c 'systemd-mount --no-block --automount=yes /dev/disk/by-uuid/%E{ID_FS_UUID} > /dev/null 2>&1'" - 更稳妥的选择是放弃 udev RUN，改用
udisks2（桌面环境默认启用）或配置/etc/fstab+noauto,x-systemd.automount - 绝对不要在规则里写
mount /dev/sdb1 /mnt这类裸命令——没权限、路径不存在、设备忙都会卡住 udevd
权限与组设置最容易被忽略的点
即使设备有了固定 symlink，普通用户仍可能因权限不足无法读写：
- 仅设
MODE="0664"不够，必须同时指定GROUP="plugdev"或GROUP="disk"，并确保用户在该组中（usermod -aG plugdev $USER） - 串口设备（如
/dev/ttyUSB0）常见坑：规则写了ATTRS{idVendor}=="0403"，但没加SUBSYSTEM=="tty"，结果匹配不到——因为 USB 转串口设备在 sysfs 中属于tty子系统，不是usb - 规则中所有匹配键（
==）必须全部满足才触发；赋值键（=、+=）之间无顺序依赖，但RUN和SYMLINK建议分多行写，避免单行过长导致解析失败
真正难的不是写规则，而是确认设备在 sysfs 中到底暴露了哪些稳定属性，以及判断当前系统是否启用了 udisks2 或 systemd 的 automount 机制——盲目加 RUN 往往让问题更隐蔽。
