Troubleshoot Azure Files connectivity and access problems (SMB)

When you try to connect to an Azure file share in Windows, you might receive the following error messages.

Error 5 when you mount an Azure file share

• System error 5 has occurred. Access is denied.

Cause 1: Unencrypted communication channel

For security, connections to Azure file shares are blocked if the communication channel isn't encrypted and the connection attempt isn't made from the same datacenter where the Azure file shares reside. If the Secure transfer required setting or the Require encryption in transit for SMB setting is enabled on the storage account, unencrypted connections within the same datacenter are also blocked. An encrypted communication channel is only provided if the user's client OS supports SMB encryption.

Windows 8, Windows Server 2012, and later versions of each system negotiate requests that include SMB 3.x, which supports encryption.

Solution for cause 1

1. Connect from a client that supports SMB encryption (Windows 8/Windows Server 2012 or later).
2. Connect from a virtual machine (VM) in the same datacenter as the Azure storage account that's used for the Azure file share.
3. If the client doesn't support SMB encryption, verify that both the Secure transfer required setting and the Require encryption in transit for SMB setting are disabled on the storage account.

Cause 2: Virtual network or firewall rules are enabled on the storage account

Network traffic is denied if the virtual network (VNET) and firewall rules are configured on the storage account, unless the client IP address or virtual network is allow-listed.

Solution for cause 2

Verify that virtual network and firewall rules are configured properly on the storage account. To test if the virtual network or firewall rules are causing the issue, temporarily change the setting on the storage account to Allow access from all networks. To learn more, see Configure Azure Storage firewalls and virtual networks.

Cause 3: Share-level permissions are incorrect when using identity-based authentication

If users are accessing the Azure file share using identity-based authentication, access to the file share fails with the "Access is denied" error if share-level permissions are incorrect.

Solution for cause 3

Validate that share-level permissions are configured correctly. See Assign share-level permissions.

Error 53, Error 67, or Error 87 when you mount or unmount an Azure file share

When you try to mount a file share from on-premises or a different datacenter, you might receive the following errors:

• System error 53 has occurred. The network path was not found.
• System error 67 has occurred. The network name cannot be found.
• System error 87 has occurred. The parameter is incorrect.

Cause 1: Port 445 is blocked

System error 53 or System error 67 can occur if port 445 outbound communication to an Azure Files datacenter is blocked. To see the summary of ISPs that allow or disallow access from port 445, go to TechNet.

To check if your firewall or ISP is blocking port 445, use the AzFileDiagnostics tool or the Test-NetConnection cmdlet.

To use the Test-NetConnection cmdlet, the Azure PowerShell module must be installed. See Install Azure PowerShell module for more information. Remember to replace <your-storage-account-name> and <your-resource-group-name> with the relevant names for your storage account.

$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"

# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445

If the connection was successful, you should see the following output:

ComputerName     : <your-storage-account-name>
RemoteAddress    : <storage-account-ip-address>
RemotePort       : 445
InterfaceAlias   : <your-network-interface>
SourceAddress    : <your-ip-address>
TcpTestSucceeded : True

Solutions for cause 1

Solution 1 — Use Azure File Sync as a QUIC endpoint You can use Azure File Sync as a workaround to access Azure Files from clients that have port 445 blocked. Although Azure Files doesn't directly support SMB over QUIC, Windows Server 2022 Azure Edition does support the QUIC protocol. You can create a lightweight cache of your Azure file shares on a Windows Server 2022 Azure Edition VM using Azure File Sync. This configuration uses port 443, which is widely open outbound to support HTTPS, instead of port 445. To learn more about this option, see SMB over QUIC with Azure File Sync.

Solution 2 — Use VPN or Azure ExpressRoute By setting up a virtual private network (VPN) or ExpressRoute from on-premises to your Azure storage account, with Azure Files exposed on your internal network using private endpoints, the traffic goes through a secure tunnel as opposed to over the internet. Follow the instructions to setup a VPN to access Azure Files from Windows.

Solution 3 — Unblock port 445 with help from your ISP/IT admin Work with your IT department or ISP to open port 445 outbound to Azure IP ranges.

Solution 4 — Use REST API-based tools like Storage Explorer or PowerShell Azure Files also supports REST in addition to SMB. REST access works over port 443 (standard tcp). Various tools that are written using REST API enable a rich UI experience. Storage Explorer is one of them. Download and Install Storage Explorer and connect to your file share backed by Azure Files. You can also use PowerShell that also uses REST API.

Cause 2: NTLMv1 is enabled

