先确认权限错误的边界

在香港AMD EPYC服务器用于多线程业务的部署中，服务可能表现为“程序手工执行正常，但由 systemd 启动后报 Permission denied”“只有部分任务失败”或“读取配置成功、写入结果失败”。多线程本身不会改变进程的 Linux 用户身份；同一个进程中的线程通常共享用户、用户组和文件权限。真正需要优先确认的是：报错的进程到底以哪个用户运行、该用户是否拥有目标目录的完整路径权限，以及 systemd 或安全策略是否进一步限制了访问。

先不要直接执行 chmod -R 777、把服务改成 root，也不要在没有记录原始状态的情况下递归修改目录。应当按照“日志和服务状态 → 实际进程身份 → 路径逐级权限 → ACL、挂载和安全策略 → 最小范围修复 → 业务复测”的顺序处理。

以下示例以 Linux 和 systemd 服务为前提。请将 app.service、/srv/app/data/jobs/input.dat 和 /srv/app/data/jobs 替换为实际服务名、报错文件及其所在目录。排查阶段需要具有读取服务状态和目标目录属性的权限；涉及修改用户组、所有者或服务配置时，需要经过变更审批，并提前安排重启影响窗口。

先从日志确定失败对象

记录报错路径和时间

权限问题不能只看应用返回的“无权限”，还要确认失败的是读取、创建、覆盖、删除还是重命名操作。不同操作需要的权限不同，后续修复方式也不一样。

SERVICE=app.service
TARGET=/srv/app/data/jobs/input.dat
TARGET_DIR=/srv/app/data/jobs

sudo systemctl status "$SERVICE" --no-pager -l
sudo journalctl -u "$SERVICE" -b --no-pager -n 200

重点查看以下信息：

• 错误发生的准确时间，以及是否每次都发生；
• 错误中出现的实际路径，是否与配置文件中的路径一致；
• 是 Permission denied、Read-only file system、No such file or directory，还是空间不足；
• 服务是否已经重启、是否存在多个工作进程；
• 报错由主进程、子进程还是某个任务执行器产生。

Permission denied 通常对应权限或安全策略拒绝，但不一定只是传统的属主和 rwx 位。Read-only file system 更像是挂载为只读或被 systemd 沙箱设为只读；No such file or directory 则应优先检查路径、工作目录、软链接目标和启动顺序，而不是立即修改权限。

确认服务是否真的由 systemd 管理

sudo systemctl is-enabled "$SERVICE"
sudo systemctl is-active "$SERVICE"
sudo systemctl cat "$SERVICE"

systemctl cat 可以看到主 unit 和 drop-in 覆盖配置。特别留意以下配置项：

• User=、Group=、SupplementaryGroups=；
• WorkingDirectory=；
• DynamicUser=；
• ProtectSystem=、ProtectHome=；
• ReadOnlyPaths=、ReadWritePaths=；
• InaccessiblePaths=、RootDirectory=；
• PrivateTmp=。

如果服务由其他进程管理，或者 unit 的 ExecStart 又启动了子进程，不能只根据 unit 文件判断身份，必须继续查看实际运行的 PID。

第一优先级：核对实际服务身份

同时查看 unit 配置和主进程

sudo systemctl show "$SERVICE" \
  -p User \
  -p Group \
  -p SupplementaryGroups \
  -p DynamicUser \
  -p MainPID

再读取主进程的实际身份：

MAINPID=$(sudo systemctl show "$SERVICE" -p MainPID --value)

if [ "$MAINPID" != "0" ]; then
  sudo ps -o pid,ppid,user,group,args -p "$MAINPID"
  sudo awk '/^(Name|Uid|Gid|Groups):/' "/proc/$MAINPID/status"
fi

判断时以实际进程为准：

