Mount SMB Azure File Share on Windows

Here’s a concise summary of the article “Mount SMB Azure file share on Windows,” with key requirements and the main mounting methods (portal, PowerShell/cmd, File Explorer) presented as steppers for clarity.

Overview

• Applies to: SMB Azure file shares.

• Azure Files supports SMB Multichannel on SSD file shares. Modern Windows (SMB 3.1.1) supports AES-256-GCM on latest releases; older Windows may require specific KBs or registry changes and may be limited to AES-128-GCM or AES-128-CCM. Very old OSes (SMB 2.1 or earlier) can't use the public endpoint.

• Recommendation: use the most recent relevant Windows update (KB) for your OS.

Prerequisites and important notes

• Port 445 (TCP) must be open for SMB; use Test-NetConnection to check. If blocked by ISP/firewall, use a VPN (P2S/S2S) or ExpressRoute to tunnel SMB.

• To mount across regions or from on-premises via the public endpoint, client OS must support SMB 3.x.

• Identity-based authentication (AD DS or Microsoft Entra) is recommended over storage account keys. If using identity-based auth:

  • Assign share-level and file/directory-level permissions.

  • Remove any previously cached storage-account-key credentials before switching to AD credentials.

  • Ensure the client has network connectivity to the AD domain controllers (use VPN if needed).

  • Sign in with the AD/Microsoft Entra identity that has access.

• Storage account key mount is supported but not recommended: it grants admin-level access to the storage account.

Mounting methods (high-level)

Stepper: Mount via Azure portal

1

Portal: get the mount script

1. In the Azure portal, go to the storage account > File shares > select the file share.

2. Select Connect, pick a drive letter and choose Authentication method: Active Directory or Microsoft Entra (or Storage account key if needed).

3. Select Show script, copy it, and run it on the host you want to mount from.

2

Portal: run script (PowerShell example)

• The portal script typically tests port 445 and creates persistent credentials and a PSDrive (example in article for mapping drive Z:).

• Use the storage account FQDN suffix file.core.windows.net (or file.core.chinacloudapi.cn as shown) unless using custom domain instructions.

Stepper: Mount using Windows command line / PowerShell

1

Domain-joined VM (net use)

• Simple command: net use Z: \.file.core.chinacloudapi.cn<FileShareName>

2

Non-domain-joined VM or different AD domain

• Provide explicit credentials. Use username@domainFQDN to obtain Kerberos tickets: net use Z: \.file.core.chinacloudapi.cn<FileShareName> /user:username@domainFQDN

• For Microsoft Entra Domain Services you can also use DOMAINNAME\username as the user format.

3

PowerShell persistent mount example (domain-joined)

• Test port 445 with Test-NetConnection.

• Use cmdkey to add credentials and New-PSDrive -Persist to create a persistent mount. (Article provides a full script—replace placeholders with your values.)

Stepper: Mount with File Explorer

1

Map network drive via File Explorer

1. Open File Explorer → This PC → Map network drive.

2. Choose a drive letter and enter UNC path: \.file.core.chinacloudapi.cn<fileShareName>.

3. Check "Connect using different credentials" and Finish.

2

Provide credentials

1. In credential prompt select More choices → Use a different account.

2. For storage-account-key auth: set Email/username to the storage account name and the password to the storage account key.

3. To disconnect later: right-click the share under Network locations → Disconnect.

3

Note on File Explorer and non-domain clients

• SID→UPN translation for owners/NTFS permissions is not supported via File Explorer for non-domain-joined or different-domain VMs. To view/modify NTFS permissions and owners, use a domain-joined VM.

Access via UNC path (no drive letter)

• You can access the share by entering: \storageaccountname.file.core.chinacloudapi.cn\myfileshare in File Explorer.

• If credential prompt doesn’t appear, use: cmdkey /add:StorageAccountName.file.core.chinacloudapi.cn /user:localhost\StorageAccountName /pass:StorageAccountKey

Custom domain (CNAME) for mounts — condensed steps

1

Prepare identity-based authentication

• Ensure identity-based authentication is configured and AD accounts are synced as required.

2

Modify SPN for the storage account

• Run in AD (example): setspn -s cifs/.

• You can find via (Get-AdDomain).DnsRoot.

3

Create CNAME in AD DNS

1. In AD DNS Manager, add New Alias (CNAME) under your domain.

2. Alias name = storage account name.

3. FQDN = . (hostname must match storage-account-name).

4. Target host FQDN = .file.core.chinacloudapi.cn

• After this, clients should be able to net use \mystorageaccount.onpremad1.com.

Troubleshooting and additional resources

• If port 445 is blocked, troubleshooting guidance linked: Port 445 is blocked article and SMB connectivity troubleshooting.

• If using AD credentials and you hit issues, see “Unable to mount Azure file shares with AD credentials” troubleshooting link.

• Next steps links in article: planning, FAQ, troubleshoot pages.

Last updated: 11/14/2025

If you’d like, I can:

• Produce the exact PowerShell and net use command snippets ready to copy (with placeholders),

• Extract and format the portal-provided script shown in the article into a ready-to-run code block,

• Or produce a shorter checklist for administrators to follow. Which would you prefer?