我把一个刚写完的予文部署脚本拖到服务器上，执行 ./deploy.sh，行权限系统甩回来一句 Permission denied。予文这种时刻总让人火大——明明文件就在那儿，行权限内容也没问题，予文偏偏系统不让你碰。行权限其实Linux早就把答案写在脸上了：文件权限里没有执行位（x）。予文

在Linux里，行权限执行权限和读写权限完全是予文两码事。读权限让你能看内容，行权限写权限让你能改内容，予文但执行权限意味着“允许系统把这个文件当作程序来运行”。行权限Windows下双击.exe就完事，予文Linux却把“能不能跑”这个决定权拆成了三组：属主、行权限属组、予文其他人。每个文件头顶都挂着-rwxr-xr-x这种十位字符，第一位是文件类型，后面九位每三位一组，分别对应属主（u）、属组（g）和其他人（o）。

给脚本加执行权限，最直白的方式是chmod +x deploy.sh。这个命令只加执行位，不动已有权限，像给门锁多配了一把钥匙。如果你手头有个编译好的二进制程序app，同样适用——chmod +x app之后，./app就能跑起来。但有个坑：脚本文件的第一行必须写#!/bin/bash或#!/usr/bin/env python3之类的shebang，否则系统不知道用哪个解释器来执行，加了x也白搭。

数字表示法更精确，也更常见于运维脚本里。chmod 755 script.sh意味着属主有rwx（7=4+2+1），属组和其他人只有r-x（5=4+1）。这种写法适合给所有人读和执行的权限。但如果你只想让自己能跑，别人只能看，那就chmod 700。我见过不少新手把chmod 777挂嘴边，图省事让所有用户都能读写执行——这等于把家门钥匙复制给整栋楼的住户，迟早出事。

说个真实案例。上个月我帮朋友排查一个线上服务，日志里反复出现exec format error。查了半天发现，他把Windows下编辑的脚本直接传到了Linux服务器，文件开头带着\r\n换行符，shebang被解析成#!/bin/bash\r，系统找不到这个解释器。加上执行权限也没用，因为问题根本不在于权限，而是文件编码。后来用sed -i 's/\r$//' script.sh清理掉回车符，再chmod +x，服务立刻正常。

还有个细节容易被忽略：挂载分区时如果带了noexec选项，哪怕文件权限是-rwxr-xr-x，执行也会被拒绝。比如/etc/fstab里写了noexec，你在这个分区下放任何可执行文件都跑不起来。这种限制常见于安全加固过的服务器，或者某些临时挂载点。遇到这种情况，别急着改权限，先mount看看有没有noexec标记。

执行权限的粒度也值得琢磨。你可以只给属主加执行位：chmod u+x file，这样只有你自己能运行，组内成员和其他用户都不行。或者反过来，只给其他人加执行位：chmod o+x file，让别的用户能跑，但你自己反而不能——这听起来反直觉，却偶尔用在某些共享程序的场景里。不过说实话，日常工作中+x和755两种用法覆盖了九成需求。

最后提一句，目录的执行权限和文件不太一样。目录的x位代表“能否进入这个目录”，没有它，即使你有读权限也cd不进去。所以当你chmod -x一个目录时，用户会发现自己被挡在门外，连ls都执行不了。这算是Linux权限体系里最容易踩的坑之一。

权限这东西，本质上是对“谁可以做什么”的精确控制。下一次再碰到Permission denied，先别急着骂系统，跑一句ls -l看看那个文件，答案就在权限位里写着。