• User= 为空时，普通 systemd 系统服务通常使用默认的 root 身份，但仍应以 /proc//status 和 ps 结果核实；
• unit 中写了普通用户，但主进程显示为另一个用户，可能是启动脚本再次降权、启动了不同的工作进程，或者查看的并非目标进程；
• Groups: 是进程当前拥有的补充组，通常比登录用户执行 id 更有参考价值；
• MainPID 只代表主进程。如果服务会派生多个 worker 或任务进程，应把这些进程一并检查。

可以通过进程树查看是否存在身份不同的子进程：

sudo pstree -alp "$MAINPID"
sudo ps -eo pid,ppid,user,group,args --forest | grep '[a]pp'

如果主进程和 worker 的用户或用户组不同，必须针对实际报错的 PID 检查，不能因为主进程有权限就认定所有线程或子进程都有权限。

检查用户、主组和补充组

假设上一步确认服务应当使用 appsvc 用户和 appgrp 用户组：

getent passwd appsvc
id appsvc
getent group appgrp
sudo -u appsvc -- id

这些命令分别用于确认：

• 用户是否存在，UID 是否发生变化；
• 用户的主组是什么；
• 目标组是否存在，以及组成员有哪些；
• 以该用户启动一个普通命令时能够看到哪些组。

sudo -u appsvc id 只能作为参考。systemd 可能通过 Group= 和 SupplementaryGroups= 设置与交互式登录不同的组环境，最终仍应以服务进程的 Groups: 为准。

如果刚把用户加入某个组，已经运行的进程通常不会自动获得新的补充组。需要在确认重启影响后重启服务，再重新读取 /proc//status。不要只重新登录管理终端后就认定服务已经获得新权限。

第二优先级：逐级检查路径权限

目录权限不是只有“能不能读”

Linux 中目录权限的含义与普通文件不同：

因此，/srv/app/data/jobs/input.dat 即使文件本身属于服务用户，只要 /srv、/srv/app、/srv/app/data 或 /srv/app/data/jobs 中任意一级缺少遍历权限，服务仍然可能打不开它。

用 namei 查看每一级目录

sudo namei -l "$TARGET"

输出会逐级展示路径中的目录、软链接、属主和权限。重点观察：

• 是否有某一级目录对服务用户和其用户组缺少 x；
• 路径中是否存在软链接，软链接最终指向哪里；
• 实际目标是否位于另一个目录树；
• 报错文件的父目录是否与预期不一致。

如果系统没有 namei，可以分段使用：

sudo stat -c '%A %a %U:%G %n' \
  /srv \
  /srv/app \
  /srv/app/data \
  /srv/app/data/jobs \
  "$TARGET"

stat 只能显示指定对象本身，不能替代对每一级路径的检查。对于软链接，还应确认真实目标：

sudo readlink -f "$TARGET"
sudo stat -Lc '%A %a %U:%G %n' "$TARGET"

如果 readlink -f 无法解析，说明路径中可能有不存在的组件或断链，先修正路径配置和目录创建流程，不要通过放宽权限掩盖路径错误。

以服务用户进行无副作用测试

先做只读的访问检查：

sudo -u appsvc -- sh -c '
  p="$1"
  d="$2"

  test -r "$p" && echo "file-read: ok" || echo "file-read: denied-or-missing"
  test -x "$d" && echo "dir-traverse: ok" || echo "dir-traverse: denied"
  test -w "$d" && echo "dir-write: ok" || echo "dir-write: denied"
' sh "$TARGET" "$TARGET_DIR"

结果的含义是：

• file-read: ok 只能说明当前 DAC 权限检查允许读取，不能证明应用使用的实际路径、MAC 策略和 systemd 沙箱也允许；
• dir-traverse: denied 表示服务无法进入该目录，创建、读取目录中的文件通常都会失败；
• dir-write: denied 表示无法在该目录创建、删除或重命名文件；
• file-read 显示缺失时，要区分文件不存在和没有读取权限，结合 stat、日志中的错误码判断。

如果必须验证“能否创建文件”，应只在专门的维护目录中进行，并明确该操作会产生并删除测试文件：

