根本原因是udev未在设备发现阶段固化owner/group/mode，必须用scsi_id获取wwid编写规则；/dev/sdx会漂移，而wwid是存储侧唯一标识，需确保rac双节点scsi_id输出完全一致、规则匹配成功且权限生效。
重启后ASM磁盘权限丢失，不是配置没生效，而是udev根本没在设备发现阶段固化OWNER、GROUP和MODE——手动chown或chmod只作用于当前节点当前时刻的/dev/sdX，而该设备名下次启动可能指向另一块物理盘。
为什么chown grid:asmadmin /dev/sdX重启就失效
Linux内核加载SCSI或多路径设备时，/dev/sdX或/dev/mapper/mpathb是动态生成的节点，其属主、组、权限由udev规则决定。默认规则不设置这些字段，所以每次设备重发现都会回退到root:root、0600。更危险的是：/dev/sdc今天是OCR盘，明天可能是归档盘，RAC双节点上设备名不同步会直接导致CRS无法启动。
必须用scsi_id匹配WWID写udev规则
设备名会漂移，但SCSI设备的WWID（World Wide Identifier）是存储侧写死的唯一标识，scsi_id -g -u -d /dev/sdX输出值（如3600507680281006e4a00000000000012）才是稳定锚点。规则里不能用SYSFS{wwid}——RHEL 7+/OL 7+内核已不保证该属性可靠，必须用PROGRAM调用scsi_id实时获取。
- 先确认裸盘：运行
fdisk -l /dev/sdf，输出必须含Disk /dev/sdf doesn't contain a valid partition table - 取WWID：在所有RAC节点执行
/usr/lib/udev/scsi_id -g -u -d /dev/sdf，结果必须完全一致（含空格、大小写、前导零） - 规则位置固定为
/etc/udev/rules.d/99-oracle-asmdevices.rules，权限644，属主root:root - 规则内容示例：
KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$name", RESULT=="3600507680281006e4a00000000000012", OWNER="grid", GROUP="asmadmin", MODE="0660"
规则写了但权限还是不对？立刻检查这三点
规则文件存在≠规则生效≠规则匹配成功。常见断点不在语法，而在状态验证环节。
- 重载规则再触发：
udevadm control --reload-rules && udevadm trigger --subsystem-match=block，缺一不可 - 查实际应用属性：
udevadm info --query=all --name=/dev/mapper/mpathb | grep -E "(OWNER|GROUP|MODE)"，不是看ls -l结果——后者显示的是上次设置的残留 - 若输出为空，说明规则根本没匹配上：重点核对
RESULT值是否与scsi_id输出**逐字一致**，包括开头空格、结尾换行（可用scsi_id ... | od -c查）
别碰ASMLib，也别信oracleasm scandisks
Oracle 19c已彻底弃用ASMLib，任何残留都会干扰ASMFD设备识别。如果lsmod | grep oracleasm有输出，或kfed read /dev/mapper/mpathb报KFED-00322，说明磁盘头已被ASMLib污染——此时oracleasm scandisks不仅无效，还会让ASM实例持续尝试加载错误路径。必须先rmmod oracleasm，再清空udev中所有含oracleasm的规则文件，最后用asmcmd afd_lsdsk确认AFD识别状态。
真正难的不是写对一行udev规则，而是确保RAC所有节点的scsi_id输出、udevadm info输出、asmcmd lsdsk输出三者完全一致——差一个空格，集群就起不来。
