Oracle RAC共享存储设备权限重启丢失的根本原因是udev动态生成设备节点时未固化属主、组和权限；必须基于WWID编写udev规则，显式设置OWNER="grid"、GROUP="asmadmin"、MODE="0660"，并确保双节点规则一致、WWID相同、grid用户UID/GID统一。
Oracle RAC共享存储设备权限为什么每次重启就丢失？
因为linux内核加载多路径设备或scsi设备时，设备节点（如 /dev/mapper/mpathb）的属主和权限由udev动态生成，而默认规则不保留oracle所需的 grid:asmadmin 权限。手动用 chown 或 chmod 临时生效，重启后失效是必然结果。
真正要解决的是：让udev在设备发现阶段就固化属主、组、权限，且规则匹配稳定不漂移。
- 别用
/dev/sdb这类易变路径写规则——热插拔、多路径切换后设备名可能变成/dev/sdc - 优先基于WWID（World Wide Identifier）或UUID匹配，例如从
scsi_id -g -u -d /dev/sdb或blkid -o export /dev/mapper/mpathb获取唯一标识 - 确保
/etc/udev/rules.d/99-oracle-asm.rules文件存在且权限为644，属主为root:root
udev规则里该用 OWNER 还是 GROUP？ASM磁盘组要求是什么？
Oracle ASM要求磁盘设备节点属主为 grid 用户、属组为 asmadmin（或 asmdba），且权限至少为 0660。仅设 GROUP 不够——OWNER 必须显式指定，否则默认是 root，ASM实例启动会报 ORA-15018: diskgroup cannot be created 或挂载失败。
正确写法示例（以多路径设备为例）：
KERNEL=="dm-*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="3600507680281006e4a00000000000012", OWNER="grid", GROUP="asmadmin", MODE="0660"
-
PROGRAM调用scsi_id获取WWID，RESULT匹配输出值，比用SYSFS{wwid}更兼容RHEL 7+/OL 7+内核 - 不要漏掉
SUBSYSTEM=="block"，否则规则可能误匹配到非块设备 -
MODE="0660"是最小安全权限；设成0640会导致ASM无法写入磁盘头
udev规则生效后磁盘权限仍不对，怎么快速定位？
执行 udevadm trigger 不一定立即更新设备节点权限——它只触发事件，不重载规则或重新计算属性。必须先重载规则再触发，且确认设备当前状态是否被匹配。
- 运行
udevadm control --reload-rules确保新规则已载入 - 用
udevadm info --query=all --name=/dev/mapper/mpathb | grep -E "(OWNER|GROUP|MODE)"查看当前应用的属性值，不是看ls -l结果 - 如果输出为空，说明规则根本没匹配上：检查
RESULT值是否与scsi_id实际输出一致（注意空格、大小写、前导零） - 强制重新应用：先
echo 1 > /sys/block/dm-1/device/delete（替换为对应设备），再执行udevadm trigger --subsystem-match=block
RAC双节点udev规则要完全一样吗？有什么隐性依赖？
是的，两个节点的 99-oracle-asm.rules 内容必须逐字相同，包括注释行。但更关键的是：两节点看到的同一LUN的WWID必须一致，否则规则在某节点不生效。
常见陷阱：
- 存储端未开启ALUA或多路径策略不一致，导致节点A看到WWID是
360050768...，节点B看到的是360050769... - 使用了不同版本的多路径软件（如节点A是
device-mapper-multipath-0.4.9，节点B是0.5.0），scsi_id输出格式微调，导致RESULT匹配失败 -
grid用户UID/GID 在两节点不一致（例如节点A的gridUID=54321，节点B是54322），即使规则生效，OWNER也会映射错人
验证方法：在两节点分别运行 scsi_id -g -u -d /dev/sdb 和 id -u grid; id -g grid，结果必须完全一致。