System error 53 or system error 87 can occur if NTLMv1 communication is enabled on the client. Azure Files supports only NTLMv2 authentication. Having NTLMv1 enabled creates a less-secure client. Therefore, communication is blocked for Azure Files.

To determine whether this is the cause of the error, verify that the following registry subkey isn't set to a value less than 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

For more information, see the LmCompatibilityLevel topic on TechNet.

Solution for cause 2

Revert the LmCompatibilityLevel value to the default value of 3 in the following registry subkey:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Cause 3: The file share name doesn't exist or there's a typo in the share name

Error 67 can occur when the storage account exists and the SMB endpoint is reachable, but the SMB namespace or share path can't be resolved. This problem isn't a DNS issue, an authentication issue, or a permissions issue.

Solution for cause 3

Double check the file share name. Azure file share names must be exact. Check for an extra character, missing characters, or an incorrect share name copied from the Azure portal. Retry mounting the share.

Error 64 when you mount an Azure file share

When you mount a file share from on-premises or another datacenter, you might see the following error message:

System error 64 has occurred. The specified network name is no longer available.

Cause

A proxy server or another type of Network Address Translation (NAT) device in the datapath blocks the connection to map the Azure file share. In this case, the PowerShell cmdlet Test-NetConnection might still test connectivity on port 445 successfully.

This problem occurs when the Active Directory computer or user account corresponding to the Azure storage account that hosts the FSLogix user profiles can't process Kerberos authentications. The underlying reasons might include incorrect modifications to the msDS-SupportedEncryptionTypes attribute, or the rotation of the storage account's access keys without updating the new keys on the Active Directory account.

Solution

To resolve this problem, reproduce it and collect a network trace to get more information about the error's origin. In most cases, you must work with your network or firewall administrator to allow the content to pass through the network device.

You can see Kerberos errors in a network trace, such as flows labeled as KRB Error in a netsh trace. To resolve them, enable Active Directory Domain Services authentication for Azure file shares to set up the authentication parameters properly.

Failed with error code 0x800704b3

When you try to mount an Azure file share, you receive the following error message:

Error code: 0x800704b3
Symbolic Name: ERROR_NO_NET_OR_BAD_PATH
Error description: The network path was either typed incorrectly, doesn't exist, or the network provider isn't currently available. Retype the path or contact your network administrator.

Cause

This error can occur if any core Windows network related services are disabled. Any service that explicitly depends on those network services fails to start.

Solution

Check if any of the following services are in a Stopped state in the Windows VM:

• Network Connections
• Network List Service
• Network Location Awareness
• Network Store Interface Service
• DHCP Client
• TCP/IP NetBIOS Helper
• Workstation

If you find any, start the service(s) and retry mounting the Azure file share.

Application or service can't access a mounted Azure Files drive

Cause

You mount drives per user. If your application or service runs under a different user account than the one that mounts the drive, the application can't see the drive.

Solution

Use one of the following solutions:

• Mount the drive from the same user account that contains the application. You can use a tool such as PsExec.

• Pass the storage account name and key in the user name and password parameters of the net use command.

• Use the cmdkey command to add the credentials into Credential Manager. Perform this action from a command line under the service account context, either through an interactive sign-in or by using runas.

  cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>
  

• Map the share directly without using a mapped drive letter. Some applications might not reconnect to the drive letter properly, so using the full UNC path might be more reliable:

  net use * \\storage-account-name.file.core.windows.net\share

After you follow these instructions, you might receive the following error message when you run net use for the system or network service account: "System error 1312 has occurred. A specified logon session does not exist. It may already have been terminated." If this error appears, make sure that the user name that you pass to net use includes domain information (for example: [storage account name].file.core.windows.net).

No folder with a drive letter in "My Computer" or "This PC"

If you map an Azure file share as an administrator by using the net use command, the share appears to be missing.

Cause

By default, Windows File Explorer doesn't run as an administrator. If you run net use from an administrative command prompt, you map the network drive as an administrator. Because mapped drives are user-centric, the user account that is logged in doesn't display the drives if they're mounted under a different user account.

Solution

Mount the share from a non-administrator command line. Alternatively, you can follow this TechNet topic to configure the EnableLinkedConnections registry value.

Net use command fails if the storage account contains a forward slash

Cause

The net use command interprets a forward slash (/) as a command-line option. If your user account name starts with a forward slash, the drive mapping fails.

Solution

To work around this problem, use either of the following steps:

• Run the following PowerShell command:

  New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"
  

  From a batch file, you can run the command this way:

  Echo new-smbMapping ... | powershell -command –

• Put double quotation marks around the key to work around this problem unless the forward slash is the first character. If it is, either use the interactive mode and enter your password separately, or regenerate your keys to get a key that doesn't start with a forward slash.

