修復 Azure 檔案儲存體驗證錯誤 — NetDrive

一位 IT 管理員在 Windows Server RDS 主機上以磁碟機代號掛載了五個 Azure File Storage 共用——每個部門一個，全都是從舊的內部部署檔案伺服器搬過來的。星期一早上，Finance 共用在 NetDrive 中出現驗證錯誤，另外四個卻正常重新連線。既然自週五以來掛載設定沒有任何變動，通常就代表是憑證或共用本身變了，而不是 NetDrive 的問題。

將 Azure File Storage 掛載為永久磁碟機代號

NetDrive 讓 Google Drive、OneDrive、S3、SFTP、WebDAV 等在 Windows 與 macOS 上顯示為原生磁碟機 — 不需同步，也不需完整下載。

• 以帳戶金鑰或範圍受限的 SAS 權杖連線
• 開機自動掛載，登入前共用即已就緒
• 團隊授權讓管理員能將憑證推送到每台電腦

WindowsmacOS

下載 NetDrive →

免費試用。提供終身與訂閱方案。

Azure File Storage 與 Azure Blob——相同的錯誤，不同的原因

NetDrive 把 Azure File Storage 與 Azure Blob Storage 視為兩種不同的連線類型，兩者的驗證失敗也源自略有不同之處。Blob Storage 指向一個容器；File Storage 則指向儲存體帳戶底下一個具名的 SMB 式檔案共用。以 File Storage 為基礎的磁碟機要正確重新連線，需要三個值——儲存體帳戶名稱、憑證（帳戶金鑰或 SAS 權杖），以及正確的共用名稱——因此「上週還能用，今天卻不行」這種失敗可能發生在三個地方。

檢查 1：SAS 權杖過期或帳戶金鑰已輪替

這是最常見的原因，也是最快能排除的一項。

1. 在 Azure Portal 中開啟出問題磁碟機背後的儲存體帳戶，查看它設定的是哪一種憑證類型。
2. SAS 權杖：前往 Security + networking → Shared access signature，確認 Expiry date 尚未過期。設定當時產生、效期 90 天的權杖，三個月後會在毫無預警的情況下悄悄失效。
3. 帳戶金鑰：前往 Security + networking → Access keys，檢查 key1 或 key2 是否近期被重新產生——常見於另一位管理員出於例行安全維護輪替了憑證，卻沒意識到還有四個其他服務仍在引用舊值。
4. 產生一個範圍限定於 File 服務的新 SAS 權杖（至少包含 Read、Write、List、Create、Delete 權限），或複製目前的帳戶金鑰。
5. 開啟 NetDrive → 在 Drive Manager 中點擊該磁碟機的齒輪圖示以開啟連線設定，貼上新憑證，然後點擊 Save。

檢查 2：儲存體帳戶防火牆規則

如果憑證沒有問題，磁碟機仍然無法通過驗證，接下來該檢查儲存體帳戶的網路規則了。

1. 在 Azure Portal 中開啟該儲存體帳戶的 Networking → Firewalls and virtual networks。
2. 如果設定的是 Enabled from selected virtual networks and IP addresses 而非 All networks，Azure 會在評估憑證之前就直接拒絕連線嘗試——這在 NetDrive 端看起來與金鑰錯誤一模一樣。
3. 確認電腦目前的公用 IP，將其加入允許範圍；若該共用不需要以 IP 為基礎的限制，也可以放寬規則。

使用動態 IP 的住家或分公司連線的電腦，在這裡經常是反覆出狀況的元兇：規則加入時是正確的，但之後 ISP 已分配了不同的位址。

檢查 3：共用已重新命名或移除

與 Blob 容器不同，File Storage 共用可以在同一個儲存體帳戶下被重新命名、刪除並重建，而儲存體帳戶本身的憑證不會因此改變——也就是說帳戶金鑰或 SAS 權杖仍能正常通過驗證，但 NetDrive 找不到它最初指向的那個共用。在 Azure Portal 中前往該儲存體帳戶的 Data storage → File shares，確認共用名稱（含大小寫）與 NetDrive 連線設定中所填的完全一致。若共用是刪除後重建的，即使其他憑證都沒有改變，也要更新 NetDrive 中的共用名稱欄位。

確認修復結果

更新憑證、防火牆規則或共用名稱後，重新連線磁碟機，確認它確實在提供檔案，而不只是在磁碟機清單中顯示「Connected」。

在檔案總管中開啟該磁碟機，瀏覽一個包含你熟悉檔案的資料夾。如果清單能正常顯示、檔案也能無誤開啟，代表憑證、網路路徑與共用名稱都是正確的。

小結

NetDrive 中 Azure File Storage 的驗證失敗，絕大多數源自過期的 SAS 權杖、被輪替的帳戶金鑰、儲存體帳戶防火牆規則，或被重新命名的共用，而不是最初設定時的打字錯誤——先檢查憑證，因為它更快能排除，再檢查網路。關於初次連線的完整步驟，請參見在 Windows 上用 NetDrive 掛載 Azure File Storage；若該磁碟機實際上使用的是 Blob 容器而非檔案共用，修復 Azure Blob 驗證錯誤一文則說明了對應的情況。

— Casey, NetDrive