This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Download Microsoft Edge More info about Internet Explorer and Microsoft Edge

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.

Important

This article only applies to SMB shares. For details on Network File System (NFS) shares, see Troubleshoot Azure NFS file shares .

Applies to

File share type

When trying to connect to an Azure file share in Windows, you might see the following errors.

Error 5 when you mount an Azure file share

System error 5 has occurred. Access is denied.

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. If the Secure transfer required 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 end-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

Connect from a client that supports SMB encryption (Windows 8/Windows Server 2012 or later).

Connect from a virtual machine (VM) in the same datacenter as the Azure storage account that's used for the Azure file share.

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

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 end users are accessing the Azure file share using Active Directory (AD) or Azure Active Directory Domain Services (Azure AD DS) 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 permissions are configured correctly:

Active Directory Domain Services (AD DS) see Assign share-level permissions .

Share-level permission assignments are supported for groups and users that have been synced from AD DS to Azure Active Directory (Azure AD) using Azure AD Connect sync or Azure AD Connect cloud sync. Confirm that groups and users being assigned share-level permissions aren't unsupported "cloud-only" groups.

Azure Active Directory Domain Services (Azure AD DS) 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
The above command returns the current IP address of the storage account. This IP address is not guaranteed to remain the same, and may change at any time. Don't hardcode this IP address into any scripts, or into a firewall configuration.
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 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 will go 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). There are various tools that are written using REST API that 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
Application or service can't access a mounted Azure Files drive
Cause
Drives are mounted per user. If your application or service is running under a different user account than the one that mounted the drive, the application won'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 login 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/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 username that's passed 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
You can use either of the following steps to work around the problem:
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.
Common causes for this problem are:
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 is enabled on the storage account, Azure Files will allow only connections that use SMB 3.x with encryption.
Solution
To resolve the problem, use the troubleshooting tool for Azure Files mounting errors on Linux. 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
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.
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
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.




    

Solution for cause 2
Verify that the VNET and firewall rules are configured properly on the storage account. To test if virtual networks 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.
"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 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.
"Mount error(112): Host is down" because of a reconnection time-out
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.
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. 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.
Unable to access, modify, or delete an Azure file share (or share snapshot)
"The user name or password is incorrect" error after a customer-initiated failover
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.
Error "No access" when you try to access or delete an Azure file share
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
Cause 1: Virtual network or firewall rules are enabled on the storage account
Solution for Cause 1
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.
Cause 2: Your user account doesn't have access to the storage account
Solution for cause 2
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).
File locks and leases
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 { }
Unable to modify, move/rename, or delete a file or directory
Select the Windows or Linux tab depending on the client operating system you're using to access Azure file shares.
Windows
Linux
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 may 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/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, which specifies the level of exclusivity of your access to the file enforced by Azure Files:
None: you have exclusive access.
Read: others may read the file while you have it open.
Write: others may write to the file while you have it open.
ReadWrite: a combination of both the Read and Write sharing modes.
Delete: others may delete the file while you have it open.
Although as a stateless protocol, the FileREST protocol 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 may use: file leases. When a file is leased, it's treated as equivalent to a file handle with a file sharing mode of None.
Although file handles and leases serve an important purpose, sometimes file handles and leases might be orphaned. When this happens, this 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 this is being caused by an orphaned file handle or lease.
Cause 1
A file handle is preventing a file/directory from being modified or deleted. You can use the Get-AzStorageFileHandle PowerShell cmdlet to view open handles.
If all SMB clients have closed their open handles on a file/directory and the issue continues to occur, you can force close a file handle.
Solution 1
To force a file handle to be closed, use the Close-AzStorageFileHandle PowerShell cmdlet.
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.
Cause 2
A file lease is preventing a file from being modified or deleted. You can check if a file has a file lease with 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 should contain the following properties:
LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked
Solution 2
To remove a lease from a file, you can 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
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 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.
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.
Can't mount an Azure file share snapshot on Linux
"Mount error(22): Invalid argument" when trying to mount an Azure file share snapshot on Linux
Cause
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'.
Solution
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.
"Bad snapshot token" when trying to mount an Azure file share snapshot on Linux
Cause
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.
Solution
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.
"Mount error(2): No such file or directory" when trying to mount an Azure file share snapshot
Cause
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
Solution
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.
Disk quota or network errors from too many open handles
Select the Windows or Linux tab depending on the client operating system you're using to access Azure file shares.
Windows
Linux
Error 1816 - Not enough quota is available to process this command
Cause
Error 1816 happens 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.
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.
ERROR_UNEXP_NET_ERR (59) when doing any operations on a handle
Cause
If you cache/hold a large number of open handles for a long time, you might see this server-side failure due to throttling reasons. When a large number of handles are cached by the client, many of those handles can go into a reconnect phase at the same time, building up a queue on the server which needs to be throttled. The retry logic and the throttling on the backend for reconnect takes 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/close open handles.
"[permission denied] Disk quota exceeded" 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'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.
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.
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.
Error "You are copying a file to a destination that does not support encryption"
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."
Cause
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.
Workaround
To copy a file over the network, you must first decrypt it. Use one of the following methods:
Use the copy /d command. It allows the encrypted files to be saved as decrypted files at the destination.
Set the following registry key:
Path = HKLM\Software\Policies\Microsoft\Windows\System
Value type = DWORD
Name = CopyFileAllowDecryptedRemoteDestination
Value = 1
Be aware that setting the registry key affects all copy operations that are made to network shares.
Error ConditionHeadersNotSupported from a Web Application using Azure Files from Browser
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.
Cause
Conditional headers aren't yet supported. Applications implementing them will need to request the full file every time the file is accessed.
Workaround
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.
Troubleshoot Azure Files
Troubleshoot Azure Files performance
Troubleshoot Azure Files authentication and authorization (SMB)
Troubleshoot Azure Files general SMB issues on Linux
Troubleshoot Azure Files general NFS issues on Linux
Troubleshoot Azure File Sync issues
Contact us for help
If you have questions or need help, create a support request, or ask Azure community support. You can also submit product feedback to Azure community support.