Ubuntu Server中脚本内执行chmod a+x无效，运行脚本遭权限拒绝

你遇到的这个问题确实有点让人困惑——明明ls -l显示update.sh已经是-rwxrwxrwx的全权限，主脚本里也执行了chmod a+x，但就是无法运行。结合Ubuntu Server 20.04的环境，我给你梳理几个最可能的原因和解决方案：

1. 检查/test分区的挂载属性 #

最常见的元凶是/test所在的分区被挂载时添加了noexec（禁止执行）属性。这个属性会直接忽略文件的执行权限设置，哪怕你给了rwx也没用。

怎么验证？ #

运行这条命令查看分区挂载参数：

mount | grep /test

如果输出里能看到noexec字样，那就是它的问题了。

怎么解决？ #

• 临时修复（重启后失效）：

sudo mount -o remount,rw,exec /test

• 永久修复：编辑/etc/fstab文件，找到对应/test的挂载行，删掉noexec参数，保存后执行sudo mount -a让修改生效。

2. 调整unzip的解压参数 #

有时候unzip工具默认不会保留原始文件的权限设置，哪怕你之后手动加了chmod，也可能因为某些隐藏的权限问题导致执行失败。你可以试试给unzip加上-X参数，强制保留原文件的权限和属性：

把主脚本里的unzip命令改成：

unzip -o -X update-file.zip

这个参数会让解压后的文件完全继承压缩包里的权限，可能解决权限不生效的问题。

3. 显式指定Shell运行脚本 #

有时候即使权限没问题，shebang行（就是脚本开头的#!/bin/bash）也可能因为某些原因无法被正确解析。你可以试试在主脚本里不用直接运行update.sh，而是显式调用bash来执行它：

替换主脚本里的运行命令：

# 原来的：/test/update/update.sh
bash /test/update/update.sh

这样相当于让bash主动读取并执行脚本内容，绕开了系统对脚本文件本身的执行权限检查（本质是bash有执行权限，它去处理脚本内容）。

4. 检查文件系统完整性 #

极端情况下，文件系统损坏可能导致权限显示和实际生效不一致。你可以尝试修复文件系统（注意要先卸载分区，或者进入单用户模式操作）：

sudo umount /test
sudo fsck /dev/[你的分区设备名]

比如/test对应的设备是/dev/sda3，就运行sudo fsck /dev/sda3，修复可能存在的文件系统错误。

内容的提问来源于stack exchange，提问作者Floating Sunfish