WebDAV 顯示「輸入的資料夾似乎無效」的解法

對話框原文

The folder you entered does not appear to be valid. Please choose another.

你在「對應網路磁碟機」輸入 WebDAV 位址，Windows 想了一下，然後拒絕。沒有錯誤碼，也沒有提示它究竟不喜歡哪一段。同一個位址在瀏覽器可以開，換一個 WebDAV 用戶端也連得上。

Windows 是在還沒資格評論你的密碼之前就丟出這句話。它的意思只有兩種：重新導向器沒能和這個位址完成一次 WebDAV 對話，或根本沒能開始對話。原因實際上只有五個，而一條指令就能判斷你在哪一半。

第一步：先打這一條

用重新導向器的方式去問伺服器。它的第一個請求就是對你給的路徑發 OPTIONS。

curl.exe -i -X OPTIONS -u alice https://dav.example.com/

要看的只有一個標頭。WebDAV 規範 RFC 4918 寫得很直白：「All DAV-compliant resources MUST return the DAV header with compliance-class '1' on all OPTIONS responses.」所以正常的伺服器會回類似 DAV: 1, 2, 3 的回應，以及含 PROPFIND 的 Allow。

如果沒有 DAV 標頭，就別再調 Windows 了。要嘛這個路徑不是 WebDAV 根（同一份規範說，對包含 / 的非 WebDAV 資源發 OPTIONS「SHOULD NOT advertise WebDAV support」），要嘛伺服器把 WebDAV 關了。例如 Nextcloud 發佈在 /remote.php/dav/files/<user>，而不是網站根目錄。

如果標頭在，伺服器就是清白的，剩下的原因全在你自己機器上。

第二步：啟動 WebClient 服務

Windows 上所有對應的 WebDAV 磁碟機都由一個叫 WebClient 的服務處理，而微軟的淘汰功能清單寫著：「The Webclient (WebDAV) service is deprecated. The Webclient service isn't started by default in Windows.」在全新安裝的 Windows 11 上，這是單一原因裡最常見的一個。

Get-Service WebClient | Format-List Name, Status, StartType
Set-Service -Name WebClient -StartupType Automatic
Start-Service -Name WebClient

然後別馬上重試。重新導向器維護一份「判定為非 WebDAV 伺服器」的清單，ServerNotFoundCacheLifeTimeInSec 預設 60 秒；在清單裡的這段時間，按文件的說法是「a fail is returned immediately without attempting to contact the server」。剛修好就重試，看到的是快取下來的失敗。

Windows Server 上，在加入「桌面體驗」功能之前重新導向器根本沒安裝；桌面版 Windows 內建。

第三步：允許對 http:// 送出 Basic 憑證

如果端點是 http:// 且使用 Basic 驗證，Windows 會在彈窗之前就拒絕。開關是 WebClient 參數機碼下的 DWORD 值 BasicAuthLevel。微軟文件寫明 0 為停用，1 為「for SSL web sites only」，2 為「SSL and non-SSL web sites」，預設是 1。

reg add "HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters" /v BasicAuthLevel /t REG_DWORD /d 2 /f
net stop WebClient
net start WebClient

重啟服務不是可選步驟——同一處註記說明，改動該機碼下任何值之後都必須重啟 Web Client 或重新開機。也要清楚代價：未加密連線上的 Basic 驗證被文件稱為「strongly discouraged」，憑證是明文過線的。對 127.0.0.1 合理，在自己的區域網路可以辯護，走公網就是錯的。

第四步：按重新導向器要的格式寫位址

精靈要的是完整 URL，含協定與非標準埠，例如 http://dav.example.com:8080/remote.php/dav/files/alice。只寫主機名會讓 Windows 走 SMB，那條路永遠找不到 WebDAV 伺服器。

指令列更好排查，因為它回的是編號而不是句子。微軟的說明用的是一般 URL 形式 NET USE * http://www.example.com，UNC 形式則記載為 \\server[@SSL][@port][\path]，其中 @SSL 代表 HTTPS、@port 在非 80/443 時必填，DavWWWRoot 指向 WebDAV 伺服器根：

net use Z: \\dav.example.com@SSL\DavWWWRoot\files /user:alice *
net use Y: http://dav.example.com:8080/remote.php/dav/files/alice /user:alice *

如果它回 System error 67，你只是從另一個方向看同一份原因清單：net use 錯誤 67。如果檔案總管之後回報 0x80070043，那是同一個 Win32 錯誤被包成 HRESULT：錯誤 0x80070043。

第五步：微軟自己寫下的那個原因

這類拒絕背後確實有一個解析錯誤，微軟在專講這句提示的支援文章裡寫明原因：「The Windows Web Client service incorrectly assumes that all XML tags from WebDAV servers contain the namespace prefix 'DAV.' However, there are some scenarios in which this assumption is incorrect.」

換句話說，伺服器的 PROPFIND 回應即使是合法 XML，只要 DAV: 命名空間宣告方式不同，就可能被直接拒絕。微軟給的答案是替換 Webclnt.dll 的修補程式，適用於 Windows 7 與 Windows Server 2008 R2。若你用的是現代 Windows 與現代伺服器，這很少是你的原因——但當它就是原因時，再怎麼改憑證也不會好，這就是解釋。

順手排掉兩個鄰居：攔截請求的代理（重新導向器會回 System error 224，要求把網站加入信任的網站），以及憑證管理員重播的舊密碼。把該主機在 Windows 憑證下的項目全部刪掉，執行 net use Z: /delete，再試一次。

對應本機 WebDAV 伺服器時

上面每條規則在伺服器就在本機時仍然成立，因為 Windows 並不在意位址是不是回送位址。

AnyStorage（v0.2.24；macOS 11+、Windows 10+、Ubuntu 20.04+）在 http://127.0.0.1:3211 上執行內建 WebDAV 伺服器，應用程式裡開啟的每個儲存連線都會成為該根目錄下的一個資料夾——S3 儲存桶、Cloudflare R2、MinIO、Backblaze B2 或 SFTP 主機，一個磁碟機代號全都到得了，不必安裝任何檔案系統驅動程式。由於端點是 HTTP + Basic 驗證，必須先把 BasicAuthLevel 設為 2 並確保 WebClient 在執行，檔案總管才會跟它說話。免費版可用兩個連線。

下一步

• 同一失敗的編號版本：WebDAV 錯誤 0x80070043 與 net use 錯誤 67
• Windows 端的完整清單：Windows 無法連線 WebDAV
• Windows 11 改了什麼：Windows 11 上 WebDAV 無法運作