OUI-10036错误本质是oraInventory目录写入失败，主因包括目录归属非root、权限非775、writer.lock残留、SELinux拦截或路径不可访问，而非缺少脚本或未执行oraInstRoot.sh。
oui-10036 错误本质是权限写入失败，不是“缺脚本”或“没执行”，而是 orainventory 目录归属、权限或锁状态不满足 oui 的写入要求。以 root 执行 orainstroot.sh 只是常见修复手段之一，但不是万能解法——它只解决“目录属主/权限未正确初始化”的场景，对锁冲突、路径不可写、selinux 限制等情况完全无效。
oraInstRoot.sh 到底做了什么
该脚本由 OUI 在安装前期自动生成（通常位于 /tmp/OraInstall*/oraInstRoot.sh），核心动作只有两个：
- 把
oraInventory目录（如/u01/app/oraInventory）的属主改为root:oinstall - 把目录权限设为
775，确保oinstall组成员（如oracle用户）可读写
它不会删除锁文件、不修改 /etc/oraInst.loc、不处理 SELinux 上下文、也不校验磁盘空间或挂载选项。如果 oraInstRoot.sh 已执行过，再次运行不会改变现状；若执行时报错（如 “No such file or directory”），说明 OUI 根本没走到生成该脚本的阶段，问题出在更早环节。
OUI-10036 真实原因排查顺序
别急着找 oraInstRoot.sh，先确认以下四点：
-
/etc/oraInst.loc文件是否存在？内容是否指向一个真实、可访问的路径？例如：inventory_loc=/u01/app/oraInventory且该路径ls -ld /u01/app/oraInventory不报 “No such file” -
oracle用户能否在该路径下创建文件？测试：sudo -u oracle touch /u01/app/oraInventory/test_write—— 若失败，才是权限问题 -
/u01/app/oraInventory/locks/writer.lock是否存在？存在即表示有残留锁，需手动删（前提是确认无其他 OUI 进程在运行） - SELinux 是否启用？
getenforce返回Enforcing时，即使权限全开也可能被拦截；临时验证可setenforce 0，生产环境应改上下文而非关闭
chmod/chown 常见错误操作
很多人直接对 oraInventory 目录执行 chmod -R 777 或 chown -R oracle:oinstall，这反而会触发 OUI 拒绝写入：
- OUI 要求
oraInventory属主必须是root（组可为oinstall），否则报 OUI-10036 或 OUI-10024 -
chmod -R 777会让子目录权限失控，OUI 启动时会校验并拒绝继续 - 正确做法是仅对顶层目录设
775，且确保oracle用户在oinstall组内（id oracle可验证）
最易被忽略的是：OUI 安装过程中若被中断（比如 Ctrl+C、X Window 关闭、SSH 断连），writer.lock 很可能残留，而进程已消失，ps 查不到。此时手动清理 locks/ 目录比反复执行 oraInstRoot.sh 有效得多。
