Linux 服务创建文件权限不符合预期怎么办

Linux 服务创建出来的文件权限不对，最常见的原因不是程序突然改了权限，而是创建它的服务进程 umask和当前终端不同。排查时先看目标 PID 的 /proc/PID/status，再按创建模式计算结果：普通文件通常按 0666 计算，目录通常按 0777 计算，umask 负责屏蔽其中的权限位。

不少朋友在Linux上部署服务的时候经常碰到这类情况：明明代码里写了指定创建文件的权限是755，实际生成的文件权限却是750甚至更低，网页访问时报权限不足403错误，排查半天找不到问题根源。你可以先对照服务运行身份、umask掩码规则、文件夹继承权限属性这几个常见方向逐项校验，就能快速定位并解决这个异常。

绝大多数这类权限不符的问题都和进程的umask配置、运行身份所属的权限组、上层文件夹挂载属性这三个因素相关，不需要额外修改服务源码的权限调用逻辑就能修复。

先看服务进程，而不是当前终端

我处理这类问题时，第一步会先拿到服务的 PID。因为服务可能由另一个父进程启动，登录用户执行的 umask 只显示当前 Shell 的掩码；它和服务进程之间可能隔着启动器、守护进程或重启过程。

# 把 PID 替换成目标服务的实际进程号，读取该进程当前的 Umask
awk '/^Umask:/ { print }' /proc/PID/status

# 当前终端的 umask 只用于对照，不等于服务进程的设置
umask

Linux man-pages 说明，进程的 umask 可以通过 /proc/PID/status 中的 Umask 字段查看。这样检查不会像反复调用 umask() 那样先修改再恢复掩码，更适合排查已经运行的服务。

文件和目录为什么会得到不同权限

umask 不是把数字直接做普通减法，而是屏蔽创建模式中的对应权限位。可以把它记成：

最终权限 = 创建模式 & ~umask

程序创建普通文件时，常见请求模式是 0666，创建目录时常见请求模式是 0777。因此同一个服务使用 0022 时，文件和目录会出现不同结果：

对象	创建模式	umask	常见结果
普通文件	0666	0022	0644
目录	0777	0022	0755
普通文件	0666	0077	0600
目录	0777	0077	0700

这也解释了一个容易误判的现象：文件本身没有执行位，并不表示 umask 失效，而是因为常见文件创建模式本来就是 0666；目录则从 0777 开始，所以同样的 0022 会保留目录的执行/搜索权限。

服务和 Shell 不一致时，沿着继承关系找

umask 属于进程属性。子进程会继承父进程的 umask，而 execve() 不会自动把它重置。因此重启方式、父进程环境和启动配置都可能让服务与登录 Shell 得到不同结果。实际判断时可以按下面的顺序缩小范围：

1. 确认新文件的创建者和服务 PID，避免看错进程。
2. 读取服务 PID 的 Umask，记录四位八进制值。
3. 用 0666 或 0777 与该值计算，不要直接拿当前 Shell 的结果套用。
4. 查看父目录的权限和 default ACL，确认目录本身是否提供了额外规则。

如果服务重启后权限又变化，重点应放在启动链路是否更换了父进程或启动参数，而不是反复对已经生成的文件执行 chmod。chmod 只能修正已有对象，不能解释下一次新建对象为什么继续出错。

umask 解释不了结果时，检查 default ACL

umask(2) 的一个重要例外是：如果父目录设置了 default ACL，新建对象会继承这套 ACL，umask 不再按普通路径单独决定结果。此时只看 Umask: 0022 仍可能解释不完整。

# 查看父目录的访问 ACL 与 default ACL；没有 default 项也属于有用结果
getfacl -p /srv/example-data

# 只查看结果对象的权限和 ACL，避免把目录权限误当成文件权限
getfacl -p /srv/example-data/output.log
stat -c 'mode=%a owner=%U group=%G path=%n' /srv/example-data/output.log

排查时把两条规则分开记录：一条是服务进程的 umask，另一条是父目录的 default ACL。先确认对象由谁创建，再确认父目录是否提供默认 ACL，通常就能找到“我明明看到 0022，结果却不是 0644”的原因。

最后用一张表快速判断

现象	优先检查	不要先做什么
文件是 0644，目录是 0755	确认服务进程 Umask 是否为 0022	不要把文件模式当成目录模式
Shell 与服务结果不同	读取服务 PID 的 /proc/PID/status	不要只执行当前用户的 umask
同一目录下结果仍不符合计算	检查父目录 default ACL	不要先批量 chmod 掩盖原因

我的结论是：把“创建模式、服务进程 umask、父目录 default ACL”当成三个独立变量，权限问题就不会停留在猜测阶段。先读进程，再算结果，最后查 ACL，比修改文件后等待下一次复现更稳定。

相关问题

为什么设置了 Shell 的 umask，服务创建的文件仍没变化？

因为 Shell 的 umask 只影响从该 Shell 继承环境的进程。已经运行的服务或由其他启动链路拉起的服务，应该读取它自己的 /proc/PID/status。

umask 0022 为什么不会得到文件 0666？

umask 的作用就是屏蔽权限位，0666 & ~0022 的结果是 0644。它不会增加权限，也不是普通数字减法。

看到 default ACL 后还需要看 umask 吗？

需要。两者属于不同层面的规则。先记录服务进程的 umask，再查看父目录的 default ACL，才能完整解释最终权限。

本文技术事实参考 Linux man-pages 的 umask(2) 说明，重点是服务进程默认权限的排查边界。