Z-Blog 重裝系統後圖片上傳失敗（提示成功但未入庫）的解決方案：目錄權限修復完整指南
問題現象
當您重新安裝 Z-Blog 系統，或在搬移網站、更換伺服器環境之後，於後臺上傳圖片時，可能遇到以下困擾：
- 系統顯示「圖片上傳成功」
- 但在「附件管理」或文章中插入圖片時，卻找不到剛剛上傳的檔案
- 伺服器錯誤日誌中出現類似「Permission denied」或「move_uploaded_file failed」的記錄
這種「假成功、真失敗」的現象，通常並非 Z-Blog 程式本身的錯誤，而是伺服器檔案權限配置不當所導致。本文將詳細說明問題的根本原因，並提供安全、有效的修復步驟。
問題分析
錯誤日誌解讀
以下是一組典型的錯誤日誌（節錄自 `/www/wwwroot/你的網域/zb_system/` 相關日誌）：
[2026-02-12 21:03:37] ERROR: move_uploaded_file(...): failed to open stream: Permission denied [2026-02-12 21:03:37] ERROR: move_uploaded_file(): Unable to move '/tmp/phpbh8bV0' to '.../202602121770901417571459.jpg'
第一條日誌指出：PHP 嘗試將上傳的圖片移動到
`/www/wwwroot/你的網域/zb_users/upload/2026/02/` 目錄時，因權限不足而無法建立新檔案。
第二條日誌則是第一條的必然結果：暫存檔案無法移動，上傳行為失敗。
為什麼重裝系統後會發生？
重新安裝 Z-Blog（或重新配置 Web 伺服器）時，可能發生以下狀況：
1. 網站目錄重新建立，預設權限被還原為 root 所有。
2. PHP 執行使用者變更，例如從 `www-data` 改為 `www` 或 `nobody`。
3. 上傳目錄未被自動賦予寫入權限，導致 PHP 程序無法寫入。
Z-Blog 的上傳路徑為 `/zb_users/upload/`，並會依照日期自動建立子目錄（如 `2026/02/`）。若此目錄的擁有者或權限模式不正確，PHP 就無法在其中儲存檔案，造成上傳失敗。
根本原因
Z-Blog 根目錄下的 `zb_users/upload/` 資料夾（及其下的日期子資料夾）對 PHP 執行使用者缺乏寫入權限。
- PHP 執行使用者：通常是 `www-data`（Debian/Ubuntu 預設）、`www`（CentOS/寶塔面板預設）或 `nobody`。
- 需要的權限：目錄擁有者應為 PHP 使用者，且權限至少為 `755`（目錄可讀、可進入，擁有人可寫入）。
解決方法（SSH 命令修復）
修復方式非常單純，只需兩條指令，強烈建議透過 SSH 終端機操作，以確保遞迴生效。
步驟 1：確認 PHP 執行使用者
執行以下命令，觀察 PHP 相關行程的第一欄：
ps aux | grep php
範例輸出（寶塔面板常見）：
www 12345 0.0 0.2 php-fpm: pool www root 12346 0.0 0.1 php-fpm: master process
此例中，PHP-FPM 工作行程的擁有者為 `www`，這就是您需要設定的使用者。
若您不確定，也可以建立一個臨時 PHP 檔案來直接輸出使用者名稱（測試後請立即刪除）：
echo "<?php echo exec('whoami'); ?>" > /www/wwwroot/您的網站目錄/whoami.php透過瀏覽器存取 `http://您的網域/whoami.php`，畫面上會顯示目前 PHP 的執行使用者。
步驟 2：修改上傳目錄擁有者及權限
假設您的 PHP 執行使用者為 `www`，網站根目錄為 `/www/wwwroot/你的網域`，請依序執行：
chown -R www:www /www/wwwroot/你的網域/zb_users/upload/ chmod -R 755 /www/wwwroot/你的網域/zb_users/upload/
指令說明：
- `chown -R www:www`：將 `upload/` 及其下所有檔案/目錄的擁有者（user）與群組（group）均設為 `www`。
- `chmod -R 755`：目錄權限設為 `755`（擁有者可讀寫執行，群組與其他人可讀執行）。
若您的 PHP 使用者是 `www-data`，則改為：
chown -R www-data:www-data /www/wwwroot/你的網域/zb_users/upload/ chmod -R 755 /www/wwwroot/你的網域/zb_users/upload/
步驟 3：驗證修復結果
1. 回到 Z-Blog 後臺，重新上傳一張圖片。
2. 檢查 `/zb_users/upload/` 下是否自動產生正確的日期子目錄，且圖片檔案成功存入。
3. 查看錯誤日誌，確認不再出現 `Permission denied` 相關記錄。
補充說明與常見問題
Q1：為什麼不直接用 777 權限？
絕對不建議！ 設定為 `777` 雖然可以暫時解決寫入問題，但也讓任何使用者（包括潛在攻擊者）都能修改或刪除這些檔案，極度危險。`755` 已足夠安全。
Q2：修復後仍然無法上傳？
請檢查以下幾點：
- 磁碟空間：執行 `df -h` 確認分割區是否已滿。
- SELinux（若為 CentOS/RHEL）：暫時停用測試 `setenforce 0`，若恢復正常則需調整 SELinux 規則。
- 防毒軟體／安全模組：部分伺服器安全軟體（如寶塔防竄改）會攔截 PHP 寫入，請至面板關閉相關功能後再試。
Q3：必須手動建立 2026/02/ 這些子目錄嗎？
不需要。 Z-Blog 會自動依日期建立子目錄，只要 `upload/` 本身權限正確，程式就能在寫入時自動建立缺失的資料夾。
Q4：重裝系統後，會不會每次都要重新設定權限？
通常只需設定一次。但如果您的網站經常更換 PHP 版本或重新安裝面板，權限可能被重置。建議將此修復步驟納入網站遷移步驟中。
結語
Z-Blog 圖片上傳「提示成功、實際未入庫」的問題，十之八九是目錄權限惹的禍。透過 SSH 正確設定 `zb_users/upload/` 的擁有者與權限，即可在五分鐘內完美解決。這不僅修復上傳功能，也讓網站維持良好的安全基線。
