修復 ownCloud 空白頁/白屏死機：選擇正確的恢復路徑

首先要確定你實際上擁有的是哪種類型的空白頁。

ownCloud 的「白屏死機」只是一個症狀，而非診斷結果。最佳解決方法取決於瀏覽器是否收到伺服器錯誤、是否接收到有效的 HTML 但未能載入 JavaScript 或 CSS，或者是否連接到了根本無法存取 ownCloud 的反向代理。

這種區別至關重要，因為權衡利弊截然不同。如果 PHP 異常指向某個第三方應用程序，則停用該應用程式的風險相對較低。而更改整個安裝的檔案所有權則更具侵入性，不應作為處理 JavaScript 錯誤的首選方法。同樣，重新啟動所有服務可能暫時掩蓋問題，但無法確定問題究竟出在 PHP、代理、系統升級或某個應用程式。

本指南適用於 ownCloud Classic。根據目前的 ownCloud Classic 11 文檔，版本 11 支援基於 Docker 的部署，作業系統、PHP 執行時間、資料庫和 Apache 都位於 ownCloud 提供的容器內。較舊的 10.x 版本可能仍使用傳統的 Web 伺服器和 PHP-FPM 架構。請使用與您的部署相符的命令分支。請參閱ownCloud Classic 11 系統需求。

1. 空白頁面回傳的是 HTTP 500 錯誤，還是瀏覽器在回傳 HTTP 200 錯誤後崩潰？

開啟瀏覽器開發者工具，檢查「網路」和「控制台」標籤。另外，從終端測試該端點：

curl -I https://cloud.example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://cloud.example.com/

說明：伺服器端 500 回應指向 ownCloud、PHP、資料庫或 Web 技術棧，而不是簡單的瀏覽器渲染問題。

如果主文檔回傳500或502/503錯誤，請優先檢查伺服器和代理程式日誌。如果主文檔傳回200 錯誤，但 JavaScript 套件載入失敗並出現 404、403 錯誤或腳本異常，請優先檢查資源路徑、反向代理程式重寫、主題、快取或應用程式相容性。如果只有一台瀏覽器受到影響，請在更改伺服器之前，先在隱私視窗中測試另一台支援的瀏覽器。

2. 該問題是在 ownCloud 或 PHP 升級後出現的嗎？

這是最有價值的問題之一，因為它能立即縮小故障範圍。 ownCloud 目前的發行說明指出，ownCloud Classic 11 將最低 PHP 版本提升至 PHP 8.3，而 ownCloud Classic 11 僅支援 Docker。舊版 ownCloud 10.x 的安裝遵循不同的 PHP 相容性規則，因此請勿複製其他主要版本的 PHP 配置建議。

對於傳統的 ownCloud 10.x 安裝，請從 ownCloud 目錄執行以下命令：

sudo -u www-data ./occ status
php -v

對於 ownCloud Classic 11，請透過 Compose 部署執行 OCC：

docker compose exec owncloud occ status
docker compose exec owncloud php -v

說明：如果升級後立即出現白屏，檢查已安裝的 ownCloud 和 PHP 版本尤其重要。

將結果與您實際運行版本的發行說明進行比較。 ownCloud官方發行說明是了解目前最低版本和重大變更的正確來源。降級並非安全的通用修復方法：ownCloud 文件警告稱，降級不受支持，因為它可能會損壞資料。

3. 哪一個日誌給了第一個具體的錯誤？

日誌通常比反覆嘗試配置變更更有用。 ownCloud 管理手冊建議使用 ownCloud 日誌來診斷問題；預設情況下，日誌儲存在配置的資料目錄中，除非另有logfile設定。

傳統安裝方式的例子包括：

tail -n 100 /path/to/owncloud/data/owncloud.log
journalctl -u php-fpm --since "15 minutes ago"
journalctl -u apache2 --since "15 minutes ago"
journalctl -u nginx --since "15 minutes ago"

在 ownCloud Classic 11 中，請改用 Compose 服務進行檢查：

docker compose logs --tail=200 owncloud
docker compose ps

