今天幫同事解決一個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
刷新頁面問題解決.