sudo -u appsvc -- sh -c '
  f=$(mktemp "$1/.permission-check.XXXXXX") || exit 1
  rm -f -- "$f"
' sh "$TARGET_DIR"

这条命令会真实写入目标目录。不要在生产业务目录随意执行，也不要使用业务文件名作为测试文件，以免覆盖现有数据。若 mktemp 成功但应用仍失败，应继续检查应用实际使用的文件名、打开模式、工作目录和 systemd 安全限制。

第三优先级：检查属主、用户组和 ACL

对照有效身份与目录属性

sudo stat -c '%A %a %U:%G %n' "$TARGET_DIR" "$TARGET"
sudo getfacl -p "$TARGET_DIR" "$TARGET"

传统模式位的判断顺序通常是：

1. 有效用户是否是文件或目录的属主；
2. 如果不是属主，有效组或补充组是否匹配所属组；
3. 如果前两者都不匹配，才使用“其他用户”权限；
4. 如果存在 ACL，还要继续判断 ACL 条目和 mask。

例如，目录显示为 appowner:appgrp，但服务进程实际用户是 appsvc，且 Groups: 中没有 appgrp，那么目录的组权限不会对该服务生效。相反，如果服务用户属于 appgrp，但目录权限是 drwx------，组成员同样无法访问。

ACL 中的 mask 也很容易造成误判。即使看到针对 appsvc 的 ACL 条目，如果 mask 没有允许相应权限，实际有效权限仍会被限制。getfacl 中带有 #effective: 的内容需要重点查看。

按失败类型判断修复范围

• 只需要读取已有文件：授予服务用户或专用组对文件的读取权限，并确保所有父目录可遍历；
• 需要创建新文件：修改父目录权限，不要只修改一个尚不存在的文件；
• 需要覆盖已有文件：同时检查目标文件的写权限，以及父目录是否允许访问；
• 需要删除或重命名文件：重点检查父目录的写和执行权限；
• 多个服务共享目录：优先建立专用用户组和组继承规则，不要直接开放给所有用户；
• 只有某些子目录失败：沿着失败文件的完整路径单独检查，避免对整个数据树递归放权。

第四优先级：排除挂载和系统安全限制

检查文件系统是否只读

sudo findmnt -T "$TARGET" -o TARGET,SOURCE,FSTYPE,OPTIONS

如果输出的挂载选项包含 ro，写入失败的根因是文件系统只读，而不是目录的 w 位。此时应先确认文件系统状态、挂载管理和运维变更记录。不要仅通过 chmod 或 chown 处理，也不要在未确认数据安全前强行重新挂载为可写。

还要注意目标路径可能位于独立挂载点、临时文件系统或服务专用目录。服务看到的路径与管理员在其他命名空间中看到的路径可能不同，需结合服务配置和实际进程环境确认。

检查 systemd 的访问限制

sudo systemctl show "$SERVICE" \
  -p ProtectSystem \
  -p ProtectHome \
  -p ReadOnlyPaths \
  -p ReadWritePaths \
  -p InaccessiblePaths \
  -p PrivateTmp \
  -p RootDirectory \
  -p WorkingDirectory

常见判断方式如下：

• ProtectSystem 可能使系统目录或大部分路径对服务变为只读；
• ReadOnlyPaths 会明确将指定路径设为只读；
• ReadWritePaths 通常用于在启用系统保护时声明少量可写目录；
• InaccessiblePaths 会让服务无法访问指定路径；
• PrivateTmp=yes 时，服务使用的是独立临时目录，管理员在宿主机普通 /tmp 中看到的文件不一定是服务使用的那一份；
• WorkingDirectory 不存在或服务用户无权进入时，服务可能在真正执行任务前就失败。

如果服务确实需要写入某个状态目录，应在 unit 的安全策略中精确放行该目录，而不是关闭全部保护。例如，确认服务已经启用 ProtectSystem，且业务只需要写入 /srv/app/data 时，可以在经过测试后使用 drop-in：

