今天帮同事解决一个nginx的问题；
问题描述：
文件地址在浏览器中无法下载，
http://10.60.1.66:9082/upload/doc/20190510165337.docx
nginx在页面上报错信息:
403 Forbidden
报 Forbidden,第一反应是该文件没有读权限，查看该文件，妹子已经给整个目录777权限了；
| [root@localhost doc]# ll total 72 -rwxrwxrwx. 1 www www 8414 May 10 16:26 20190510162651.docx -rwxrwxrwx. 1 www www 8291 May 10 16:50 20190510165002.docx -rwxrwxrwx. 1 www www 8413 May 10 16:50 20190510165005.docx -rwxrwxrwx. 1 www www 8292 May 10 16:53 20190510165337.docx -rwxrwxrwx. 1 www www 8292 May 10 16:55 20190510165553.docx -rwxrwxrwx. 1 www www 8292 May 10 16:56 20190510165652.docx [root@localhost doc]#
|
访问项目根目录下的两个文件
http://10.60.1.66:9082/index.php
http://10.60.1.66:9082/access.log
[root@localhost server_api]# ll access.log
-rw-r--r--. 1 www www 14170 May 10 16:55 access.log
[root@localhost server_api]#
.php能正常访问,上传的文件docx, 根目录下的.log文件无法访问; 这些文件即使赋予777权限,也无法访问;
查看nginx进程的用户,发现work进程的用户是nobody
| [root@localhost ~]# ps -ef |grep nginx root 37054 1 0 May04 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf nobody 77749 37054 0 17:27 ? 00:00:00 nginx: worker process root 77813 77798 0 17:34 pts/10 00:00:00 grep nginx [root@localhost ~]# |
看到了,就很清楚了,系统确实没有nobody用户,所以即使给www属主的文件赋予777权限,nginx的work进程怎么能读取这些文件呢?
那index.php的文件又为什么能正常访问呢? 因为nginx收到.php结尾的请求,就转发给php-fpm(的默认端口9000)去处理了, php-fpm的work进程的用户是www,所以php-fpm当然访问自己所属的文件啦.
| [root@localhost ~]# ps -ef|grep php-fpm root 5150 1 0 Apr28 ? 00:00:16 php-fpm: master process (/usr/local/php/etc/php-fpm.conf) www 40653 5150 0 May05 ? 00:00:12 php-fpm: pool www www 44580 5150 0 May06 ? 00:00:11 php-fpm: pool www www 54400 5150 0 May08 ? 00:00:09 php-fpm: pool www root 78344 78181 0 18:53 pts/2 00:00:00 grep php-fpm [root@localhost ~]# |
nginx中的./conf/nginx.conf中默认注释的user是nobody, 我安装nginx时,已经把user改成了www;
查看./conf/nginx.con, 果然被别人改成了nobody. 改回www后,重启nginx即可;
下载问题解决,以为到这里就结束了....
过了一会妹子又说啦,下载文件是好了,但有个账号在后台管理系统中登陆成功后,首页无法展示全部信息;之前是正常的;
浏览器<F12>查看network中的请求,发现一个获取用户信息的接口没有返回数据;
这是个正式环境,我没有权限上传代码,无法打log;测试环境没有这个问题;所以我无法直接调试这个接口;
妹子说是我把nginx的user改为www用户后,才出现的这个问题;那验证下吧,
把/usr/local/nginx/conf/nginx.conf中的user改回nobody,发现该管理员登陆正常,说明跟www和nobody确实有关系;
nginx.conf中的user还是改为www,重启nginx;
查找属主为nobody用户的文件
find / -user nobody
搜索到/usr/local/nginx/fastcgi_temp/目录下,有大量属主为nobody的文件,查看如下:
| [root@localhost nginx]# ll total 36 drwx------. 2 www root 4096 May 10 17:24 client_body_temp drwxr-xr-x. 3 root root 4096 May 10 19:16 conf drwx------. 12 www root 4096 Apr 25 13:46 fastcgi_temp drwxr-xr-x. 2 root root 4096 Apr 24 11:04 html drwxr-xr-x. 2 root root 4096 May 10 19:17 logs drwx------. 12 www root 4096 Apr 28 00:08 proxy_temp drwxr-xr-x. 2 root root 4096 Apr 23 22:04 sbin drwx------. 2 www root 4096 Apr 23 22:04 scgi_temp drwx------. 2 www root 4096 Apr 23 22:04 uwsgi_temp [root@localhost nginx]# cd fastcgi_temp/ [root@localhost fastcgi_temp]# ll total 40 drwx------. 34 nobody nobody 4096 May 4 14:52 0 drwx------. 35 nobody nobody 4096 May 4 14:53 1 drwx------. 35 nobody nobody 4096 May 4 14:54 2 drwx------. 35 nobody nobody 4096 May 4 14:54 3 drwx------. 33 nobody nobody 4096 May 4 14:54 4 drwx------. 34 nobody nobody 4096 May 4 14:51 5 drwx------. 33 nobody nobody 4096 May 4 14:51 6 drwx------. 33 nobody nobody 4096 May 4 14:51 7 drwx------. 34 nobody nobody 4096 May 4 14:51 8 drwx------. 34 nobody nobody 4096 May 4 14:52 9 [root@localhost fastcgi_temp]# |
改变nobody用户文件的属主和属组都为www, 必须加-R递归改,只改fastcgi_tem目录的文件权限无效;
chown -R www:www /usr/local/nginx/fastcgi_temp
刷新页面问题解决.