Nginx日志权限报错(13: Permission denied)本质是worker用户对日志路径缺写入或执行权限，需确认实际运行用户、逐级检查属主属组及全路径x权限、精准赋权并排查SELinux拦截。
直接看 error.log 里报的路径和错误码（比如 (13: Permission denied)），基本能锁定是 Nginx 工作用户对日志目录或文件缺少写入权限，不是配置写错了，而是系统在底层拦住了。
确认 Nginx 实际运行用户
别只信 nginx.conf 里的 user 行——它可能被注释、被覆盖或没生效：
- 运行
ps aux | grep nginx | grep -v master，看 worker 进程的 USER 列（常见为www-data、nginx或_www） - 再查日志路径归属：
ls -ld /home/www/log /home/wwwlogs，对比第三列（属主）和第四列（属组）是否匹配上面查到的用户 - 如果属主是
root，而 worker 是www-data，那必然失败
检查整条路径的执行权限（x 权限不能漏）
Linux 要求从 / 开始，每一级父目录都得有 x 权限，Nginx 才能“走进去”。只改目标目录权限不够：
- 用
namei -l /home/www/log一次性看清全路径中哪一级缺x - 重点看中间某级是不是
drw-r--r--（没 x）或drwxr-x---（others 没 x），哪怕只是/home/www这一级没 x，整个/home/www/log就进不去
精准修复属主和权限（避免 777）
按最小权限原则操作，不扩大攻击面：
- 改属主属组（以
www-data为例）：sudo chown -R www-data:www-data /home/www/log - 设权限（
X大写只给目录加 x，不影响文件）：sudo chmod -R u+rwX,g+rwX,o-rwx /home/www/log - 如果日志路径在用户家目录（如
/home/deploy/log），必须连同父级一起授权：sudo chmod 755 /home/deploy，否则进不去
排查 SELinux 等静默拦截
有些限制不报 Permission denied，但效果一样：
- 运行
sudo sestatus -v，若为enforcing，临时放开：sudo setsebool -P httpd_write_content 1 - 长期方案：打上下文标签：
sudo semanage fcontext -a -t httpd_log_t "/home/www/log(/.*)?"，再执行sudo restorecon -Rv /home/www/log