[Service]
ReadWritePaths=/srv/app/data

这类配置改变会影响服务的可写范围。修改前应保存当前 unit 和 drop-in，修改后执行 daemon-reload 并重启服务；如果验证失败，恢复原 drop-in 文件，再次执行 daemon-reload 和服务重启。不要直接删除不清楚用途的现有 drop-in，因为其中可能包含其他安全设置。

检查 SELinux 或 AppArmor

传统 Unix 权限允许访问，不代表强制访问控制一定允许。先判断系统是否启用了相关机制：

if command -v getenforce >/dev/null 2>&1; then
  getenforce
  sudo ls -Zd "$TARGET_DIR" "$TARGET"
fi

if command -v aa-status >/dev/null 2>&1; then
  sudo aa-status
fi

如果 SELinux 处于强制模式，可在对应时间范围内查找拒绝记录；如果系统使用 AppArmor，则查看内核日志和对应配置文件中的拒绝事件。重点是让策略允许服务访问必要的目录，而不是长期关闭安全机制。

恢复安全标签、调整策略或修改 profile 都属于安全配置变更。执行前应保存当前标签或策略文件，确认影响范围，完成业务验证后再保留变更。sudo -u appsvc 的测试不一定能够复现 SELinux 或 AppArmor 的完整判断，因此“命令行测试成功、服务仍失败”时，安全审计日志尤其重要。

按最小权限原则修复

方案一：为服务建立专用目录

如果服务需要保存运行状态、任务结果或临时文件，优先使用独立目录，而不是让服务写入整个 /srv 或用户家目录。

创建新目录时可以一次性指定属主、属组和初始权限：

sudo install -d -o appsvc -g appgrp -m 0750 /srv/app/state

如果多个服务需要协作，可根据实际需要使用组权限，例如：

sudo install -d -o appsvc -g appgrp -m 2770 /srv/app/shared

2770 中的 2 表示设置组继承位，新建文件和子目录会更容易继承指定组。它只适用于确实需要组内协作的目录，不应在所有业务目录上统一使用。

方案二：针对现有路径调整属主或组

只修改已经确认属于该服务的目录，不要对整个系统目录递归执行 chown。变更前先保存属性和 ACL：

sudo getfacl -p /srv/app/data/jobs > /root/app-data-jobs.acl.before
sudo stat -c '%A %a %U:%G %n' /srv/app/data/jobs "$TARGET" \
  > /root/app-data-jobs.stat.before

确认目录边界、挂载点和业务影响后，再做最小调整。例如，目录确实应由该服务专属：

sudo chown appsvc:appgrp /srv/app/data/jobs
sudo chmod 0750 /srv/app/data/jobs

如果目录需要由同组服务共同读写，可以采用经过确认的组权限：

sudo chown appsvc:appgrp /srv/app/data/jobs
sudo chmod 2770 /srv/app/data/jobs

这些命令会改变现有访问行为，可能使其他用户无法继续读写，也可能改变新文件的组继承方式。回滚不能靠猜测原权限，应根据变更前保存的记录恢复；如果记录包含完整 ACL，可在确认备份文件可信且路径未发生变化后使用：

sudo setfacl --restore=/root/app-data-jobs.acl.before

恢复前要核对备份中的路径，避免把旧权限错误应用到新的目录结构。

方案三：使用专用组或精确 ACL

如果目录不能改变原有属主，可以使用专用组。加入补充组前先记录当前组成员，确认该组不包含不应访问数据的账号：

id appsvc
getent group appgrp

在确认 appgrp 是适合该服务的专用组后，才考虑追加成员：

sudo usermod -aG appgrp appsvc

-aG 是追加而不是覆盖现有补充组。变更后必须重启服务并重新核对进程的 Groups:。如果确认需要回滚，使用变更前记录核对后再移除成员；不要把服务用户的主组误删：

sudo gpasswd -d appsvc appgrp

ACL 适用于只需要给某个服务增加权限、又不希望改变目录主属主的场景。修改前必须先备份：

