Ask Learn
Preview
Please sign in to use this experience.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article lists common problems that might occur when you try to connect to and access Server Message Block (SMB) Azure file shares from Windows or Linux clients. It also provides possible causes and resolutions for these problems.
Note
Was this article helpful? Your input is important to us. Please use the Feedback button on this page to let us know how well this article worked for you or how we can improve it.
Important
This article applies only to SMB shares. For details about Network File System (NFS) shares, see Troubleshoot Azure NFS file shares.
File share type | SMB | NFS |
---|---|---|
Standard file shares (GPv2), LRS/ZRS | ![]() |
![]() |
Standard file shares (GPv2), GRS/GZRS | ![]() |
![]() |
Premium file shares (FileStorage), LRS/ZRS | ![]() |
![]() |
Select the Windows or Linux tab depending on the client operating system that you're using to access Azure file shares.
Linux clients can use AzFileDiagnostics to automate symptom detection and ensure that they have the correct prerequisites.
Common causes for this problem are:
To resolve the problem, use the troubleshooting tool for Azure Files mounting errors on Linux. This tool:
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.
If virtual network (VNET) and firewall rules are configured on the storage account, network traffic will be denied access unless the client IP address or virtual network is allowed access. In addition, if your company or ISP blocks port 445 outbound, you won't be able to mount the share.
Verify that the VNET and firewall rules are configured properly on the storage account, and that port 445 is allowlisted. 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 learn more, see Configure Azure Storage firewalls and virtual networks.
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.
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.
When storage account key access is disabled or disallowed for a storage account, SAS tokens and access keys won't work.
Use identity-based authentication instead. See Enable Active Directory authentication over SMB for Linux clients accessing Azure Files for prerequisites and instructions.
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.
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 may have backported 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 with Use Azure Files with Linux.
If your Linux SMB client doesn't support encryption, mount Azure Files 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.
A "112" mount error occurs on the Linux client when the client has been idle for a long time. After an extended idle time, the client disconnects, and the connection times out.
The connection can be idle for the following reasons:
This reconnection problem in the Linux kernel is now fixed as part of the following changes:
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.
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. You can 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 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 a customer-initiated failover scenario with geo-redundant storage accounts, file handles and leases aren't retained on failover. Clients must unmount and remount the file shares.
When you try to access or delete an Azure file share using the Azure portal, you might receive the following error:
No access Error code: 403
Verify that virtual network and firewall rules are configured properly on the storage account. To test if 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.
Browse to the storage account in which the Azure file share is located, select Access control (IAM), and verify that your user account has access to the storage account. To learn more, see How to secure your storage account with Azure role-based access control (Azure RBAC).
If you can't modify or delete an Azure file share or snapshot, it might be due to file locks or leases. Azure Files provides two ways to prevent accidental modification or deletion of Azure file shares and share snapshots:
Storage account resource locks: All Azure resources, including the storage account, support resource locks. Locks might be put on the storage account by an administrator or by services such as Azure Backup. Two variations of resource locks exist: modify, which prevents all modifications to the storage account and its resources, and delete, which only prevents deletions of the storage account and its resources. When modifying or deleting shares through the Microsoft.Storage
resource provider, resource locks are enforced on Azure file shares and share snapshots. Most portal operations, Azure PowerShell cmdlets for Azure Files with Rm
in the name (for example, Get-AzRmStorageShare
), and Azure CLI commands in the share-rm
command group (for example, az storage share-rm list
) use the Microsoft.Storage
resource provider. Some tools and utilities such as Storage Explorer, legacy Azure Files PowerShell management cmdlets without Rm
in the name (for example, Get-AzStorageShare
), and legacy Azure Files CLI commands under the share
command group (for example, az storage share list
) use legacy APIs in the FileREST API that bypass the Microsoft.Storage
resource provider and resource locks. For more information on legacy management APIs exposed in the FileREST API, see control plane in Azure Files.
Share/share snapshot leases: Share leases are a kind of proprietary lock for Azure file shares and file share snapshots. Leases might be put on individual Azure file shares or file share snapshots by administrators by calling the API through a script or by value-added services such as Azure Backup. When a lease is put on an Azure file share or file share snapshot, modifying or deleting the file share/share snapshot can be done with the lease ID. Admins can also release the lease before modification operations, which requires the lease ID, or break the lease, which doesn't require the lease ID. For more information on share leases, see lease share.
Because resource locks and leases might interfere with intended administrator operations on your storage account/Azure file shares, you might wish to remove any resource locks/leases that have been put on your resources manually or automatically by value-added services such as Azure Backup. The following script removes all resource locks and leases. Remember to replace <resource-group>
and <storage-account>
with the appropriate values for your environment.
Before running the following script, you should install the latest version of the Azure Storage PowerShell module.
Important
Value-added services that take resource locks and share/share snapshot leases on your Azure Files resources may periodically reapply locks and leases. Modifying or deleting locked resources by value-added services may impact the regular operation of those services, such as deleting share snapshots that were managed by Azure Backup.
# Parameters for storage account resource
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
-ResourceGroupName $resourceGroupName `
-Name $storageAccountName
# Remove resource locks
Get-AzResourceLock `
-ResourceType "Microsoft.Storage/storageAccounts" `
-ResourceGroupName $storageAccount.ResourceGroupName `
-ResourceName $storageAccount.StorageAccountName | `
Remove-AzResourceLock -Force | `
Out-Null
# Remove share and share snapshot leases
Get-AzStorageShare -Context $storageAccount.Context | `
Where-Object { $_.Name -eq $fileShareName } | `
ForEach-Object {
try {
$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClient)
$leaseClient.Break() | Out-Null
} catch { }
}
Select the Windows or Linux tab depending on the client operating system you're using to access Azure file shares.
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.
This issue typically occurs if the file or directory has an open handle.
If the SMB clients have closed all open handles and the issue continues to occur, perform the following:
Use the Get-AzStorageFileHandle PowerShell cmdlet to view open handles.
Use the Close-AzStorageFileHandle PowerShell cmdlet to close open handles.
Note
The Get-AzStorageFileHandle
and Close-AzStorageFileHandle
cmdlets are included in Az PowerShell module version 2.4 or later. To install the latest Az PowerShell module, see Install the Azure PowerShell module.
If the snapshot
option for the mount
command isn't passed in a recognized format, the mount
command can fail with this error. To confirm it, check kernel log messages (dmesg), and dmesg will show a log entry such as cifs: Bad value for 'snapshot'
.
Make sure you're passing the snapshot
option for the mount
command in the correct format. Refer to the mount.cifs manual page (e.g. man mount.cifs
). A common error is passing the GMT timestamp in the wrong format, such as using hyphens or colons in place of periods. For more information, see Mount a file share snapshot.
If the snapshot mount
option is passed starting with @GMT
, but the format is still wrong (such as using hyphens and colons instead of periods), the mount
command can fail with this error.
Make sure you're passing the GMT timestamp in the correct format, which is @GMT-year.month.day-hour.minutes.seconds
. For more information, see Mount a file share snapshot.
If the snapshot you're attempting to mount doesn't exist, the mount
command can fail with this error. To confirm it, check kernel log messages (dmesg), and dmesg will show a log entry such as:
[Mon Dec 12 10:34:09 2022] CIFS: Attempting to mount \\snapshottestlinux.file.core.windows.net\snapshot-test-share1
[Mon Dec 12 10:34:09 2022] CIFS: VFS: cifs_mount failed w/return code = -2
Make sure the snapshot you're attempting to mount exists. For more information on how to list the available snapshots for a given Azure file share, see Mount a file share snapshot.
Select the Windows or Linux tab depending on the client operating system you're using to access Azure file shares.
Linux clients can use AzFileDiagnostics to automate symptom detection and ensure that they have the correct prerequisites.
In Linux, you might receive an error message that resembles the following:
<filename> [permission denied] Disk quota exceeded
You've 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.
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.
Note
The Get-AzStorageFileHandle
and Close-AzStorageFileHandle
cmdlets are included in Az PowerShell module version 2.4 or later. To install the latest Az PowerShell module, see Install the Azure PowerShell module.
When a file is copied over the network, the file is decrypted on the source computer, transmitted in plaintext, and re-encrypted at the destination. However, you might see the following error when you're trying to copy an encrypted file: "You are copying the file to a destination that does not support encryption."
This problem can occur if you are using Encrypting File System (EFS). BitLocker-encrypted files can be copied to Azure Files. However, Azure Files doesn't support NTFS EFS.
To copy a file over the network, you must first decrypt it. Use one of the following methods:
Be aware that setting the registry key affects all copy operations that are made to network shares.
The ConditionHeadersNotSupported error occurs when accessing content hosted in Azure Files through an application that makes use of conditional headers, such as a web browser, access fails. The error states that condition headers aren't supported.
Conditional headers aren't yet supported. Applications implementing them will need to request the full file every time the file is accessed.
When a new file is uploaded, the CacheControl property by default is no-cache. To force the application to request the file every time, the file's CacheControl property needs to be updated from no-cache to no-cache, no-store, must-revalidate. This can be achieved using Azure Storage Explorer.
If you have questions or need help, create a support request, or ask Azure community support. You can also submit product feedback to Azure feedback community.
Please sign in to use this experience.
Sign in