Nginx或PHP Worker进程因缓存目录缺少“可进入（x）+可读取（r）”权限而报错，需确认实际运行用户、逐级检查属主与x权限、精准chown/chmod，并排查SELinux、open_basedir等静默拦截。
核心问题不是“没 root 权限”，而是 Nginx 或 PHP Worker 进程以非 root 用户（如 www-data、nginx、daemon）运行时，对配置中指定的缓存目录（如 root /var/www/app; 或 runtime/、storage/）缺少必要访问权限。这类问题常表现为 403 Forbidden、静态资源加载失败、PHP 报 is_writable() === false 或 Swoole/Hyperf 启动卡在写入 runtime。
确认 Worker 实际运行用户
别只看 nginx.conf 里的 user 行——它可能被注释、覆盖或未生效：
- 执行
ps -eo pid,user,comm,args | grep nginx | grep -v grep，找worker process对应的USER列（不是 master） - 在 PHP 环境中，用
echo posix_getpwuid(posix_geteuid())['name'];查 Web 请求实际用户（不是 CLI 的whoami） - Hyperf/Swoole 场景下，运行
ps aux | grep swoole确认进程归属
检查缓存目录的属主与关键权限位
目录必须满足“可进入 + 可读取”组合，缺一不可：
- 执行
ls -ld /var/www/app和ls -ld /var/www/app/runtime，确认输出中属主（第三列）或属组（第四列）匹配上一步查到的 Worker 用户 - 目录权限中必须含 x（执行）位：没有 x，Worker 连进入目录都做不到，更别说读文件或创建子目录
- 文件需有 r（读）位 才能返回给客户端；若需写入（如日志、缓存生成），文件或父目录还需 w 位
- 常见错误：目录属主是
root，权限为750，而 Worker 用户不在属组中 → 直接 403
按最小权限原则修复归属与权限
不推荐盲目 chmod 777，应精准授权：
- 改属主属组（以 Debian/Ubuntu 的
www-data为例）：sudo chown -R www-data:www-data /var/www/app/runtime /var/www/app/storage - 设权限（大写
X只对目录加 x，不影响文件）：sudo chmod -R u+rwX,g+rwX,o-rwx /var/www/app/runtime - 若缓存路径是用户家目录下（如
~/composer-cache或/home/deploy/app/runtime），确保chown同时覆盖父级路径，因为逐级进入都需要 x
警惕静默拦截机制
有些限制不会报 “Permission denied”，但效果一样：
-
SELinux（CentOS/RHEL）：运行
sudo sestatus -v，若为enforcing，临时放开：sudo setsebool -P httpd_write_content 1（Nginx 也适用该布尔值） -
open_basedir：在 PHP 脚本中执行
echo ini_get('open_basedir');，若输出非空且缓存路径不在其中，需在 Nginx 配置中通过fastcgi_param PHP_VALUE "open_basedir=..."补充路径 -
挂载选项：Linux 上用
mount | grep $(df . | tail -1 | awk '{print $1}')检查是否挂载为ro（只读）；macOS 查mount | grep " / "是否含read-only
