OUI-10036报错本质是oraInventory写入失败，oraInstRoot.sh仅修复属主（root:oinstall）和权限（775），不处理writer.lock残留、SELinux拦截、路径不存在或oracle用户不在oinstall组等问题。
orainstroot.sh不是万能钥匙，它只解决orainventory目录归属和权限初始化问题；oui-10036报错时，先验证写入能力比急着执行脚本更重要。
为什么执行orainstRoot.sh后OUI-10036还在报
因为OUI-10036本质是写入失败，而oraInstRoot.sh只做两件事：把/u01/app/oraInventory属主设为root:oinstall、权限设为775。它不碰锁文件、不改SELinux上下文、不校验路径是否真实存在。常见失效场景包括：
-
/etc/oraInst.loc里写的inventory_loc路径根本不存在，或拼写错误（比如/u01/app/oraInvenotry） -
/u01/app/oraInventory/locks/writer.lock残留且没被清理，OUI启动时拒绝覆盖 - SELinux处于
Enforcing模式，setenforce 0临时关闭后能过，说明是上下文拦截 -
oracle用户不在oinstall组里，id oracle查不到oinstall
执行orainstRoot.sh前必须确认的三件事
别直接sudo ./oraInstRoot.sh，先手工验证基础条件是否满足：
- 运行
ls -ld /u01/app/oraInventory，确认目录存在且当前输出中用户是root、组是oinstall - 运行
sudo -u oracle touch /u01/app/oraInventory/test_write && rm /u01/app/oraInventory/test_write，测试oracle用户能否真正写入 - 检查
/u01/app/oraInventory/locks/下是否有writer.lock，有就rm -f（前提是确认无其他OUI进程在跑）
chmod/chown操作最容易踩的坑
OUI对oraInventory的权限要求非常刚性，乱用-R反而触发校验失败：
- 只对顶层目录设权限：
chmod 775 /u01/app/oraInventory，不要chmod -R 775——子目录权限失控会导致OUI拒绝继续 - 属主必须是
root，不能是oracle或grid；组可以是oinstall，但用户字段必须为root - 如果误执行了
chown -R oracle:oinstall /u01/app/oraInventory，OUI会报OUI-10024或静默退出，必须重置为root:oinstall
oraInstRoot.sh执行成功与否的唯一判断标准
看脚本输出末尾有没有Successfully changed permissions of the Oracle Inventory directory.这行字。不要只看“completed successfully”这种模糊提示——很多情况下脚本看似跑完，但实际卡在某个校验点上，日志里却没报错。更可靠的方式是执行完立刻运行：
ls -ld /u01/app/oraInventory id oracle | grep oinstall
两者都符合才真正过关。真正卡住的地方往往不是脚本没运行，而是OUI在后台比对了oraInventory下至少17个固定子路径的权限、锁状态、SELinux上下文，任何一项不满足硬编码规则，它就停在那里，连错误码都懒得打全。