sudo getfacl -p /srv/app/data/jobs > /root/app-data-jobs.acl.before
sudo setfacl -m u:appsvc:rwx /srv/app/data/jobs

这只解决该目录本身的访问，路径上级目录仍需允许 appsvc 遍历。若目标是新建文件，还要确认目录具备写权限以及 ACL 的 mask 没有限制实际权限。不要对整棵目录树直接设置宽泛 ACL，除非已经明确每一级目录和文件的业务用途。

方案四：修正服务身份，而不是提升到 root

如果服务当前以错误的普通用户运行，应在 unit 的 drop-in 中明确身份。修改前保存当前配置，并评估服务重启影响：

sudo systemctl cat app.service | sudo tee /root/app.service.before >/dev/null
sudo systemctl edit app.service

在编辑器中加入类似内容：

[Service]
User=appsvc
Group=appgrp
WorkingDirectory=/srv/app

保存后：

sudo systemctl daemon-reload
sudo systemctl restart app.service
sudo systemctl status app.service --no-pager -l

将服务从 root 改为普通用户可能暴露其他问题，例如原来由 root 创建的文件、监听端口、日志目录或运行时目录不再可访问。因此，不能只改 User= 就结束排查，必须同步检查服务需要的每个目录。

如果此次修改失败，应恢复刚才保存的 drop-in 内容，而不是使用可能影响其他管理员配置的整体回退命令。恢复后重新执行：

sudo systemctl daemon-reload
sudo systemctl restart app.service

除非经过明确评估，不要用“改回 root”作为权限修复。root 可以绕过部分传统文件权限，但仍可能受到只读挂载、systemd 沙箱、SELinux 或 AppArmor 限制，而且会扩大服务故障或被利用后的影响范围。

修复后的验证方法

验证服务身份已经生效

sudo systemctl show app.service \
  -p User \
  -p Group \
  -p SupplementaryGroups \
  -p MainPID

MAINPID=$(sudo systemctl show app.service -p MainPID --value)
sudo awk '/^(Name|Uid|Gid|Groups):/' "/proc/$MAINPID/status"
sudo ps -o pid,ppid,user,group,args -p "$MAINPID"

如果服务有多个 worker，应再次查看进程树和所有相关 PID，确认没有一个子进程仍以不同身份运行。

验证实际业务动作

不要只以 systemctl status 显示“active”作为成功标准。应在低风险时间执行一次与故障相同的业务动作：

• 读取一个已存在的输入文件；
• 创建一个新的任务文件；
• 写入或覆盖一个测试结果；
• 如果业务需要，再验证重命名、归档或删除动作。

同时观察本次操作对应的日志：

sudo journalctl -u app.service --since "10 minutes ago" --no-pager

成功标准应包括：

• 目标业务动作完成；
• 日志中不再出现对应路径的权限错误；
• 新建文件的属主、属组和权限符合预期；
• 服务重启后仍然能够完成同一动作；
• 新启动的 worker 仍然继承正确的用户组；
• 没有因放宽权限而让无关用户获得额外访问能力。

持续观察容易复发的场景

如果故障只在批量任务、文件轮换或服务重启后出现，应继续检查：

• 新建子目录是否继承了正确的组和权限；
• 日志轮换、任务归档是否由另一个用户执行；
• 定时任务或部署脚本是否重新创建了 root 属主文件；
• 服务重启后补充组是否仍然正确；
• 某些任务是否使用了不同的工作目录或软链接；
• 文件系统是否在特定时段变为只读；
• systemd unit 或安全策略是否在更新后被覆盖。

当“手工以服务用户执行命令成功，但实际服务仍失败”时，优先回到实际 PID、systemd 沙箱和 SELinux/AppArmor 日志，而不是继续扩大目录权限。权限排查的最终目标不是让任何用户都能访问，而是让正确的服务身份只获得完成指定多线程任务所需的最小目录和文件权限。