New-PSDrive command fails with "the network resource type is not correct" error

Cause

You might see this error message if the file share isn't accessible. For example, port 445 is blocked or there's a DNS resolution issue.

Solution

Make sure port 445 is open and check DNS resolution and connectivity to your file share.

Linux clients can use AzFileDiagnostics to automate symptom detection and ensure that they have the correct prerequisites.

Common causes for this problem include:

• You're using a Linux distribution with an outdated SMB client. See Use Azure Files with Linux for more information on common Linux distributions available in Azure that have compatible clients.
• SMB utilities (cifs-utils) aren't installed on the client.
• The minimum SMB version, 2.1, isn't available on the client.
• SMB 3.x encryption isn't supported on the client. The preceding table provides a list of Linux distributions that support mounting from on-premises and cross-region using encryption. Other distributions require kernel 4.11 and later versions.
• You're trying to connect to an Azure file share from an Azure VM, and the VM isn't in the same region as the storage account.
• If the Secure transfer required setting or the Require encryption in transit for SMB setting is enabled on the storage account, Azure Files accepts only connections that use SMB 3.x with encryption.

Solution

If the client doesn't support SMB encryption, verify that both the Secure transfer required setting and the Require encryption in transit for SMB setting are disabled on the storage account.

You can use the troubleshooting tool for Azure Files mounting errors on Linux to resolve the problem. This tool:

• Helps you to validate the client running environment.
• Detects the incompatible client configuration that would cause access failure for Azure Files.
• Gives prescriptive guidance on self-fixing.
• Collects the diagnostics traces.

"Mount error(13): Permission denied" when you mount an Azure file share

Cause 1: Unencrypted communication channel

For security reasons, connections to Azure file shares are blocked if the communication channel isn't encrypted and the connection attempt isn't made from the same datacenter where the Azure file shares reside. Unencrypted connections within the same datacenter can also be blocked if the Secure transfer required setting is enabled on the storage account. An encrypted communication channel is only provided if the user's client OS supports SMB encryption.

To learn more, see Prerequisites for mounting an Azure file share with Linux and the cifs-utils package.

Solution for cause 1

1. Connect from a client that supports SMB encryption or connect from a virtual machine in the same datacenter as the Azure storage account that's used for the Azure file share.
2. Verify the Secure transfer required setting is disabled on the storage account if the client doesn't support SMB encryption.

Cause 2: Virtual network or firewall rules are enabled on the storage account, or port 445 is blocked

If virtual network (VNET) and firewall rules are configured on the storage account, network traffic is denied unless the client IP address or virtual network is allowed access. This restriction includes scenarios where the storage account firewall blocks the VM's subnet, even when the VM and storage account are in the same region. In addition, if your company or ISP blocks port 445 outbound, you can't mount the share.

Solution for cause 2

Verify that the VM's subnet is allowlisted in the storage account firewall, and that port 445 isn't blocked. To test if virtual networks or firewall rules cause the issue, you can temporarily change the setting on the storage account to Allow access from all networks.

To check and update the virtual network rules, use the Azure portal or Azure CLI.

To use the Azure portal, follow these steps:

1. In the Azure portal, go to your storage account.
2. Under Security + networking, select Networking.
3. On the Firewalls and virtual networks tab, confirm that Enabled from selected virtual networks and IP addresses is selected and that your VM's virtual network and subnet appear under Virtual networks.
4. If the subnet isn't listed, select + Add existing virtual network, select the virtual network and subnet, and then select Add. Select Save to apply the changes.

To list the current virtual network rules by using Azure CLI, run the following command:

az storage account network-rule list --resource-group "<resource-group>" --account-name "<storage-account>" --query virtualNetworkRules

To add your VM's subnet, run:

subnetid=$(az network vnet subnet show --resource-group "<resource-group>" --vnet-name "<vnet-name>" --name "<subnet-name>" --query id --output tsv)
az storage account network-rule add --resource-group "<resource-group>" --account-name "<storage-account>" --subnet $subnetid

To test SMB connectivity after verifying the network rules, use the AzFileDiagnostics tool.

For more information, see Configure Azure Storage firewalls and virtual networks.

Cause 3: SMB client is configured to use NTLMv1

Azure Files only supports NTLMv2 (storage account key only) and Kerberos authentication for SMB file shares. NTLMv1 isn't supported. Kernel 3.3 and later versions default to NTLMv2 unless overridden with the sec mount option. Kernel 4.4 and later versions enable NTLMv2 by default and disable LANMAN. Under default configurations, NTLMv1 is kept as a negotiation only option. For more information, see your OS documentation.

