立即用正常节点的getfacl -R备份权限，传至问题节点后先chown修正归属，再setfacl --restore恢复ACL；关键文件$GRID_HOME/bin/oracle和$ORACLE_HOME/bin/oracle必须为-rwsr-s--x（6751），最后验证crsctl check cluster及数据库启动。
chown -R 误改 /u01/app/oracle 或 $GRID_HOME 后，集群直接起不来怎么办
oracle rac 环境下，chown -r 是权限灾难的起点。一旦对 /u01/app/oracle 或 $grid_home 执行了递归修改，crsctl start crs 会卡在 “crs-4640: oracle high availability services is already active” 或干脆报 crs-2101: the olr was formatted using version 3 类错误——这不是服务没启，是底层校验直接拒绝加载。
关键点在于：Oracle 不只看 owner/group，还校验每个文件/目录的精确权限位、setuid/setgid 位、甚至 ACL。单纯 chown -R oracle:oinstall /u01/app/oracle 只修了归属，没动权限，而 chmod -R 775 /u01/app/oracle 又把二进制文件（如 oracle、crsctl）的执行位和 setuid 位全搞乱了。
- 目录必须是
775（不能755或777），否则 CRS 启动时校验失败 - 普通文件必须是
664（不是644），否则oraagent.bin加载失败 -
$GRID_HOME/bin/oracle和$ORACLE_HOME/bin/oracle必须是6751（含 setuid + sticky bit） -
$GRID_HOME/crs/install/rootcrs.sh --init在 12c+ 上可重置部分权限，但仅限于 CRS 核心组件，不覆盖 DB HOME 下的 bin/lib
用 getfacl + setfacl 从正常节点同步权限（最稳方案）
两节点 RAC 中，只要一个节点没动过，就别碰 rootcrs.sh --init 这种半吊子命令。直接拿它当“权限模板”最可靠。
在未改动的节点（比如 rac1）上执行：
getfacl -R /u01/app/oracle > /tmp/oracle_acl_rac1.txt getfacl -R $GRID_HOME > /tmp/grid_acl_rac1.txt
传到出问题的节点（rac2）后，先备份再恢复：
mkdir /tmp/bak_acl_$(date +%F) cp -r /u01/app/oracle /tmp/bak_acl_$(date +%F)/oracle_bak setfacl --restore=/tmp/oracle_acl_rac1.txt setfacl --restore=/tmp/grid_acl_rac1.txt
- 注意：如果
getfacl输出里含主机名或 SID，需用sed替换（如sed -i 's/rac1/rac2/g'），否则setfacl会静默失败 -
setfacl --restore不会覆盖当前 owner/group，所以得先用chown -R把归属拉回来，再跑 restore - 恢复后立刻验证：
ls -l $GRID_HOME/bin/oracle应显示-rwsr-s--x（即6751）
Oracle 19c 单实例下 chmod -R 搞崩安装目录的紧急修复
单实例没集群那么复杂，但 dbca 创建库时若提示 “not a valid Oracle Home” 或 ORA-01034: ORACLE not available，大概率是 $ORACLE_HOME 权限错乱。
Oracle 19c 安装后默认要求：
- 所有目录：严格
775—— 执行find $ORACLE_HOME -type d -exec chmod 775 {} \; - 所有普通文件：严格
664—— 执行find $ORACLE_HOME -type f -exec chmod 664 {} \; - 但以下 3 个文件例外，必须手动设为
6751：$ORACLE_HOME/bin/oracle、$ORACLE_HOME/bin/ldapbind、$ORACLE_HOME/bin/nmhs - 别碰
$ORACLE_HOME/lib下的 .so 文件——它们权限应为644，chmod -R会误改成664，导致监听无法加载 SSL 模块
为什么 rootcrs.sh --init 经常失效
这个脚本本质是读取 $GRID_HOME/crs/utl/crsconfig_fileperms 和 crsconfig_dirs 两个静态文件来还原权限。但它有硬伤：
- 只覆盖
$GRID_HOME/crs和$GRID_HOME/bin下的文件，不碰$GRID_HOME/lib或$GRID_HOME/network - 如果之前打过 PSU，
crsconfig_fileperms未必包含新补丁引入的文件 - 完全不管
$ORACLE_HOME—— 所以即使 CRS 起来了，DB 实例仍可能报ORA-27140: attach to post/wait facility failed - 执行前必须确保
$GRID_HOME/crs/install/rootcrs.sh可执行且属主为root:root，否则直接报 “Permission denied”
真正容易被忽略的是：权限修复不是“一次操作”，而是“归属 → 目录权限 → 文件权限 → 特殊位 → 验证启动”。少走一步，crsctl check cluster 就会停在 “CSS daemon” 那一栏不动。