標題：指出應用程式或類別的 PHP 致命錯誤或堆疊追蹤訊息，比更改不相關的伺服器設定更能安全地進行故障排除。

尋找失敗請求前後出現的第一個致命異常，而不僅僅是最終的錯誤級聯。常見類別包括缺少 PHP 類別、應用程式不相容、資料庫連接失敗、配置無法讀取、缺少程式碼檔案或升級未完成時發生的異常。

ownCloud 的日誌記錄文件指出，DEBUG 日誌記錄有助於診斷問題，但會產生大量輸出，並可能影響效能。如果您暫時提高了日誌級別，請在收集相關資訊後將其恢復到較低的詳細程度。請參閱ownCloud 日誌記錄配置。

4. 是否應該停用第三方應用程式？

如果錯誤訊息指向非核心應用程式、空白頁面出現在應用程式安裝或更新之後，或故障發生在 ownCloud 升級過程中，請選擇此路徑。 ownCloud的故障排除指南明確建議在進行故障排除和升級之前停用第三方應用。

首先列出應用。在 ownCloud 10.x 版本中：

sudo -u www-data ./occ app:list
sudo -u www-data ./occ app:disable APP_ID

在 ownCloud 11 上：

docker compose exec owncloud occ app:list
docker compose exec owncloud occ app:disable APP_ID

標題：僅停用日誌中涉及的應用程式比禁用多個元件或更改整個 Web 堆疊造成的干擾更小。

這樣做的代價是功能性損失：使用者將無法使用該應用，直到其更新或重新啟用。這通常比禁用核心 ownCloud 服務更可取。 OCC 文件也指出，一些核心應用無法停用，包括 DAV、FederatedFileSharing、Files 和 Files_External。請參閱官方的通用故障排除指南和O​​CC 指令參考。

5. 什麼時候需要修復權限問題？

如果日誌中包含Permission denied“最近一次部署以錯誤用戶身份複製了 app/config 文件，或者升級替換了所有權錯誤的文件”之類的信息，則權限問題很可能是罪魁禍首。但如果唯一的證據是瀏覽器端 JavaScript 錯誤，則權限問題的可能性較小。

在進行任何可能造成系統中斷的維修工作之前，請將系統置於維護模式。對於 ownCloud 11：

docker compose exec owncloud occ maintenance:mode --on

對於傳統的 10.x 部署：

sudo -u www-data ./occ maintenance:mode --on

說明：維護模式會降低使用者活動，以便您調查已有日誌證據支持的所有權或檔案權限錯誤。

請勿執行全域遞歸升級chmod 777或從不相關的版本複製權限配置。目前的 ownCloud 11 手冊詳細記錄了 Docker 掛載的目錄中手動新增的檔案的所有權和模式apps：config所有權www-data:root、應用程式檔案0644、應用程式目錄0751和新增的設定檔0644。它還記錄了0640手動更改的.htaccess權限配置.user.ini。請使用ownCloud 11 手動升級文件作為特定版本的參考。

6. 是否應該更改 PHP 模組、OPcache 或記憶體設定？

只有當日誌或相容性檢查指向該問題時才會採取行動。這種方法的影響範圍比禁用單一有問題的應用程式要廣。缺少必要的 PHP 擴充功能可能會導致程式碼無法執行，而錯誤的 PHP 配置則會影響主機上的所有 PHP 應用程式。

對於傳統的託管 PHP 堆疊，請檢查 Web 運行時實際載入的內容：

php -m
php --ini
php -r 'phpinfo();' | grep opcache.enable

說明：當伺服器日誌中出現缺少擴充功能或執行時間不相容的情況時，PHP 模組和 OPcache 檢查很有用，但如果沒有證據，它們不應該是第一個變更。

對於 ownCloud 11，官方鏡像管理 PHP 運行時，因此更改主機上的 PHP 套件通常是錯誤的操作層面。 ownCloud 文件顯示，其 Docker 映像預設啟用 OPcache。請參閱ownCloud 記憶體快取文件。

