說實(shí)話只要跑過一段時(shí)間Nginx沒人能躲過這個(gè)報(bào)錯(cuò)組合瀏覽器里一個(gè)大白板寫著403 Forbidden翻到error.log看到一行open() /xxx/index.html failed (13: Permission denied)。尤其是當(dāng)你確認(rèn)文件存在、路徑?jīng)]錯(cuò)、配置也是從默認(rèn)模板改的結(jié)果頁(yè)面死活打不開的時(shí)候那種憋屈感我太懂了。Nginx權(quán)限問題在排障里出鏡率極高但它本身并不復(fù)雜。這篇文章我會(huì)把底層邏輯講明白再按場(chǎng)景給可復(fù)現(xiàn)的修復(fù)步驟最后附上我平時(shí)排查的固定流程和踩坑清單爭(zhēng)取讓你下次碰到類似問題能在五分鐘內(nèi)定位。1. 先搞清楚Nginx權(quán)限體系的底層邏輯1.1 工作進(jìn)程是誰在跑很多人把Nginx的權(quán)限問題想得太玄其實(shí)核心就一句話運(yùn)行Nginx進(jìn)程的用戶必須對(duì)網(wǎng)頁(yè)文件有合適的訪問權(quán)限。Nginx啟動(dòng)時(shí)有個(gè)master主進(jìn)程負(fù)責(zé)加載配置、管理worker進(jìn)程。主進(jìn)程通常以root啟動(dòng)因?yàn)橐O(jiān)聽80/443這種特權(quán)端口但它干完活就會(huì)把worker進(jìn)程降權(quán)。真正處理請(qǐng)求、讀文件、寫日志的是那些worker進(jìn)程。worker進(jìn)程跑在哪個(gè)用戶下看配置文件里的user指令。常見發(fā)行版默認(rèn)值不一樣Debian/Ubuntu系常用www-dataCentOS/RHEL系常用nginx一些編譯安裝的版本可能直接用nobody。所以排查權(quán)限問題的第一步永遠(yuǎn)是確認(rèn)worker進(jìn)程的實(shí)際身份。光看配置文件的user指令是不夠的因?yàn)槟承┌l(fā)行版會(huì)在編譯時(shí)覆蓋默認(rèn)值或者配置里有include片段二次賦值。最可靠的辦法是直接看進(jìn)程ps -eo pid,user,comm | grep nginx輸出里以nginx: worker結(jié)尾的進(jìn)程屬于哪個(gè)用戶處理請(qǐng)求時(shí)就用哪個(gè)身份這是鐵律。順便提一句雖然user指令可以寫成user root;來“一勞永逸”但這是嚴(yán)重的生產(chǎn)事故隱患后文會(huì)專門解釋為什么不能這么干。1.2 目錄和文件權(quán)限到底卡在哪一層Linux的權(quán)限模型很簡(jiǎn)單文件或目錄有owner、group、others三組身份每組有r讀、w寫、x執(zhí)行三種權(quán)限。但對(duì)Nginx這類web服務(wù)來說判斷標(biāo)準(zhǔn)要從“當(dāng)前登錄用戶”換成“worker進(jìn)程的用戶身份”。這里有個(gè)新手最容易栽跟頭的地方目錄的權(quán)限含義和文件不一樣。文件讀需要r寫需要w執(zhí)行/運(yùn)行需要x。目錄r只代表“能列出目錄里有哪些名字”w代表“能在目錄里創(chuàng)建/刪除文件”x才代表“能穿過這個(gè)目錄”。對(duì)Nginx而言訪問/data/www/site/index.html需要/data、/data/www、/data/www/site每一級(jí)目錄都包含“其他用戶可執(zhí)行”others的x的權(quán)限。哪怕只有一級(jí)目錄缺了xNginx就會(huì)上報(bào)permission denied。但注意目錄缺r并不會(huì)直接阻止訪問已知文件名的文件這就是為什么有些“目錄沒讀權(quán)限”的站點(diǎn)直接輸入完整路徑能打開但瀏覽目錄列表會(huì)403?？紤]到權(quán)限配置標(biāo)準(zhǔn)安全的做法是目錄給755rwxr-xr-x文件給644rw-r--r--owner設(shè)為部署用戶或站點(diǎn)管理員。這樣owner全權(quán)控制其他所有人包括Nginx worker能讀能執(zhí)行但不能寫。1.3 SELinux這個(gè)隱藏?cái)r路虎在CentOS/RHEL及衍生發(fā)行版上大量Nginx權(quán)限問題還有一個(gè)隱形元兇SELinux。它的存在會(huì)讓“普通的Linux權(quán)限”看起來完全正常但訪問依然被拒。SELinux給每個(gè)進(jìn)程和文件都打了安全標(biāo)簽。默認(rèn)策略里Nginx進(jìn)程的域是httpd_t而網(wǎng)頁(yè)文件通常需要標(biāo)記為httpd_sys_content_t。如果你的站點(diǎn)文件放在自定義路徑比如/data/www而不是發(fā)行版默認(rèn)的/usr/share/nginx/htmlSELinux默認(rèn)不帶httpd_sys_content_t標(biāo)簽Nginx就會(huì)在系統(tǒng)調(diào)用層被攔截。最典型的現(xiàn)象是ll看文件權(quán)限一切正常nginx用戶也有權(quán)限但日志照樣報(bào)Permission denied。這時(shí)候必須檢查SELinuxgetenforce輸出Enforcing就說明SELinux在生效。再用ls -Z看文件標(biāo)簽ls -Zd /data/www如果標(biāo)簽是default_t而不是httpd_sys_content_t就可以實(shí)錘了。修SELinux的正確姿勢(shì)不是直接setenforce 0關(guān)掉雖然很多人這么干而是按后文方案給文件打標(biāo)簽。后面我在解決方案里會(huì)展開講。2. 認(rèn)識(shí)兩類最典型的權(quán)限報(bào)錯(cuò)2.1 403 Forbidden的兩種截然不同的成因我見過太多人一看403就急著調(diào)目錄權(quán)限結(jié)果越調(diào)越亂。其實(shí)403 Forbidden在Nginx里有兩種完全不同的來源必須靠error.log區(qū)分。第一種是系統(tǒng)調(diào)用層錯(cuò)誤。Nginx嘗試用worker進(jìn)程身份去open()文件內(nèi)核返回EACCESerrno 13。這種錯(cuò)誤在error.log里的特征是包含Permission denied字樣并且會(huì)帶上失敗的操作路徑。比如[error] 12345#0: *678 open() /usr/share/nginx/html/index.html failed (13: Permission denied)這種才是真正的“權(quán)限”問題需要按第3章的方案去修目錄、owner、SELinux標(biāo)簽。第二種是Nginx配置層的拒絕。文件本身讀得到但Nginx的配置邏輯決定不給你看。典型場(chǎng)景[error] 12345#0: *789 directory index of /data/www/site/ is forbidden這種情況通常是目錄里沒有index.html/index.php等索引文件而配置里又沒開autoindex on;。簡(jiǎn)單說Nginx進(jìn)得了目錄、讀得到文件列表但不知道默認(rèn)該顯示哪個(gè)文件。這不太算權(quán)限問題更像配置問題。還有一種配置層拒絕是location塊里顯式寫了deny all;或做了IP封禁。區(qū)分這兩種403的方法很簡(jiǎn)單去error.log看關(guān)鍵字。有“permission denied”的走系統(tǒng)權(quán)限排查只有“directory index is forbidden”的檢查索引文件和index指令。2.2 error.log里第13號(hào)錯(cuò)誤代表什么系統(tǒng)調(diào)用錯(cuò)誤后面跟的數(shù)字是從errno全局變量來的。13: Permission denied對(duì)應(yīng)EACCES意思是“權(quán)限不足操作不被允許”。并不是只有文件權(quán)限會(huì)導(dǎo)致EACCES像Unix socket連接、寫日志、創(chuàng)建臨時(shí)文件都可能觸發(fā)。常見的幾個(gè)errno在Nginx日志里出現(xiàn)的頻率也高我整理了一下errno含義Nginx日志里的典型表現(xiàn)13EACCES權(quán)限不足open() failed (13: Permission denied)2ENOENT文件/目錄不存在open() failed (2: No such file or directory)21EISDIR路徑是目錄open() /path failed (21: Is a directory)30EROFS文件系統(tǒng)只讀open() failed (30: Read-only file system)111ECONNREFUSED連接被拒connect() failed (111: Connection refused)排查時(shí)不要只盯著13不放有時(shí)候2號(hào)和13號(hào)是連鎖反應(yīng)比如Nginx想訪問某目錄下的默認(rèn)索引文件但目錄本身對(duì)worker進(jìn)程沒有x權(quán)限內(nèi)核可能返回的不是13而是2當(dāng)作不存在。所以“文件明明存在但報(bào)No such file or directory”時(shí)也要回頭看權(quán)限。3. 分場(chǎng)景破解權(quán)限問題3.1 靜態(tài)文件與站點(diǎn)目錄的權(quán)限修復(fù)最典型也最好修的場(chǎng)景靜態(tài)站或前端項(xiàng)目部署到服務(wù)器上結(jié)果訪問直接403。我習(xí)慣按這個(gè)順序處理第一步確認(rèn)worker進(jìn)程用戶。ps -eo user,comm | grep nginx假設(shè)返回nginx那所有判斷都以nginx用戶能否讀文件為基準(zhǔn)。第二步檢查目錄鏈路權(quán)限。namei -l /data/www/site/index.html這條命令會(huì)列出從根目錄到目標(biāo)文件的每一層權(quán)限一眼就能看出哪級(jí)目錄缺x或r。比如說f: /data/www/site/index.html drwxr-xr-x root root / drwxr-xr-x root root data drwxr-xr-x root root www drwx------ root root site -rw-r--r-- root root index.html問題立刻就清楚了site目錄權(quán)限是700只有root能進(jìn)nginx用戶被拒之門外。修復(fù)方式是把目錄改成755chmod 755 /data/www/site如果不想用迭代的chmod命令可以一條命令遞推設(shè)置目錄和文件權(quán)限find /data/www/site -type d -exec chmod 755 {} \; find /data/www/site -type f -exec chmod 644 {} \;第三步把owner調(diào)整為更適合協(xié)作的模式。如果部署用戶是deploy但它要把文件放在/data/www下給nginx讀有幾種選擇直接把文件owner改成nginxchown -R nginx:nginx /data/www/site更推薦的做法owner保持deploygroup設(shè)成nginx目錄權(quán)限755文件權(quán)限640以上再把nginx用戶加入deploy組或文件所在組。這樣開發(fā)部署方便Nginx也能讀權(quán)責(zé)邊界清晰。實(shí)操里我一般不用nginx作owner因?yàn)楹罄m(xù)程序要更新文件時(shí)會(huì)很別扭。把項(xiàng)目交給專用的部署賬戶然后把站點(diǎn)目錄的group設(shè)成nginx更順手。第四步檢查SELinux標(biāo)簽。如果你在CentOS系上文件權(quán)限改完還是403立刻檢查標(biāo)簽chcon -R -t httpd_sys_content_t /data/www/site但chcon是臨時(shí)生效重啟或執(zhí)行restorecon后會(huì)恢復(fù)。正規(guī)做法是用semanage fcontext寫持久化規(guī)則semanage fcontext -a -t httpd_sys_content_t /data/www/site(/.*)? restorecon -Rv /data/www/site如果后續(xù)還會(huì)部署新文件到該目錄這個(gè)持久化規(guī)則會(huì)自動(dòng)給新文件打正確的標(biāo)簽一勞永逸。3.2 PHP-FPM的Unix Socket權(quán)限沖突PHP類站點(diǎn)比如各種PHP框架、WordPress跑Nginx時(shí)靜態(tài)文件可能一切正常但一旦訪問PHP文件報(bào)錯(cuò)就變成了[error] connect() to unix:/run/php-fpm/php-fpm.sock failed (13: Permission denied)這種和網(wǎng)頁(yè)文件的Permission denied完全不是一回事。Nginx在這里是要把自己當(dāng)成客戶端去連接一個(gè)Unix domain socket而連接socket的權(quán)限由socket文件的權(quán)限和SELinux布爾值決定。先看socket文件本身ls -l /run/php-fpm/php-fpm.sock常見輸出是srw-rw---- 1 root php-fpm 0 某日某時(shí) php-fpm.socksocket的owner是rootowner是php-fpm組。而Nginx worker進(jìn)程是nginx用戶它不屬于php-fpm組。srw-rw----表示除了root和php-fpm組成員其他人都無法讀也無法寫nginx自然連不上。解決辦法有四種按推薦度排序方案A改PHP-FPM的socket owner/group為nginx。在PHP-FPM的pool.d/www.conf里找listen.owner nginx listen.group nginx listen.mode 0660改完重啟PHP-FPMsocket的ower/group就變成nginx了Nginx就能連。這種最省心。方案B把nginx用戶加進(jìn)php-fpm組。usermod -a -G php-fpm nginx需要讓Nginx重新加載用戶組信息通常得重啟服務(wù)。效果也是讓nginx用戶獲得socket訪問權(quán)。方案C把socket權(quán)限放寬到0666。修改listen.mode 0666。能用但不建議因?yàn)檫@是把所有本地用戶都敞開寫入socket的權(quán)限等于把后門打開給同機(jī)器的其他進(jìn)程。CenterOS系上還有第五個(gè)隱藏坑即使socket權(quán)限看起來全對(duì)可能還是連不上因?yàn)镾ELinux會(huì)攔。這時(shí)要檢查并打開布爾開關(guān)setsebool -P httpd_can_network_connect 1httpd_can_network_connect控制Nginx是否能發(fā)起網(wǎng)絡(luò)連接包括訪問socket。在CentOS 7/8上這個(gè)值默認(rèn)往往是off。順帶一提如果你用Nginx反代到本機(jī)某端口遇到connection refused或13錯(cuò)誤很多時(shí)候也是這個(gè)布爾值的鍋。我自己踩過最深的坑是改了socket權(quán)限之后忘了檢查SELinux結(jié)果還報(bào)13錯(cuò)。后來把兩個(gè)維度并成一套檢查流程ls -l看Unix權(quán)限getsebool httpd_can_network_connect看SELinux布爾量一氣呵成。3.3 反向代理與緩存目錄的權(quán)限邊界Nginx做反向代理時(shí)目錄權(quán)限問題主要在緩存目錄和臨時(shí)目錄。如果配置了proxy_cache而緩存目錄沒有正確權(quán)限會(huì)出現(xiàn)[error] mkdir() /var/cache/nginx/proxy_temp failed (13: Permission denied)這里要理解Nginx對(duì)臨時(shí)目錄和緩存目錄的權(quán)限要求worker進(jìn)程必須對(duì)它們有完全的讀寫執(zhí)行權(quán)限。因?yàn)镹ginx在代理大文件、響應(yīng)體時(shí)會(huì)先把內(nèi)容寫入臨時(shí)文件快滿或超閾值時(shí)再移動(dòng)到目標(biāo)位置。默認(rèn)臨時(shí)目錄配置在http塊里proxy_temp_path /var/cache/nginx/proxy_temp; proxy_cache_path /var/cache/nginx/proxy_cache levels1:2 keys_zonemy_cache:10m max_size10g inactive60m use_temp_pathon;把這兩類目錄的owner統(tǒng)一給nginx是正確的做法mkdir -p /var/cache/nginx/proxy_temp /var/cache/nginx/proxy_cache chown -R nginx:nginx /var/cache/nginx chmod -R 700 /var/cache/nginx權(quán)限給700就夠反正是Nginx自己的私有目錄越少對(duì)外開放越好。如果你用Nginx反代到上游比如負(fù)載均衡到多個(gè)后端節(jié)點(diǎn)還要留意上游返回內(nèi)容很大時(shí)Nginx寫臨時(shí)文件會(huì)迅速占滿磁盤。這雖然不算權(quán)限問題但經(jīng)常和權(quán)限問題一起出現(xiàn)排查時(shí)我建議順手看下df -h和目錄所屬空間是否夠用。3.4 日志文件寫不進(jìn)去怎么辦Nginx自身有兩個(gè)日志相關(guān)的大坑一是access.log/error.log本身寫不了導(dǎo)致啟動(dòng)失敗二是站點(diǎn)的業(yè)務(wù)日志目錄權(quán)限不對(duì)導(dǎo)致應(yīng)用報(bào)錯(cuò)。Nginx日志寫不了的場(chǎng)景error.log里大概率會(huì)直接出現(xiàn)[emerg] open() /var/log/nginx/error.log failed (13: Permission denied)這種往往是/var/log/nginx目錄的owner或者父目錄權(quán)限被動(dòng)過worker進(jìn)程和master進(jìn)程在啟動(dòng)階段沒權(quán)限創(chuàng)建或追加日志文件。解決辦法mkdir -p /var/log/nginx chown -R nginx:nginx /var/log/nginx用nginx -t驗(yàn)證配置沒問題后再啟動(dòng)服務(wù)。要是還不行注意看一下/var/log自身是不是權(quán)限異常某些加固腳本會(huì)把所有日志目錄都改成700 root:root那Nginx是真的寫不進(jìn)去。業(yè)務(wù)日志目錄的坑沒法用Nginx配置解決。比如PHP應(yīng)用要寫/data/www/site/runtime日志目錄而Nginx worker用戶的上下文是nginx應(yīng)用進(jìn)程PHP-FPM也是nginx用戶如果該目錄owner是別的用戶且不可寫應(yīng)用就會(huì)報(bào)錯(cuò)。這類問題排查時(shí)要區(qū)分“給Nginx的權(quán)限”和“給應(yīng)用運(yùn)行用戶的權(quán)限”別全部套用Nginx邏輯。我經(jīng)歷過一次所有改動(dòng)都正確但仍寫不進(jìn)去的情況最后發(fā)現(xiàn)是/data/www/site/runtime被chattr i加了不可變標(biāo)志。這個(gè)冷門問題值得留意排查時(shí)可執(zhí)行l(wèi)sattr /data/www/site/runtime如果看到----i--------移除標(biāo)志后用chattr -i就行。4. 一套可落地的排查流程4.1 從進(jìn)程用戶到目錄鏈路的五步檢查爛熟于心的排查順序能幫你節(jié)省大量時(shí)間。我自己總結(jié)的五步法基本覆蓋了90%的Nginx權(quán)限問題第一步最小化確認(rèn)worker身份。執(zhí)行ps -eo user,comm | grep nginx第二步確認(rèn)報(bào)錯(cuò)路徑與文件。從error.log里拿到具體路徑不要憑感覺猜目錄。日志里的路徑可能有前綴比如/usr/share/nginx/html和實(shí)際站點(diǎn)目錄不是一回事務(wù)必以日志為準(zhǔn)。第三步逐級(jí)查看目錄鏈路權(quán)限。用namei -l或手動(dòng)ls -ld每個(gè)目錄確認(rèn)每一級(jí)都有“其他人可執(zhí)行”權(quán)限。第四步確認(rèn)文件權(quán)限。文件至少要644至少不能對(duì)worker用戶封鎖讀權(quán)限。第五步查SELinux狀態(tài)和標(biāo)簽。特別在CentOS/RHEL系上這一步不能省。這五步執(zhí)行下來基本能定位“是普通Linux權(quán)限還是SELinux標(biāo)簽”的問題。如果五步全對(duì)還是報(bào)Permission denied我才會(huì)考慮是不是有chattr加固、只讀掛載或其他文件系統(tǒng)層因素。4.2 模擬用戶訪問定位權(quán)限盲區(qū)有一個(gè)特別高效的驗(yàn)證思路切換到worker用戶身份真實(shí)模擬一次Nginx訪問。先確認(rèn)worker用戶比如是nginx然后執(zhí)行sudo -u nginx cat /data/www/site/index.html如果cat讀得出來說明普通Linux權(quán)限沒問題。如果提示permission denied那就可以直接定位到具體是哪個(gè)目錄的哪個(gè)環(huán)節(jié)缺權(quán)限sudo -u nginx ls /data/www/site/對(duì)比兩條命令的結(jié)果就能判斷到底卡在目錄穿越x權(quán)限還是文件讀取r權(quán)限上。PHP-FPM socket場(chǎng)景也能模擬sudo -u nginx curl --unix-socket /run/php-fpm/php-fpm.sock http://localhost/如果curl訪問socket返回權(quán)限錯(cuò)誤說明socket的owner/group或SELinux布爾量有問題如果curl返回HTTP響應(yīng)那Nginx配置或PHP進(jìn)程本身可能是主要嫌疑。這個(gè)模擬法的好處是能區(qū)分“文件系統(tǒng)的狀態(tài)”和“Nginx的配置行為”。很多時(shí)候文件權(quán)限沒問題、SELinux也正常但Nginx依然403原因就跑到Nginx配置層去了。通過模擬命令可以直接把配置層問題從權(quán)限問題中摘出來。5. 常見問題速查與避坑筆記5.1 高頻問題對(duì)照表我把這幾年在群里、社區(qū)里見過的高頻Nginx權(quán)限問題濃縮成一張速查表實(shí)戰(zhàn)時(shí)可對(duì)照著用報(bào)錯(cuò)特征可能原因首選修復(fù)open() failed (13: Permission denied)文件在站點(diǎn)目錄目錄鏈路缺x或文件缺rSELinux標(biāo)簽不對(duì)namei -l定位缺權(quán)限層chmod 755/644SELinux下用restorecon -Rvdirectory index of /xxx is forbidden目錄下無index文件且未開autoindex放index文件或加autoindex on;慎用connect() to unix:/xxx.sock failed (13: Permission denied)socket權(quán)限不對(duì)調(diào)listen.owner/group或在PHP-FPM配置中指定nginx用戶mkdir() xxx failed (13: Permission denied)緩存目錄/臨時(shí)目錄owner不對(duì)chown -R nginx:nginx緩存目錄access.log/error.log open() failed (13)日志目錄owner不對(duì)或日志目錄被鎖chown -R nignx:nginx /var/log/nginx查lsattr反代到本機(jī)端口報(bào)13或111SELinux布爾量關(guān)閉setsebool -P httpd_can_network_connect 1文件存在但報(bào)2號(hào)No such file某級(jí)目錄權(quán)限缺x內(nèi)核“看不見”補(bǔ)目錄的x權(quán)限光看表不一定覆蓋所有場(chǎng)景但排障的時(shí)候先對(duì)照一遍大概率能省去你從零摸索的時(shí)間。5.2 幾個(gè)容易忽略的細(xì)節(jié)這一節(jié)分享幾個(gè)我在實(shí)際操作中容易踩到的細(xì)節(jié)常規(guī)文檔基本不提但影響實(shí)打?qū)崱＜?xì)節(jié)一Nginx對(duì)目錄的權(quán)限要求比想象中嚴(yán)格。目錄權(quán)限至少要711才能讓Nginx正常穿越750也能穿越owner可讀寫執(zhí)行、group可讀執(zhí)行、others沒有權(quán)限。這意味著如果你把站點(diǎn)目錄放在某用戶home目錄下比如/home/deploy/www而home目錄權(quán)限是700Nginx就永遠(yuǎn)進(jìn)不去。很多人把站點(diǎn)放在home下文件權(quán)限全對(duì)就是403原因就在home目錄沒有“其他人可執(zhí)行”。這種場(chǎng)景要么把目錄挪到/var/www或/data/www要么調(diào)整home目錄權(quán)限一般不建議。細(xì)節(jié)二不要輕易用user root;。我看到過幾次有人為了省事直接把Nginx worker設(shè)成root這樣的后果是任何漏洞都直接以root權(quán)限執(zhí)行。一旦PHP或其他模塊被攻擊影響是災(zāi)難性的。正規(guī)做法永遠(yuǎn)是給worker一個(gè)低權(quán)限賬號(hào)并把站點(diǎn)文件通過合理的方式group、ACL、sudo部署交給這個(gè)賬號(hào)訪問。細(xì)節(jié)三改完權(quán)限記得測(cè)試重載。修改配置文件或權(quán)限后先跑nginx -t確認(rèn)語(yǔ)法沒問題再用nginx -s reload平滑重載。很多時(shí)候權(quán)限問題不是沒修好而是改了配置沒生效或者語(yǔ)法報(bào)錯(cuò)導(dǎo)致根本沒加載。細(xì)節(jié)四ACL權(quán)限也可能參與。當(dāng)ls普通權(quán)限看著沒問題但Nginx還是13錯(cuò)時(shí)檢查ACLgetfacl /data/www/site如果ACL里有mask或者某條對(duì)特定用戶拒絕的記錄會(huì)直接影響Nginx的訪問判斷。用setfacl -R -m u:nginx:rX /data/www/site可以追加ACL授權(quán)這個(gè)方案特別適合那些不方便改owner的共享目錄場(chǎng)景。細(xì)節(jié)五日志輪轉(zhuǎn)也會(huì)制造權(quán)限問題。logrotate輪轉(zhuǎn)日志時(shí)如果新創(chuàng)建的日志文件owner是root而Nginx接下來要寫入就會(huì)遇到13錯(cuò)。排查時(shí)如果看到日志報(bào)錯(cuò)時(shí)間點(diǎn)集中在輪轉(zhuǎn)前后大概率就是輪轉(zhuǎn)腳本創(chuàng)建的文件權(quán)限不對(duì)。解決方式是在logrotate配置里加create 640 nginx adm這類參數(shù)確保輪轉(zhuǎn)后文件owner正確。結(jié)尾說點(diǎn)個(gè)人體會(huì)處理Nginx權(quán)限問題這幾年我最深的體會(huì)是這問題根本不算難難的是養(yǎng)成系統(tǒng)性排查習(xí)慣。很多人一看到403就直接把手頭文件chmod 777改完了還不行就開始懷疑配置、懷疑防火墻、懷疑網(wǎng)絡(luò)繞一大圈回來才知道是目錄上一級(jí)少了個(gè)x權(quán)限。與其這樣不如按前面那五步來確認(rèn)worker身份、看日志拿路徑、查目錄鏈路、查文件權(quán)限、查SELinux。每一步都用一個(gè)命令驗(yàn)證基本上兩分鐘就能定位。另外一個(gè)讓我吃過虧的細(xì)節(jié)是修改完權(quán)限后務(wù)必要重新加載Nginx和PHP-FPM。Nginx的root權(quán)限配置改了要重載PHP-FPM的listen.owner改了要重啟SELinux布爾量改了最好也重啟一下相關(guān)服務(wù)。很多人改完不重啟就在那兒反復(fù)測(cè)浪費(fèi)時(shí)間不說還容易誤判。如果你按照這個(gè)流程排完之后發(fā)現(xiàn)權(quán)限完全正常但問題依舊最后再分享一個(gè)小技巧去看error.log的完整上下文別只盯著最后一行。有時(shí)候權(quán)限問題不是根因而是連鎖反應(yīng)。比如后端PHP進(jìn)程崩潰了Nginx連不上socket日志先報(bào)connect失敗后報(bào)permission denied你把全部精力花在處理socket權(quán)限上結(jié)果后端一啟動(dòng)就全好了。前后文結(jié)合著看才能避免白忙一場(chǎng)。