快速修复
# 一键:补执行位后直接运行
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 拷贝/压缩包解压/新创建的文件,执行位丢失。
原因
- Linux 用「执行位」决定能否直接运行文件;新文件默认
644(无执行位)。 ./script.sh走「直接执行」路径,需要 x 位;bash script.sh是「把文件当参数读」,不需要 x 位。- 从 Windows 复制(FAT/exFAT/网络盘)或 zip 解压常丢执行位;git 仓库里
core.fileMode配置不当也可能让 x 位丢失。
解法
- 补执行位:
chmod +x setup.sh
./setup.sh
- 不想改权限:显式用解释器
bash setup.sh/python3 app.py(对单次运行足够)。 - 批量:`chmod +x 站内文档。
- 预防: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 · 外部工具成套方案 (组合包)
这个问题包含在下列成套安装方案中。
来源与证据
素材来源:https://stackoverflow.com/questions/18960689/ubuntu-says-bash-program-permission-denied
← 编码代理与终端 问题域 | 问题货架 | 遇到其它问题?去 问题空间 提交求助卡