如果在舊版系統中手動取代 PHP 檔案後懷疑 OPcache 快取過期，重新啟動 PHP-FPM 或相關的 Web/PHP 服務可以清除進程本機操作碼快取。這樣做會造成短暫的中斷，並且之後會降低冷緩存下的效能。請在修復底層檔案後再執行此操作，而不是用它來代替識別錯誤。

7. 升級是否中斷或核心檔案不一致？

如果在升級過程中或升級後立即出現白頁，請先檢查升級狀態。 ownCloud 官方升級文件建議使用 OCC 進行升級和修復，而不是手動操作資料庫。

適用於 ownCloud 11：

docker compose exec owncloud occ status
docker compose exec owncloud occ upgrade
docker compose exec owncloud occ maintenance:repair
docker compose exec owncloud occ integrity:check-core

對於 ownCloud 10.x，請使用 web 伺服器使用者下的等效 OCC 命令：

sudo -u www-data ./occ status
sudo -u www-data ./occ maintenance:repair
sudo -u www-data ./occ integrity:check-core

標題：OCC 修復適用於中斷或不一致的升級，而完整性檢查可以識別已修改或缺少的簽章核心檔案。

程式碼完整性檢查結果需要解讀。 ownCloud 文件INVALID_HASH將程式碼完整性檢查結果FILE_MISSING作為EXTRA_FILE不同的條件進行解釋。請勿透過編輯文件signature.json來消除警告。目前的 ownCloud 11 文件還規定，安裝、更新和啟用第三方應用程式必須進行簽署。請參閱ownCloud 程式碼簽署文件。

8. 如何驗證修復是否成功？

好的恢復過程不僅僅是「頁面不再空白」。也要檢查整個請求路徑：

• ownCloud 主頁傳回預期的 HTTP 狀態，而不是 500/502/503。
• 瀏覽器開發者工具未顯示任何重複出現的致命 JavaScript 錯誤或缺少核心套件。
• ownCloud 日誌不會立即記錄相同請求的新致命異常。
• occ status報告顯示已安裝實例，且無意外升級需求。
• 維護完成後，維護模式將被停用。
• 測試使用者可以登入並開啟“文件”頁面。

適用於 ownCloud 11：

docker compose exec owncloud occ maintenance:mode --off
docker compose exec owncloud occ status
curl -I https://cloud.example.com/

標題：恢復應在兩個層面得到確認：ownCloud 介面加載，伺服器端狀態和 HTTP 檢查保持正常。

哪一種解決方案能帶來最佳的風險報酬比？

ownCloud 顯示白屏時不要做什麼

• 不要display_errors僅僅為了向瀏覽器顯示堆疊追蹤資訊而在公共生產環境中啟用 PHP；請改用伺服器日誌。
• 不要遞歸地將整個 ownCloud 樹設定為全域可寫權限。
• 除非您要將受支援的備份還原到相容的環境中，否則不要將 ownCloud 降級作為快速回滾操作。
• 請勿隨意刪除資料目錄、應用程式資料、資料庫表或快取目錄。
• 如果可以單獨停用某個應用程序，請不要一次停用所有應用程式。
• 不要signature.json為了抑製完整性錯誤而編輯已簽署的核心檔案。

何時應該升級策略而不是繼續試驗？

當日誌顯示資料庫損壞、加密金鑰問題、乾淨復原後核心完整性反覆出現故障，或升級狀態無法使用已記錄的 OCC 工作流程完成時，請停止進行任何變更。此外，如果空白頁面影響生產集群，且無法在不影響資料一致性的情況下隔離單一節點，也應立即上報。

在提交支援請求之前，ownCloud 建議您收集設定報告和相關日誌。對於 ownCloud 10.x 版本，文件中記錄的命令是：

sudo -u www-data ./occ configreport:generate > config_report.txt

請使用與您的部署相對應的 OCC 執行方法，並在將輸出共用給組織外部之前檢查其中是否包含敏感資訊。 ownCloud日誌和設定收集指南解釋了支援工程師通常需要哪些資訊。

官方參考資料

• ownCloud Classic 11 常規故障排除
• ownCloud Classic 11 系統需求
• ownCloud 伺服器發行說明
• ownCloud Classic 11 手動升級
• ownCloud 日誌記錄配置