修正 ownCloud 中的「WebDAV 介面已損壞」錯誤

如果 ownCloud 在瀏覽器中可以加載，但其管理頁面顯示“WebDAV 介面已損壞”，則檔案上傳、桌面同步和“檔案”應用程式也可能發生故障。此警告僅為症狀，並非診斷結果：DAV 端點可能無法存取、重寫錯誤、被代理或安全規則阻止，或 ownCloud 呼叫其自身公共 URL 時無法存取。

本指南適用於 ownCloud Classic Server 安裝。 ownCloud Infinite Scale 採用不同的架構和部署模型，因此請勿將 Classic Server 的 Apache 設定套用至 Infinite Scale 部署。以下連結的官方頁面涵蓋 ownCloud Server 10.15 和 10.16 以及 Classic Server 11.0；檢查中使用了已記錄的 WebDAV 路由和 Apache 要求，但具體的管理員警告可能因版本而異。

圖示說明：以下介面和終端影像僅為示意圖範例。主機名稱、狀態列和顯示值均為佔位符，並非實際安裝配置或已執行測試的聲明。

WebDAV警告是什麼意思？

WebDAV 是 ownCloud 用於列出和管理同步客戶端文件以及進行相關文件操作的基於 HTTP 的介面。瀏覽器登入僅確認 Web 介面有回應，並不能確認 WebDAV 請求是否完整地到達 ownCloud，其路徑、方法、驗證標頭和 HTTPS 連線是否完好無損。

首先確定故障是外部因素導致的，還是僅限於 ownCloud 的自我檢測。同步用戶端錯誤和經過驗證的 WebDAV 請求失敗都指向 DAV 路由或驗證問題。如果用戶端可以正常運作但管理員警告仍然存在，請測試伺服器本身是否可以解析並存取公用主機名，包括其 TLS 憑證。

步驟 1：記錄確切的 URL 並直接測試 WebDAV。

使用使用者在瀏覽器中輸入的相同主機名稱和安裝路徑。對於根網域安裝，目前的經典伺服器 DAV 路徑通常遵循以下格式：

https://cloud.example.com/remote.php/dav/files/USERNAME/

如果 ownCloud 安裝在某個路徑下，請在 `<path>` 前加上路徑/remote.php，例如 `/etc/ownCloud/` https://example.com/owncloud/remote.php/dav/files/USERNAME/。請使用您自己的帳戶名稱和 URL。不要測試虛構的主機名，也不要假設每個安裝都使用相同的子目錄。

從用戶端電腦傳送經過驗證的 PROPFIND 要求。使用 cURL 時，僅傳遞使用者名稱會提示輸入密碼，而不是將其放在命令中：

curl -i --user USERNAME -X PROPFIND \
  -H 'Depth: 0' \
  'https://cloud.example.com/remote.php/dav/files/USERNAME/'

有效的 WebDAV 驗證回應通常使用 HTTP。 A207 Multi-Status可能401只是表示憑證未被接受；A404通常指向錯誤的路由或代理路徑重寫；A403可能提示存在存取規則、WAF 或伺服器原則；而 A301或 B302可能表示用戶端或自檢未如預期執行重定向。更改配置前，請閱讀回應頭和伺服器日誌。共用指令輸出前，請隱藏使用者名稱、Cookie、令牌和公有 IP 位址。

步驟 2：檢查伺服器是否可以存取自身的公用 URL

某些設定檢查會從 ownCloud 伺服器向其配置的公共位址發出請求。請從該伺服器執行基本的 DNS 和 HTTPS 檢查，而不僅僅是從您的筆記型電腦執行：

getent hosts cloud.example.com
curl -I https://cloud.example.com/status.php

主機名稱應解析為伺服器可存取的位址，且 HTTPS 請求應順利完成，不出現憑證名稱、信任鍊或連線錯誤。如果 DNS 將伺服器指向不支援 NAT 反射（也稱為環回 NAT）的防火牆，則外部用戶端可能可以正常運作，但內部自檢會失敗。此時，可以考慮使用分離式 DNS、內部路由到反向代理或進行提供者側的網路調整；請根據您的網路設計進行盡可能小的更改。

受信任網域條目是 ownCloud 傳入請求的主機允許清單。請僅新增使用者實際使用的主機名，並遵循文件中記錄的設定步驟。切勿隨意新增內部位址。此overwrite.cli.url設定控制某些設定中命令列/後台上下文使用的 URL；它不能取代 DNS、路由或 TLS 的修復。在更改任何設定之前，請確認警告的具體內容。

步驟 3：驗證 Apache 重寫規則和目錄設置

