Linux 提示 Permission denied，先别急着 chmod 777

在 Linux 上部署网站或跑脚本，碰到 Permission denied 很常见。直接把目录改成 777 虽然省事，但也把写权限给了所有本地用户，不适合当成默认解决办法。可以按下面的顺序查。

先确认是谁在访问

终端里执行的程序通常使用当前用户身份；网站服务则可能是 www、www-data 或 nginx，具体以实际配置为准。

whoami
id
ls -ld /path/to/app
ls -l /path/to/app/config.ini

这里的路径只是示例，需要换成自己的文件。重点看属主、属组，以及正在运行的程序属于哪个用户，不要只看自己的账号能不能打开文件。

文件能读，父目录也得能走进去

访问一个文件时，路径上的每一级目录都需要相应的执行权限。文件本身有读权限，不代表一定能访问到它。

namei -l /path/to/app/config.ini

如果系统没有 namei，也可以逐层用 ls -ld 检查。目录上的 r 是列出目录内容，x 是进入和访问目录里的条目，含义和普通文件的可执行权限不一样。

只改需要的那一处

确认脚本可信、确实需要直接执行时，可以给属主增加执行权限：

chmod u+x ./deploy.sh

这只对属主生效；如果由别的服务用户执行，还要检查属组及对应权限。网站里的上传、缓存、日志目录可能需要写权限，但代码和配置不应该因此全部开放写入。也不要没检查目录内容就递归 chown，尤其是共享目录或包含敏感文件的路径。

普通权限没问题，再查其他限制

还可能是 ACL、SELinux、只读挂载，或者分区启用了 noexec。可以结合实际环境检查：

getfacl /path/to/app/config.ini
findmnt -T /path/to/app
getenforce

这些工具并非每台机器都安装。getenforce 只适用于启用了 SELinux 的系统；其他系统还可能有 AppArmor 等限制。不要为了验证猜测就直接关闭安全机制，先看拒绝日志和具体策略。

排查权限问题，最重要的是对齐“哪个进程、以哪个用户、访问哪个路径、需要什么权限”。定位到原因以后再改，通常比到处加 777 更省心。