Solution for cause 3

Ensure that SMB mount commands don't override the default NTLMv2 authentication via the sec option. The sec option should never use ntlm or ntlmi when connecting to SMB Azure file shares. If you set global options in /etc/samba/smb.conf, ensure that you don't disable NTLMv2.

Cause 4: Storage account key access is disabled or disallowed via a policy

When you disable or disallow storage account key access for a storage account, SAS tokens and access keys stop working.

Solution for cause 4

Use identity-based authentication instead. For prerequisites and instructions, see Enable Active Directory authentication over SMB for Linux clients accessing Azure Files.

Cause 5: SMB channel encryption is set to AES-256-GCM only

If you configure your Azure storage account to use only AES-256-GCM for SMB channel encryption, mount operations fail when the client defaults to AES-128-GCM.

Solution for cause 5

Configure the client to require AES-256-GCM by enabling the require_gcm_256 option:

# Load the CIFS module
modprobe cifs

# Set the parameter at runtime
echo 1 | sudo tee /sys/module/cifs/parameters/require_gcm_256

# Persist the configuration
echo "options cifs require_gcm_256=1" | sudo tee -a /etc/modprobe.d/cifs.conf

You can also use a Kubernetes DaemonSet to enforce AES-256-GCM on every node. See the following example:

support-cifs-aes-256-gcm.yaml

"Mount error(115): Operation now in progress" when you mount Azure Files by using SMB 3.x

Cause

Some Linux distributions don't yet support encryption features in SMB 3.x. Users might receive a "115" error message if they try to mount Azure Files by using SMB 3.x because of a missing feature. SMB 3.x with full encryption is supported only on the latest version of a Linux distro.

Solution

The encryption feature for SMB 3.x for Linux was introduced in the 4.11 kernel. This feature enables the mounting of an Azure file share from on-premises or a different Azure region. Some Linux distributions might backport changes from the 4.11 kernel to older versions of the Linux kernel that they maintain. To help determine if your version of Linux supports SMB 3.x with encryption, consult Use Azure Files with Linux.

If your Linux SMB client doesn't support encryption, mount Azure Files by using SMB 2.1 from a Linux VM that's in the same Azure datacenter as the file share. Verify that the Secure transfer required setting is disabled on the storage account.

"Mount error(112): Host is down" because of a reconnection time-out

A "112" mount error occurs on the Linux client when the client is idle for a long time. After an extended idle time, the client disconnects, and the connection times out.

Cause

The connection can be idle for the following reasons:

• Network communication failures that prevent re-establishing a TCP connection to the server when the default "soft" mount option is used.
• Recent reconnection fixes that aren't present in older kernels.

Solution

This reconnection problem in the Linux kernel is now fixed as part of the following changes:

• Fix reconnect to not defer smb3 session reconnect long after socket reconnect
• Call echo service immediately after socket reconnect
• CIFS: Fix a possible memory corruption during reconnect
• CIFS: Fix a possible double locking of mutex during reconnect (for kernel v4.9 and later)

However, these changes might not be ported yet to all Linux distributions. If you're using a popular Linux distribution, you can check Use Azure Files with Linux to see which version of your distribution has the necessary kernel changes.

Workaround

You can work around this problem by specifying a hard mount. A hard mount forces the client to wait until a connection is established or until it's explicitly interrupted. Use it to prevent errors because of network time-outs. However, this workaround might cause indefinite waits. Be prepared to stop connections as necessary.

If you can't upgrade to the latest kernel versions, you can work around this problem by keeping a file in the Azure file share that you write to every 30 seconds or less. This operation must be a write operation, such as rewriting the created or modified date on the file. Otherwise, you might get cached results, and your operation might not trigger the reconnection.

In Windows, you might see the following errors.

Orphaned file handles or leases

One of the key purposes of a file share is that multiple users and applications can simultaneously interact with files and directories in the share. To assist with this interaction, file shares provide several ways of mediating access to files and directories.

When you open a file from a mounted Azure file share over SMB, your application or operating system requests a file handle, which is a reference to the file. Among other things, your application specifies a file-sharing mode when it requests a file handle. This mode specifies the level of exclusivity of your access to the file that Azure Files enforces:

• None: you have exclusive access.
• Read: others can read the file while you have it open.
• Write: others can write to the file while you have it open.
• ReadWrite: a combination of both the Read and Write sharing modes.
• Delete: others can delete the file while you have it open.

Although the FileREST protocol is a stateless protocol and doesn't have a concept of file handles, it does provide a similar mechanism to mediate access to files and folders that your script, application, or service can use: file leases. When you lease a file, treat it as equivalent to a file handle with a file sharing mode of None.

