Linux namei -l 怎么定位目录权限失败：逐级拆开路径与最小修复

服务日志里出现 Permission denied 时，很多人第一反应是给目标文件加读权限。但 Linux 打开一个路径，必须从根目录开始逐级穿过每个父目录；文件本身是 644，不代表进程真的能走到它。namei -l 能把这条路径拆成每一级目录、符号链接和最终文件，适合在不扩大权限的前提下快速定位卡点。

先看完整路径，而不是只盯着 config.yml

假设服务用户是 appuser，配置文件位于 /srv/app/data/config.yml。先保留现场，不要直接执行递归 chmod：

namei -l /srv/app/data/config.yml
ls -l /srv/app/data/config.yml
id appuser

namei -l 的输出会把 /、srv、app、data 和 config.yml 分行展示。目录行重点看最后三位权限是否包含 x，文件行再看是否有 r。如果路径中有软链接，输出还会把链接指向的目标展开，避免你检查了链接却漏掉真实目录。

目录没有 x，为什么文件的 r 也救不了

对目录来说，r 允许读取目录项列表，x 才允许按名称访问其中的对象。下面这个状态很容易误判：

drwxr-xr-x root    root    /
drwxr-xr-x root    root    srv
drwxr-xr-x deploy  deploy  app
drw-r----- appuser appuser data
-rw-r----- appuser appuser config.yml

config.yml 看起来属于 appuser，但 data 没有任何执行位。appuser 无法穿过这个目录，因此打开文件仍然失败。这个判断也解释了为什么只改文件模式通常没有效果。

如果某一级目录显示为 drwx--x---，它可能允许特定属主或组穿过，却不允许列目录。此时不要把“不能 ls”直接等同于“不能读文件”，要结合服务用户、组成员关系和实际访问动作判断。

用服务真实身份复现一次

root 执行 cat 能成功，只能说明 root 有权限，不能证明 systemd 服务也有权限。先查看服务配置中的身份：

systemctl show myapp.service -p User -p Group -p SupplementaryGroups
sudo -u appuser -- namei -l /srv/app/data/config.yml
sudo -u appuser -- cat /srv/app/data/config.yml >/dev/null

如果服务使用了动态用户、额外组或沙箱目录，还要把这些运行时约束纳入判断。尤其是 ProtectSystem、ReadOnlyPaths 等 systemd 设置可能让“权限看起来正确”的路径在服务环境里仍不可用；不要为了绕过一个读取问题就关闭整组隔离。

按命中的那一级做最小修复

修复顺序建议是：先补正确的组关系，再给目录增加必要的组执行位，最后才考虑文件属主或 ACL。比如服务应通过 appconf 组读取配置，可以这样处理：

sudo usermod -aG appconf appuser
sudo chgrp appconf /srv/app/data /srv/app/data/config.yml
sudo chmod g+x /srv/app/data
sudo chmod g+r /srv/app/data/config.yml
namei -l /srv/app/data/config.yml

组变更通常需要重启服务或重新建立会话才会生效；不要用 chmod -R 777 /srv 作为验证手段。若不能改变共享组，再评估针对文件或目录的 ACL，并把规则记录在部署配置中，避免下次发布覆盖。

复查结果要同时覆盖权限与服务重启

修复后至少做三次核对：用 namei -l 确认每一级路径；用服务用户读取文件；再检查服务日志中的新一轮启动结果。

sudo -u appuser -- cat /srv/app/data/config.yml >/dev/null
systemctl restart myapp.service
systemctl status myapp.service --no-pager
journalctl -u myapp.service -n 50 --no-pager

如果同一用户命令成功、服务仍失败，问题就不一定是传统 Unix 模式位，继续检查 systemd 沙箱、容器挂载、SELinux 或 AppArmor 审计记录。这样能把“路径权限问题”和“运行环境拒绝”分开处理。

常见问题

namei -l 和 ls -l 应该先用哪个？

排查完整路径时先用 namei -l，它能发现父目录和软链接问题；确认单个文件内容与属主时再补充 ls -l。

目录只有 r 没有 x，能读取里面的文件吗？

通常不能按名称穿过目录访问文件。目录的 x 是路径访问的关键权限，不能用文件的 r 替代。

root 能读但服务用户不能读，是否直接改成 644？

不应直接改。先确认服务用户、组和每一级父目录，再按最小权限补齐组或 ACL；644 只描述文件本身，不解决父目录卡点。

权限修复后 systemd 仍报拒绝怎么办？

用服务身份复现后检查 unit 的沙箱配置、挂载命名空间，以及 SELinux/AppArmor 审计日志，确认是否是运行环境策略而非 Unix 模式位。

一条路径的访问失败，往往只差在中间某一级目录。把路径拆开、用真实服务身份复现，再对命中点做小范围修复，通常比盲目放大权限更快也更安全。