修复 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