遇到这种权限问题很常见，尤其是自定义日志路径的时候，别着急，我们一步步排查可能的原因：

• 确认Nginx运行的用户身份
  首先得明确Nginx是以哪个用户身份运行的，你可以先查看nginx.conf里的user指令，比如通常是user nginx;或者user www-data;。也可以用命令直接查看进程所属用户：

  ps aux | grep nginx
  

  重点看worker进程的用户，这才是实际处理文件操作的进程身份。

• 检查整个路径的权限链
  很多人只改了目标目录的权限，但忽略了父目录的权限——Nginx需要对路径上的每一层目录都有执行（x）权限才能进入到目标目录。你可以用这个命令查看整个路径的权限和所有者：

  namei -l /path/to/directory/error.log
  

  确保从根目录到/path/to/directory的每一层，Nginx运行用户都有x权限。

• 确保目录和日志文件的权限正确
  如果error.log已经存在，要让Nginx用户拥有读写权限：

  chown nginx:nginx /path/to/directory/error.log
  chmod 640 /path/to/directory/error.log
  

  如果文件还不存在，Nginx需要目标目录的写入（w）权限来创建文件，所以给目录设置正确的所有者或权限：

  chown nginx:nginx /path/to/directory
  chmod 750 /path/to/directory
  

• 排查SELinux或AppArmor的限制（这是最容易忽略的点）
  很多Linux发行版有安全模块会阻止Nginx写入非默认目录：

  • 如果你用的是RHEL/CentOS等SELinux开启的系统，先把目标目录标记为Nginx允许的日志类型：

    chcon -R -t httpd_log_t /path/to/directory/
    

    要是想永久生效，可以用semanage fcontext命令配置持久规则。
  • 如果你用的是Debian/Ubuntu等AppArmor开启的系统，检查/etc/apparmor.d/usr.sbin.nginx文件，看是否包含你的目标目录路径，没有的话添加类似下面的规则：

    /path/to/directory/ r,
    /path/to/directory/* rw,
    

    然后重启AppArmor服务：

    systemctl restart apparmor
    

• 验证配置并重启
  最后先测试Nginx配置是否合法，避免其他语法错误：

  nginx -t
  

  当看到nginx: configuration file /etc/nginx/nginx.conf test is successful后，再重启Nginx服务：

  systemctl restart nginx
  

内容的提问来源于stack exchange，提问作者Bikash Chapagain