Linux 文件权限怎么改：chmod、chown 与目录权限
Linux 权限问题经常出现在文件上传、服务账号变更或迁移之后。看到 Permission denied 就执行递归的 777，虽然可能暂时消除报错，却把无关文件一起开放。本文以 Ubuntu 24.04 为例，讨论普通文件与目录的权限调整；已有 ACL、容器映射或其他安全策略时，还要检查对应层面的限制。
先查当前状态和真正访问者
在服务器查看目标路径：
# Ubuntu 服务器，替换为已确认的实际文件
stat -c '%U:%G %a %n' /srv/app/config.ini
ls -ld /srv /srv/app
id deploy
第一条给出属主、属组、数字权限和文件名；第二条检查上层目录。deploy 是示例用户，必须换成实际账号。程序可能由 systemd 指定的其他用户运行，所以“我在 SSH 里能读”并不能证明应用进程也能读。
先记录修改前的权限和归属，同时确认路径是否为符号链接。修改链接引用的对象可能影响另一个目录中的文件，不能只看眼前的文件名。对重要目录，保留具备权限元数据的备份，再安排变更。
文件的读写与目录的读写不同
对普通文件，读权限用于读取内容，写权限用于修改内容，执行权限允许把适合执行的文件作为程序运行。对目录，读权限影响列出名称，执行权限影响穿越目录和查找条目，写权限配合执行权限影响新增、删除或重命名条目。
因此，一个文件即使本身可读，上层目录不能穿越时仍然无法打开；反过来，文件本身只读，也不保证拥有父目录写权限的人不能删除或替换它。共享目录还可能受 sticky bit 限制，不能仅用三组数字判断所有删除行为。chmod 手册说明了权限位与目录搜索权限的区别。
用最小范围修改，避免递归一刀切
假设只有应用配置需要属组读取，且已确认这个文件的用途，可以采用符号权限：
# Ubuntu 服务器，仅修改已确认的这个文件
sudo chmod u=rw,g=r,o= /srv/app/config.ini
结果通常对应普通文件的 640 权限，但先确认没有需要保留的特殊位或 ACL。符号模式更容易表达“允许谁做什么”，数字模式适合已经明确完整目标状态的场景。不能把文件模式机械套给目录，否则可能丢失必要的穿越权限。
给目录增加进入权限时，要同时考虑谁能够列目录、谁能够写入。发布目录和上传目录通常应分开处理；应用只需写上传目录，就不要让它改写整个程序目录。批量调整前先列出匹配文件，并在小范围验证。
chown 改的是身份归属
如果文件归属错误，再检查是否需要修改属主或属组。以下仅用于已经存在的账号与组：
getent passwd deploy
getent group appreaders
sudo chown deploy:appreaders /srv/app/config.ini
前两条核对身份，最后一条才改变归属。不要对不存在的名称猜测数字 ID，也不要把源服务器的数字用户 ID 原样套到另一台身份分配不同的机器。chown 官方发行版手册解释了只改用户、只改组和同时修改的语法。
改组并不会自动让所有运维账号成为该组成员。已有会话还可能保持旧组信息，因此修改成员关系后需要重新登录或重启对应服务身份再验证。不要为“刷新权限”随意重启整台业务服务器。
用应用身份验收，并保留恢复记录
由管理员以实际服务用户验证所需访问，例如 sudo -u 实际用户 test -r 实际文件，再检查业务能否完成真实读写动作。这里的 test 只返回结果，不会证明应用解析内容也正确；配置语法和业务流程仍要单独验收。
如果传统权限看起来正确，继续检查 ACL、只读挂载、AppArmor、容器用户映射或路径是否走到了其他文件系统。不要反复放宽 chmod 来掩盖这些问题。每次只修改明确的一层，记录结果，才能知道真正原因。
出现意外时，按事先记录恢复具体文件的属主、组和权限，并再次验收。没有原始记录时，不应凭感觉对整个系统递归 chown；应先从包管理、部署资料或可信备份恢复正确的元数据。