完美解决*64099 open() “/xx/nginx/tmp/client_body/0000000043“ failed (13: Permission denied)问题

如果本文解决了你的问题，可以点个免费的赞，谢谢

问题分析

最近部署项目，遇到了通过nginx上传文件无法上传的问题，查看日志发现原因是权限不足(13: Permission denied)的问题，记录一下排错以及解决方法。

一、发现问题

通过日志得知网页用户在上传时会报错误提示

*64099 open() “/xx/nginx/tmp/client_body/0000000043” failed (13: Permission denied)

nginx的运行是由用户A来启动的

[root@localehost ~]# ps axu |grep nginx
A 16204 0.0 0.0 57276 12212 ? S 17:54 0:00 nginx: worker process
A 16205 0.0 0.0 57276 12980 ? S 17:54 0:00 nginx: worker process
A 16206 0.0 0.0 57276 13672 ? S 17:54 0:00 nginx: worker process
A 16207 0.0 0.0 57276 13840 ? S 17:54 0:00 nginx: worker process

查看一下该文件夹的权限

ll /x/nginx/tmp/
total 20
drwx------ 2 A root 4096 Feb 20 16:43 client_body
drwx------ 2 A root 4096 Feb 20 16:43 fastcgi
drwx------ 2 A root 4096 Feb 20 16:43 proxy
drwx------ 2 A root 4096 Feb 20 16:43 scgi
drwx------ 2 A root 4096 Feb 20 16:43 uwsgi

从结果上来看，用户A是文件夹的所有者，其实理论上是可以读写的，然后我就看了一下上一层的目录

[root@localehost ~]# ll /var/lib/ |grep nginx
drwxrwx— 3 nginx root 4096 Feb 16 21:22 nginx

那确实上层目录阻止了用户A继续访问

二、网上的方法

百度了一些方法
有修改nginx运行用户的，直接修改为root
修改nginx.conf文件

user root;
为了安全性考虑，这个方法不太适合当前的场景

修改顶层文件夹权限

chmod 777 -R /x/
也是处于安全性考虑，这个方案也排除了

三、修改tmp文件位置

最后想到以前做过一个修改uwsgi的tmp的文件位置

uwsgi_temp_path /home/A/nginxtmp/uwsgi_path 1 2;
这里的level1,2,3如果有值就代表存在一级，二级，三级子目录

按照上面的目录结构，写了如下的tmp文件位置参数
加在http{}以内即可

client_body_temp_path /home/A/nginxtmp/client_body 1 2;
fastcgi_temp_path /home/A/nginxtmp/fastcgi 1 2;
proxy_temp_path /home/A/nginxtmp/proxy 1 2;
scgi_temp_path /home/A/nginxtmp/scgi 1 2;
uwsgi_temp_path /home/A/nginxtmp/uwsgi_path 1 2;

新建一下目录
请将A替换为nginx运行用户

su A
mkdir /home/A/nginxtmp/
cd /home/A/nginxtmp/
mkdir client_body fastcgi proxy scgi uwsgi

测试一下配置文件是否可用

nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

重新载入一下nginx

systemctl reload nginx