如何修复Oracle安装过程中目录权限设置失败_通过chown命令递归修改-Oracle-PHP中文网

立即用正常节点的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 权限错乱。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

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”