"net use" for Azure File Services fails depending on OS type

Question

Anyone know why the below "net use" command gets varied results depending on the machine OS even though I am logged on as an admin in all cases? Fails or works based on the OS within PowerShell or Cmd whether the shell is run as Administrator or not. The share is setup in Azure File Services and can be accessed on my Win10 machine just fine using Azure PowerShell cmdlets.

# mount azure share as a drive
net use x: \\[myaccount].file.core.windows.net\davesdata /user:[myaccount] [my secondary key]

• Runs fine on Server 2012
• Gets “access denied” on Server 2008
• Gets “path not found” on Windows 10

Answer 1

Port 445 was open on my router. It took me some time to find an additional option in the router: Netbios must be set to "allowed". Then, Windows 10 works fine for me.

Answer 2

Azure File Storage supports the following Windows / SMB variants: Windows 7 SMB 2.1, Windows Server 2008 R2 SMB 2.1, Windows 8 SMB 3.0, Windows Server 2012 SMB 3.0, Windows Server 2012 R2 SMB 3.0 and Windows 10 SMB 3.0.

If you are connecting from a VM within the same Azure region you can connect using SMB 2.1 or SMB 3.0. If you are connecting from outside of the Azure region you need to ensure that Port 445 outbound is open. Many ISP's / corporate filewalls will block this. This wiki contains a list of ISP's that allow / disallow Port 445.

Answer 3

To map a drive to Azure File Storage from on-prem/outside the Azure region hosting it you need SMB 3.0 which comes with Windows 8/2012 or higher. For a machine inside Azure on the same Azure region you need SMB 2.0 or higher which comes with Windows 7/2008 or higher.

Definitely works on Windows 10 using the syntax you showed, double check for typos in the path/key or more detailed error messages in the event log. The mapped drive won't survive a reboot unless you persist the credentials.

cmdkey /add:storage_account_name.file.core.windows.net /user:storage_account_name /pass:storage_account_key