应使用chmod u+x而非chmod 777为configure或.sh脚本添加执行权限，因其默认无x位导致Permission denied，仅需赋予属主执行权即符合最小权限原则且避免安全风险。
直接给 configure 或 .sh 文件加执行权限，不是 chmod 777，而是 chmod u+x。OpenJDK 源码包里的 configure、get_source.sh 等脚本默认没有 x 位，Linux 不允许直接运行，报 Permission denied 是正常现象，跟 SELinux、挂载选项或用户权限无关——先别急着切 root 或改 ownership。
为什么 ./configure 报 Permission denied
因为 Linux 要求可执行文件必须有执行权限（x），而 OpenJDK 官方源码包解压后，configure 是普通文件（权限通常是 -rw-r--r--），shell 不会尝试用 /bin/sh 去解释它，而是直接拒绝执行。
- 这不是路径错误，也不是环境变量问题，
ls -l configure一眼就能确认：第三位没x -
bash configure可能成功，但这是绕过权限检查的“伪解决”，不符合构建流程预期，后续make阶段仍可能失败 - 不要用
chmod 777 configure——开放所有权限既无必要，又埋下安全风险
正确加执行权限的命令和范围
只给当前用户加执行权，最小权限原则：
- 单个脚本：
chmod u+x configure - 同目录所有 shell 脚本：
chmod u+x *.sh - 如果还有
autogen.sh或get_source.sh，同样处理：chmod u+x autogen.sh get_source.sh - 不需要
-R，OpenJDK 构建脚本不依赖子目录里其他文件的 x 权限
常见连带错误和干扰项
加完 x 还报错？大概率是别的问题混进来了：
-
./configure: line 1: /bin/bash: No such file or directory→ 系统没装 bash，或脚本首行#!/bin/bash路径不对；改用#!/usr/bin/env bash或装 bash -
configure: error: no acceptable C compiler found→ 缺少build-essential（Debian/Ubuntu）或@development-tools（RHEL/CentOS），和权限无关 - 用
sudo ./configure后提示找不到java或gcc→sudo重置了$PATH，应改用sudo -E ./configure保留环境变量 - 解压时用了
tar -xzf但源码包本身是 zip 格式 → 实际得到的是未解压的 zip 文件，ls -l会显示大小异常，别被文件名骗了
真正卡在 Permission denied 的，90% 就是缺 x 权限；剩下 10%，往往是因为把 configure 当成二进制去 chmod 777，结果触发了某些发行版的 strict mode 检查，反而更难排查。
