Azure 文件服务的"net use"失败,具体取决于操作系统类型



有人知道为什么下面的"net use"命令会根据机器操作系统得到不同的结果,即使我在所有情况下都是以管理员身份登录的吗?无论shell是否以管理员身份运行,都会根据PowerShell或Cmd中的操作系统失败或工作。该共享是在Azure文件服务中设置的,可以在我的Win10计算机上使用Azure PowerShell cmdlet进行访问。

# mount azure share as a drive
net use x: \[myaccount].file.core.windows.netdavesdata /user:[myaccount] [my secondary key]
  • 在Server 2012上运行良好
  • 在Server 2008上获取"拒绝访问"
  • 在Windows 10上获取"未找到路径"

Azure文件存储支持以下Windows/SMB变体:Windows 7 SMB 2.1、Windows Server 2008 R2 SMB 2.1、Windows8 SMB 3.0、Windows Server 2012 SMB 3.0、WindowsServer 2012 R2 SMB 3.0和Windows10 SMB 3.0。

如果您从同一Azure区域内的VM进行连接,则可以使用SMB 2.1或SMB 3.0进行连接。如果您是从Azure区域外进行连接,则需要确保445出站端口处于打开状态。许多ISP/公司的文件墙会阻止此操作。此wiki包含允许/不允许端口445的ISP列表。

要将驱动器从托管它的Azure区域内外映射到Azure文件存储,您需要Windows 8/2012或更高版本附带的SMB 3.0。对于同一Azure区域上Azure内部的计算机,您需要Windows 7/2008或更高版本附带的SMB 2.0或更高级别。

使用您显示的语法在Windows 10上肯定有效,请仔细检查路径/键中的拼写错误或事件日志中更详细的错误消息。映射的驱动器将无法在重新启动后继续运行,除非您保留凭据。

cmdkey/add:storage_account_name.file.core.windows.net/user:storage_account_name/pass:storage-account_key

我的路由器上的445端口已打开。我花了一些时间才在路由器中找到一个附加选项:Netbios必须设置为"允许"。然后,Windows 10对我来说很好。

最新更新