./script.sh 报 permission denied 的根本原因是文件缺少执行权限位（x），即使脚本语法正确、路径无误，linux 也仅依据权限位决定是否允许执行；需同时满足：文件自身有 x 权限（如 chmod u+x script.sh）、首行含正确 shebang（如 #!/bin/bash）、文件系统未以 noexec 挂载（如 fat32/ntfs 分区）。
直接给脚本加 chmod u+x 就能运行，但必须同时满足三个条件：权限位有 x、脚本首行有正确 #!/bin/bash（或类似 shebang）、文件系统支持权限位（比如不能是挂载的 FAT32 或 NFS 的 noexec 选项）。
为什么 ./script.sh 报 Permission denied？
Linux 不看后缀名，只认权限位里的 x。用 ls -l script.sh 查看，如果输出开头是 -rw-r--r--，说明压根没执行权限——x 缺失就是根本原因。
- 报错不是因为没写对路径，也不是因为脚本语法错，而是系统在启动前就拒绝了执行请求
- 即使脚本内容完全合法，没有
x权限也绝不会进入解释器 -
bash script.sh能跑，是因为你手动调用了bash进程去读取并执行它，绕过了文件自身权限检查
chmod u+x 和 chmod +x 有什么区别？
chmod u+x 只给文件所有者加执行权限；chmod +x 等价于 chmod a+x，会给所有用户（所有者、组、其他人）都加 x，安全性更低。
- 日常开发中推荐用
chmod u+x script.sh，符合最小权限原则 - 如果脚本要被同组用户运行，用
chmod ug+x script.sh - 用数字模式时，
chmod 755 script.sh是常见安全配置（所有者 rwx，组和其他人 rx） - 千万别用
chmod 777，尤其当脚本里含密码或敏感路径时
加完权限还不能运行？重点排查这三点
权限加了、ls -l 看到 x 了，但 ./script.sh 仍失败，问题大概率出在这：
- 脚本第一行缺失或写错 shebang，例如写成
#!/bin/sh但系统里实际是/usr/bin/bash，或路径拼错（如#!/bin/basg） - 文件保存在不支持 Unix 权限的文件系统上（比如挂载的 Windows 分区、U 盘 FAT32、某些 NFS 配置启用了
noexec） - 脚本本身有 DOS 换行符（
\r\n），导致解释器找不到 shebang 行，报错类似bad interpreter: No such file or directory
临时绕过权限限制的替代方式
当你无法修改权限（比如只读挂载、无权改属主），或只是快速测试脚本逻辑，可以用解释器显式调用：
-
bash script.sh—— 最常用，不依赖x权限，也不依赖 shebang -
sh script.sh—— 注意：sh是 POSIX shell，不支持[[、source等 bash 特性 -
/usr/bin/env bash script.sh—— 更健壮的 shebang 替代方案，适合跨平台分发脚本
这些方式能跑通，不代表权限设置可以跳过。工程化部署、定时任务、CI 流水线等场景，仍必须用 chmod u+x 并验证 ./script.sh 可直接执行——否则上线后容易静默失败。
