項目目錄下,無通過php mkdir的權限
- 首先,創建目錄|文件權限,由目錄|文件所在目錄的w權限決定。
- 弄清楚哪個用戶在mkdir。
- nginx配置裏有user
- php-fpm配置裏有user
- 顯然,nginx配置的用戶,一般對項目有r權限,可能還有日誌所在目錄|文件的w權限;而執行php函數mkdir,是php-fpm配置的用戶去執行的。
- 通過
ps aux | grep php-fpm
查看php-fpm配置的用戶是誰。 - 解決方法:可以將項目目錄的owner和group改爲php-fpm配置的用戶對應的,也可以統一設置項目目錄owner和group爲nginx,nginx與php-fpm配置的用戶均改爲nginx。
- 引入新問題,phpmyadmin無法訪問,報session權限問題
phpmyadmin session權限問題無法正常訪問
-
剛開始不太理解報錯的問題,期望通過日誌獲得更詳細報錯信息。
學會看日誌——linux那套潛規則
ps aux | grep 服務
一般可查看到服務(或進程)的配置文件-
- access_log
- error_log
-
php-fpm日誌
/etc/php-fpm.conf
配置/etc/php-fpm.d/www.conf
配置/etc/php.ini
配置
-
-
先梳理整體流程,理解期望獲得的錯誤日誌記錄在哪裏。
- nginx服務監聽到http請求,匹配,當是.php結尾的url,就call本地(127.0.0.1:9000)的服務。(這是nginx配置文件代碼的意圖)。
- 127.0.0.1:9000端口的服務是php-fpm。
-
nginx日誌:把錯誤日誌等級開到info
vim /etc/nginx/nginx.conf ## 修改 error_log /var/log/nginx/error.log info;
沒有得到詳細的報錯信息,說明不是nginx相關錯誤,並且php-fpm沒有報錯誤報給nginx,nginx就當正常返回了。
-
php-fpm日誌:
-
首先將
php.ini
,php-fpm配置的記錄日誌相關控制都打開。vim /etc/php.ini error_reporting = E_ALL & ~E_DEPRECATED display_errors = On display_startup_errors = On log_errors = On track_errors = On html_errors = On vim /etc/php-fpm.conf log_level = debug vim /etc/php-fpm.d/www.conf catch_workers_output = yes
-
發現即使訪問一個php語法有錯誤的頁面,仍沒有記錄日誌。上網查得是因爲修改了php-fpm的用戶爲nginx,而php-fpm日誌目錄的owner爲apache。
-
修改owner爲nginx後,訪問php語法錯誤頁面有日誌。但訪問phpmyadmin仍沒記錄日誌,理解可以是phpmyadmin捕獲了異常,自定義處理了,沒繼續拋給php。
-
最後還是上網查得,php-fpm修改後的用戶nginx沒有創建,寫入session文件的權限
- phpmyadmin需要用到session,即要在指定目錄(
/etc/php-fpm.d/www.conf
定義了session.save_path
),創建session文件,並寫入內容 - 而目前session.save_path的owner是apache的
- phpmyadmin需要用到session,即要在指定目錄(
-
-
最終解決:把session.save_path指定目錄的owner改爲nginx。
總結
- 優先通過查看錯誤日誌找問題
- 把記錄日誌控制開關打開,並逐步調高日誌等級。
- 梳理整個操作流程,確定報錯應該記錄在誰的錯誤日誌。
- linux裏權限問題優先考慮對某目錄|文件執行操作的用戶是否有該目錄|文件的對應操作權限,即:
- 執行操作的用戶是誰?
ps aux | grep php-fpm
一般可查看到 - 操作對象在哪?除項目目錄外,可考慮
ps aux | grep php-fpm
一般可看到配置文件,再看配置文件制定的目錄,可能是日誌,session - 操作所屬權限是r還是w或x?
- 對文件,很好理解
- 對目錄:
- r -> ls
- w -> 創建,修改文件
- x -> cd
- 執行操作的用戶是誰?