對於 Apache 安裝，ownCloud 的手動設定指南要求mod_rewrite，AllowOverride All在使用自帶的 Apache 時，需要為 ownCloud 目錄配置 `<host>` .htaccess，以及一個與 DAV 相關的 Apache 設置，以避免 Apache 自帶的 DAV 模組接管應用程式路由。請將您的虛擬主機和目錄配置與官方指南進行比較，而不是將整個範例貼到自訂網站上。

在 Debian 或 Ubuntu 系統上，檢查已載入的重寫模組和 Apache 設定語法：

sudo apachectl -M | grep rewrite
sudo apachectl -t

如果未啟用重寫規則，請先啟用它sudo a2enmod rewrite，然後再次驗證配置，並在語法檢查通過後重新載入 Apache。確認路徑<Directory>與實際的 ownCloud 網站根目錄匹配，且配置中更高層級的覆蓋規則未被停用。避免手動將 ownCloud 產生的.htaccess重寫規則替換為通用的重寫規則；自訂規則可能會破壞應用程式路由或在升級過程中遺失。

第四步：檢查反向代理、WAF 規則和驗證標頭

如果直接透過 Web 伺服器呼叫該端點可以正常運作，但透過公用 URL 呼叫卻失敗，請檢查反向代理程式或負載平衡器。確保它保留了完整的/remote.php/dav/路徑，轉發了預期的 Host 和 HTTPS 訊息，並允許使用 WebDAV 方法，例如 `<webdav_name>`、`<webdav_name>` PROPFIND、OPTIONS` PUT<webdav_name>` 和MOVE`<webdav_name>`（如果需要）。如果代理程式移除了安裝前綴或將 DAV 請求傳送到不同的後端，則可能會導致 Web UI 顯示正常，但檔案操作失敗。

檢查請求失敗時的代理程式、Apache/Nginx 和 ownCloud 日誌。 Web 應用防火牆 (WAF) 或 ModSecurity 規則可能會拒絕某個方法或請求體。確定特定的規則 ID，並為受影響的 ownCloud 路由或請求建立一個範圍較窄的例外，然後重新測試。不要為了消除警告而全域關閉 WAF。如果 DAV 驗證僅在 FastCGI/PHP 處理程序後失敗，請驗證授權標頭是否已傳遞給 PHP；ownCloud 配置說明中記錄了此類問題。

步驟五：驗證 TLS 和重定向

WebDAV 用戶端和瀏覽器一樣，都依賴有效的 HTTPS 連線。請檢查證書是否對主機名稱有效，是否包含所需的中間證書，以及是否已執行 ownCloud 自檢的伺服器環境信任。瀏覽器可能會隱藏或單獨信任 cURL 或 PHP 報告的憑證問題。請勿透過停用證書驗證來解決問題。

檢查是否有重定向循環、意外的 HTTP 到 HTTPS 重定向，或從 DAV 路由重定向到登入頁面或通用主頁。對於瀏覽器的基本 URL 來說，重定向可能是正常的，但 DAV 請求最終應該到達應用程式端點，並且其方法和 Authorization 標頭應保持不變。如果代理程式終止了 TLS，請確認 ownCloud 是否根據代理程式的文件配置接收到了正確的轉送協定和主機。

雙方驗證修復是否成功

每次進行針對性更改後，重複相同的檢查，而不是一次更改多個圖層：

• 從用戶端向已記錄的 DAV URL 進行身份驗證，並確認回應是預期的 WebDAV 回應，通常207 Multi-Status用於 PROPFIND。
• 從 ownCloud 主機上，確認公用主機名稱可以解析，且 HTTPS 可以到達實例，而不會出現 TLS 驗證錯誤。
• 再次查看 ownCloud 管理概覽，並檢查日誌中是否有新的 DAV、代理或驗證錯誤。
• 在網頁介面或受支援的同步用戶端中測試小檔案的上傳、重新命名和下載功能。

如果用戶端請求正常但警告仍然存在，請專注於檢查伺服器本身的 DNS、路由、憑證信任以及配置的公共 URL。如果自我檢測和用戶端請求都失敗，請先檢查端點路徑、重寫規則、代理路由、請求方法和驗證轉送。如果伺服器由託管服務提供者管理，請傳送時間戳記、脫敏後的 HTTP 狀態碼、要求路徑以及符合的日誌條目；切勿傳送密碼或包含金鑰的設定資訊。

對於特定版本的指令，請將您的部署與ownCloud Server 10.15 Apache 安裝指南、ownCloud Classic WebDAV 存取文件以及ownCloud WebDAV 驗證設定說明進行比較。請遵循您已安裝版本和部署類型的相應手冊。