rootcrs.sh -check 仅执行只读校验，不修复任何权限或属主；真正修复需先 rootcrs.pl -deconfig 清理，再 rootcrs.pl -init 重置核心文件权限，必要时重跑 root.sh。
直接说结论：rootcrs.sh -check 不修复权限，只做只读校验；它不会改任何文件属主或权限，也不能替代真正的修复流程。
Oracle 11g RAC（特别是 11.2.0.3+）中，一旦 GRID_HOME 下的二进制、脚本、配置文件权限或属主被篡改（比如误执行 chown -R grid:oinstall $GRID_HOME 或 chmod -R 757 $GRID_HOME），会导致 CRS 启动失败、oraagent_oracle 无法加载、资源卡在 STARTING 状态等——这时很多人第一反应是跑 rootcrs.sh -check，但这是个典型误解。
rootcrs.sh -check 实际行为与局限
- 它只是调用内部校验逻辑（类似
cluvfy comp software -n all -verbose的轻量版），输出“哪些文件权限/属主不合规”，不执行任何修改 - 输出示例中常见提示如：
File /u01/app/11.2.0/grid/bin/oraagent.bin has incorrect permissions (expected: 644, found: 757)
Directory /u01/app/11.2.0/grid/crs has incorrect ownership (expected: root:root, found: grid:oinstall)
- 即使加了
-verbose或-fix参数（某些版本伪支持），11g 中该脚本根本不响应-fix，也不会写入磁盘 - 它依赖当前 CRS 进程是否能通信；若
crsd已崩，-check往往直接报CRS-4535: Cannot communicate with Cluster Ready Services，连校验都做不了
真正有效的权限修复路径
必须分两步走：先恢复基础可启动状态，再按 Oracle 认可方式重置权限。
-
第一步：确保 CRS 能至少拉起
ohasd和crsd- 检查
/var/tmp/.oracle/npohasd是否存在且权限为prw-rw----（注意是 FIFO 文件，不是普通文件）；若属主错或权限过宽，用rm -f /var/tmp/.oracle/npohasd+mkfifo /var/tmp/.oracle/npohasd+chown root:root /var/tmp/.oracle/npohasd - 确认
$GRID_HOME/crs/install/rootcrs.pl -deconfig -force -verbose能干净卸载（需 root 执行），否则残留配置会干扰后续操作 - 清空临时 socket：
rm -f /tmp/.oracle/* /var/tmp/.oracle/* /usr/tmp/.oracle/*
- 检查
-
第二步：用 Oracle 提供的机制重置权限
- 11.2.0.3 及以后：运行
$GRID_HOME/crs/install/rootcrs.pl -init（注意是-init，不是-check）——它会重设关键二进制（如oraagent、orarootagent、crsctl）的属主和权限，但仅限 Oracle 认为“核心”的约 30 个文件 - 若
-init后仍有组件启动失败（如ora.mdnsd卡STARTING），说明非核心文件（如$GRID_HOME/mdns/lib下的 so、$GRID_HOME/gpnp/profiles/peer/profile.xml）权限也错了，此时必须手动还原备份或从正常节点同步 - 没有备份？唯一兜底方式是重新运行
root.sh（先-deconfig，再root.sh），但要求 OCR/Vote Disk 未损坏且网络配置仍有效
- 11.2.0.3 及以后：运行
容易被忽略的三个硬伤点
-
rootcrs.pl -init不会修复$GRID_HOME/log、$GRID_HOME/rdbms、$GRID_HOME/srvm下任意子目录权限，而这些目录里有大量被oraagent动态加载的脚本和库，权限错照样导致 agent 启动失败 - 属主错误比权限错误更致命：例如
oraagent_oracle必须属grid:oinstall，但它的父目录$GRID_HOME/bin必须属root:root；混用属主会触发 SELinux 拒绝或 setuid 失效 - 11g 中所有修复操作必须由 root 用户执行，且不能在
grid用户 session 下 sudo 切换——因为rootcrs.pl内部会检测真实 uid，sudo 会绕过关键环境变量校验
真正修复完后，用 crsctl check cluster -all 和 ps -ef | grep crsd 确认进程存活，再观察 crsctl stat res -t 是否全部 ONLINE；别只信 -check 的输出。
