先把当时的情况摆出来。运维按安全基线把 /etc/profile 里的 umask 从 0022 改成 0077，重启后 Jenkins 发布的站点目录权限变成 700，nginx 以 www 用户访问全部 403。
原因不止一个，得分开看。umask 是进程级默认值，Jenkins 继承了新值，创建目录时自动去掉组和其他人的权限。还有一种是systemd 启动的服务读的是自己的 UMask 配置，与 shell 里设置的不一致。
少数情况下是发布脚本里没显式 chmod，全靠默认值，改动后立刻暴露。不容易想到的是，老目录权限没变，只有新发布的版本受影响，排查时容易被新旧混杂误导。
第一件事是确认当前进程与服务各自的 umask
umask && systemctl show jenkins -p UMask只对服务单元设置合适的掩码
printf '[Service]\nUMask=0022\n' > /etc/systemd/system/jenkins.service.d/umask.conf && systemctl daemon-reload发布脚本里显式声明目标权限
install -d -m 755 /www/wwwroot/site && chmod -R 755 /www/wwwroot/site等前面都确认过，再重启服务后按新流程发布一次
systemctl restart jenkins && ls -ld /www/wwwroot/site恢复的判定其实很直接。新发布出来的目录权限是 755、文件是 644，nginx 访问返回 200，systemctl show 里 UMask 与实际生效值一致。
容易忽略的是，全局改 umask 影响面极大，安全基线要求收紧权限时应落在具体服务单元上；改完必须重新发布一次才能验证，老目录不会自动变。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。