编码代理与终端 · 收录于 2026-08-29 · 适用 1 工具 ✓ 实测验证

bash: ./script.sh: Permission denied——脚本缺执行权限

已验证 2026-08-29bash: ./script.sh: Permission denied——脚本缺执行位,chmod +x 后运行。

快速修复

# 一键:补执行位后直接运行
chmod +x setup.sh && ./setup.sh

你会遇到什么

从 Windows 拷过来、或压缩包解压出来的脚本,执行 ./setup.sh 报 Permission denied,但 bash setup.sh 却能跑。你以为是文件坏了或系统拒绝执行——其实只是脚本少了执行位(x),Linux 的权限模型和 Windows 不一样。

本文路径:快速修复(30 秒一段命令)→ 一步步排查(可跳读)→ 原理与变体(症状/原因/证据)。赶时间直接跳到「快速修复」。

为什么会这样

Linux 用「执行位」决定一个文件能否被直接运行:

  • ./script.sh 走「直接执行」路径,内核要求文件有 x 位;
  • bash script.sh 是把文件当参数交给 bash 读取,不需要 x 位——所以同样一个文件,两种调用方式结果不同。

新创建的文件默认是 644(无执行位);从 Windows 复制(FAT/exFAT/网络盘)或 zip 解压经常丢执行位;git 仓库 core.fileMode 配置不当也可能让 x 位丢失。

实测环境:WSL Ubuntu,2026-08-29。

Linux 执行一个脚本有两条路径:./script.sh 走「直接执行」——内核检查文件有 x 位后,读 shebang 找解释器执行;bash script.sh 走「解释器读文件」——bash 只是把文件当参数读取,不检查执行位。所以同一个文件两种调用结果不同。

执行位是文件元数据(权限位),新建文件默认 644(无 x);从 Windows 复制(FAT/exFAT/网络盘不支持 POSIX 权限)或 zip 解压(zip 不存执行位)经常丢;git 检出丢 x 是 core.fileMode 配置不当。

确定性推论:Permission denied + 文件存在 = 缺 x 位,chmod +x 即修;WSL 挂载盘(/mnt/c)chmod 无效(drvfs 不支持)→ 复制进 WSL 文件系统再 chmod;zip 解压后统一 chmod +x;

git 里 x 位是版本化属性,git update-index --chmod=+x <file> 或修 core.fileMode;

判断路径:ls -l 看权限位,第一列无 x = 坐实。

一步步来

1. 确认是权限问题 — 必做

ls -l setup.sh

权限位是 -rw-r--r--(没有 x)→ 就是这个问题(实测:chmod 644 后 ./nox.sh 报 Permission denied,exit=126)。

2. 补执行位 — 必做

chmod +x setup.sh

3. 再运行 — 必做

./setup.sh

实测:chmod +x 后正常输出,exit=0。

4. 批量/预防 — 必做

chmod +x scripts/*.sh
  • git 提交前确认 git ls-files -s 显示 100755(可执行);
  • 解压 zip 后按需补 x;
  • Windows 挂载盘场景按需处理 core.fileMode(保持 true 通常更稳)。

怎么确认修好了

./setup.sh

不再报 Permission denied、能正常执行即成功(实测:bash nox.sh 也能跑,exit=0——不想改权限时显式用解释器调用即可)。

其它环境的表现

环境说明
WSL Ubuntu与原生 Linux 一致,补 chmod +x
Windows 拷贝的文件FAT/exFAT/网络盘不带执行位,拷入后必查必补
zip 解压unzip 后常丢 x 位,按需补
git 仓库core.fileMode=false 会让 x 位丢失不同步,保持 true
单次救急bash script.sh / python3 app.py 显式解释器调用,无需 x 位

症状

$ ./setup.sh
bash: ./setup.sh: Permission denied
  • ls -l 显示脚本权限是 -rw-r--r--(没有 x)。
  • 明明文件内容没问题、bash setup.sh 能跑,./setup.sh 却报 Permission denied。
  • 常见场景:从 Windows 拷贝/压缩包解压/新创建的文件,执行位丢失。

原因

  1. Linux 用「执行位」决定能否直接运行文件;新文件默认 644(无执行位)。
  2. ./script.sh 走「直接执行」路径,需要 x 位;bash script.sh 是「把文件当参数读」,不需要 x 位。
  3. 从 Windows 复制(FAT/exFAT/网络盘)或 zip 解压常丢执行位;git 仓库里 core.fileMode 配置不当也可能让 x 位丢失。

解法

  1. 补执行位:
   chmod +x setup.sh
   ./setup.sh
  1. 不想改权限:显式用解释器 bash setup.sh / python3 app.py(对单次运行足够)。
  2. 批量:`chmod +x 站内文档。
  3. 预防:git 提交前确认 git ls-files -s 里是 100755(可执行);解压 zip 用 unzip 后按需补 x;core.fileMode 保持 true(Windows 挂载盘场景按需处理)。
验证证据
  • 本机(WSL Ubuntu,2026-08-29):
  • 实测 1:chmod 644 + ./nox.sh → Permission denied,exit=126——与用户报错一致。
  • 实测 2:bash nox.sh → 正常输出,exit=0(解释器调用不需要 x 位)。
  • 实测 3:chmod +x + ./nox.sh → 正常,exit=0。
  • 实测复现日志(2026-08-29)

适用工具 (1)

本问题方案已挂到下列工具的方案页——从工具页也能回到这里,双向可达。

bash · 外部工具

成套方案 (组合包)

这个问题包含在下列成套安装方案中。

来源与证据

收录 验证 ✓ 实测验证适用 1 工具
方案含本地实测或来源可复核的解法;未实测项已在文中如实标注。

素材来源:https://stackoverflow.com/questions/18960689/ubuntu-says-bash-program-permission-denied

← 编码代理与终端 问题域 | 问题货架 | 遇到其它问题?去 问题空间 提交求助卡