根本原因是Oracle Universal Installer在预检查阶段需向%TEMP%、安装介质目录及ORACLE_BASE三个路径写入临时校验文件，任一路径缺少“完全控制”权限即触发硬性阻断错误INS-30131，日志中PRVF-7532即直接证据。
为什么setup.exe在Windows上提示“访问被拒绝”或报INS-30131
根本原因不是杀毒软件拦截，而是Oracle Universal Installer（setup.exe）在预检查阶段尝试向三个关键路径写入临时校验文件时，当前用户缺少完全控制权限。日志里高频出现的PRVF-7532: failed to create a temporary file in the specified location就是直接证据。
- 这三个路径分别是：
%TEMP%（或%TMP%，通常指向C:Users\AppDataLocalTemp）、安装介质所在目录（如D:oracle_installwinx64_11gr2_database）、以及你指定的ORACLE_BASE目录（如C:ppAdministratorproduct） - 只要其中任一路径权限不足，
setup.exe就会中断并抛出INS-30131，勾选“忽略全部”也无效——这不是警告，是硬性阻断 - 常见诱因包括：安装包解压到
C:根目录、用普通用户解压后未重置子目录继承权限、%TEMP%被策略重定向到只读网络位置
如何快速验证哪个路径权限异常
别猜，直接用系统自带工具验证。打开命令提示符（**必须以管理员身份运行**），逐条执行：
- 检查
%TEMP%是否可写：echo test > "%TEMP%ins_test.txt" && echo OK || echo FAIL
如果返回FAIL，说明%TEMP%不可写，立刻右键该文件夹 → “属性” → “安全” → 编辑当前用户的权限，勾选“完全控制” - 检查安装介质目录：
echo test > "D:oracle_install est_write.txt" && del "D:oracle_install est_write.txt"
若失败，需对该目录右键 → “属性” → “安全” → 给当前用户加“完全控制”，并勾选“替换子容器和对象的所有者” - 检查
ORACLE_BASE路径（如C:ppAdministrator）是否已存在且可写；若不存在，先手动创建该目录，再设权限——Installer不会自动建父目录
Linux下root.sh执行报“Permission denied”怎么办
这通常不是脚本没加执行权限，而是root.sh内部调用的二进制文件（如clscfg.bin、ohasd）因动态库缺失或路径错误导致加载失败，最终被shell误判为“权限拒绝”。典型表现是日志里夹杂libcap.so.1: cannot open shared object file或/bin/sh: /u01/app/11.2.0/grid/crs/install/root.sh: Permission denied。
- 先确认
root.sh本身有执行权：ls -l /u01/app/11.2.0/grid/crs/install/root.sh
正常应显示-rwxr-xr-x；若无x位，用chmod +x补上 - 真正要查的是它依赖的底层二进制：
ldd /u01/app/11.2.0/grid/bin/clscfg.bin | grep "not found"
常见缺失项是libcap.so.1，需手动软链：ln -sf /usr/lib64/libcap.so.2 /usr/lib64/libcap.so.1
- CentOS/RHEL 7+ 上还可能因
/etc/init.d/init.ohasd被systemd屏蔽而静默失败，此时root.sh会卡住并最终超时退出，看似权限问题，实则是服务注册缺失
容易被忽略的权限陷阱
很多人修完上述路径权限就以为万事大吉，结果在最后一步还是失败。最常漏掉的两点是：
-
ORACLE_HOME目录的属主必须是oracle用户，且不能是root；如果用root解压安装包再chown -R oracle:oinstall，要注意chown不递归修改符号链接目标的权限，某些版本的oraInst.loc会因此失效 - Windows下若安装路径含空格（如
C:Program FilesOracle）或中文字符，setup.exe内部调用的Java子进程会解析失败，错误表现为闪退或java.lang.NoClassDefFoundError，而非明确的权限提示——这种“伪权限错误”必须靠路径净化来解决