Although file handles and leases serve an important purpose, sometimes they're orphaned. When this situation occurs, it can cause problems in modifying or deleting files. You might see error messages like:

• The process can't access the file because the file is being used by another process.
• The action can't be completed because the file is open in another program.
• The document is locked for editing by another user.
• The specified resource is marked for deletion by an SMB client.

The resolution to this issue depends on whether an orphaned file handle or lease causes the problem.

Cause 1

A file handle prevents a file or directory from being modified or deleted. Use the Get-AzStorageFileHandle PowerShell cmdlet to view open handles.

If all SMB clients close their open handles on a file or directory and the issue continues to occur, you can force close a file handle.

Solution 1

To force close a file handle, use the Close-AzStorageFileHandle PowerShell cmdlet.

Cause 2

A file lease prevents a file from being modified or deleted. You can check if a file has a file lease by using the following PowerShell commands. Replace <resource-group>, <storage-account>, <file-share>, and <path-to-file> with the appropriate values for your environment.

# Set variables 
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
        -ResourceGroupName $resourceGroupName `
        -Name $storageAccountName

# Get reference to file
$file = Get-AzStorageFile `
        -Context $storageAccount.Context `
        -ShareName $fileShareName `
        -Path $fileForLease

$fileClient = $file.ShareFileClient

# Check if the file has a file lease
$fileClient.GetProperties().Value

If a file has a lease, the returned object contains the following properties:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Solution 2

To remove a lease from a file, release the lease or break the lease. To release the lease, you need the LeaseId of the lease, which you set when you create the lease. You don't need the LeaseId to break the lease.

The following example shows how to break the lease for the file indicated in cause 2 (this example continues with the PowerShell variables from cause 2):

$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null

Linux clients can use AzFileDiagnostics to automate symptom detection and ensure that they have the correct prerequisites.

In Linux, you might see the following issues.

Open handles on files or directories

Cause

This issue typically occurs if the file or directory has an open handle.

Solution

If the SMB clients close all open handles and the issue continues, perform the following steps:

• Use the Get-AzStorageFileHandle PowerShell cmdlet to view open handles.

• Use the Close-AzStorageFileHandle PowerShell cmdlet to close open handles.

Error 1816 - Not enough quota is available to process this command

Cause

Error 1816 occurs when you reach the upper limit of concurrent open handles that are allowed for a file or directory on the Azure file share. For more information, see Azure Files scale targets.

Solution

Reduce the number of concurrent open handles by closing some handles, and then retry. For more information, see Microsoft Azure Storage performance and scalability checklist.

To view open handles for a file share, directory, or file, use the Get-AzStorageFileHandle PowerShell cmdlet.

To close open handles for a file share, directory, or file, use the Close-AzStorageFileHandle PowerShell cmdlet.

ERROR_UNEXP_NET_ERR (59) when doing any operations on a handle

Cause

If you cache or hold a large number of open handles for a long time, you might see this server-side failure due to throttling. When the client caches many handles, many of those handles enter a reconnect phase at the same time. This phase builds up a queue on the server that needs to be throttled. The retry logic and the throttling on the backend for reconnect take longer than the client's timeout. This situation manifests itself as a client not being able to use an existing handle for any operation, with all operations failing with ERROR_UNEXP_NET_ERR (59).

There are also edge cases in which the client handle becomes disconnected from the server (for example, a network outage lasting several minutes) that could cause this error.

Solution

Don't keep a large number of handles cached. Close handles, and then retry. Use Get-AzStorageFileHandle and Close-AzStorageFileHandle PowerShell cmdlets to view and close open handles.

If you're using Azure file shares to store profile containers or disk images for a large-scale virtual desktop deployment or other workloads that open handles on files, directories, and/or the root directory, you might reach the upper scale limits for concurrent open handles. In this case, use an additional Azure file share and distribute the containers or images between the shares.

Linux clients can use AzFileDiagnostics to automate symptom detection and ensure that they have the correct prerequisites.

"[permission denied] Disk quota exceeded" error when you try to open a file

In Linux, you might receive an error message that resembles the following:

<filename> [permission denied] Disk quota exceeded

Cause

You reached the upper limit of concurrent open handles that are allowed for a file or directory.

Azure Files supports 10,000 open handles on the root directory and 2,000 open handles per file and directory within the share.

Solution

Reduce the number of concurrent open handles by closing some handles, and then retry the operation.

To view open handles for a file share, directory, or file, use the Get-AzStorageFileHandle PowerShell cmdlet.

To close open handles for a file share, directory, or file, use the Close-AzStorageFileHandle PowerShell cmdlet.