Troubleshooter for Azure Files storage problems


What does this guide do?

This guided walk-through provides steps to assist you with problems connecting/mapping/mounting Azure Files shares. The following scenarios are covered:

  1. Unable to create an Azure Files share
  2. Unable to connect to an Azure Files share.
  3. Unable to view or access a mapped drive hosted in Azure Files.
  4. Unable to access a file that's hosted in Azure Files.

In this guided walk-through, you can also find the resolution for the following errors:

  • Port 445 issue, Error 53, Error 67, or Error 87 when you mount or unmount an Azure file share
  • Error 1816 “Not enough quota is available to process this command” when you copy to an Azure file share
  • Error "You are copying a file to a destination that does not support encryption"

Who is it for?

Anyone who is working with Azure Files shares using Windows or Linux.

How does it work?

This troubleshooter provides a checklist and a sequence of steps to identify the problem and guide you to resolution.

Estimated time of completion

Varies depending on your scenario, but may take anywhere from 15 min to 2 hours.

Before using this guide, try the following troubleshooting script that automatically detects mounting file share problems and provides prescriptive fix guidance. In case the script can’t solve your problem, select a scenario and continue with the guide for troubleshooting.

 Troubleshooting script for Windows

 Troubleshooting script for Linux

Select your scenario:

Before using this guide, try the following troubleshooting script that automatically detects mounting file share problems and provides prescriptive fix guidance. In case the script can’t solve your problem, select a scenario and continue with the guide for troubleshooting.

 Troubleshooting script for Windows

 Troubleshooting script for Linux

Select your scenario:

Azure Files is only available on a Standard Storage account. To verify the storage account type, follow these steps:

1. go to the Azure portal>All resources >Storage Account name > Overview

2. In the Overview page, check the Performance to identify the type of the storgae.

Imagen de tipo de almacenamiento de información de cheque

 

The Premium storage account does not support File storage.  For more information about how to create File share in a Standard Storage account, see Create a file share in Azure Files.

Did this fix your issue?

If you're using SMB 2.1 version for Azure Files storage and connect the Azure Files share from the secondary region, it doesn't support.

Azure Files supports GRS (data is replicated to the secondary region), but not RA-GRS (data can be accessed read-only from the secondary region), so you can't access the data read-only from the secondary region. For additional information see When should I use Azure Files versus blob storage?

Did this fix your issue?

The Azure Files connectivity issues might be various depends on the operating system that you’re running on the clients.

Please select the scenario per your operating system

Select the problem that you're experiencing:

Select the symptoms that you're experiencing:

Failed to initially access the Azure Files share (For Windows)


Cause

Azure File storage is a service that offers file shares in the cloud using the standard Server Message Block (SMB) Protocol.  For security reasons, connections to Azure Files shares are blocked if the communication channel is not encrypted and the connection attempt is not made from the same Azure region on which Azure File shares reside. Communication channel encryption is not provided if the user's client OS doesn't support SMB encryption. This is indicated by a "System error 53 has occurred. Access is denied" Error message when a user tries to mount a file share from on-premises or from a different data center. Windows 8, Windows Server 2012, and later versions of each negotiate request that includes SMB 3.0, which supports encryption.

Solution

To fix this issue, connect from a client that meets the requirements of Windows 8, Windows Server 2012 or later versions, or that connect from a virtual machine that is on the same Azure region as the Azure Storage account that is used for the Azure File share.

Did this fix your issue? 

Cause

"System Error 53" or "System Error 67" when you mount an Azure file share can occur if Port 445 outgoing communication to Azure Files Azure region is blocked. For more information, see Summary of ISPs that allow or disallow access from port 445.

To understand whether this is the reason behind the "System Error 53" message, you can use Portqry to query the TCP:445 endpoint. If the TCP:445 endpoint is displayed as filtered, the TCP port is blocked. Here is an example query:

g:\DataDump\Tools\Portqry>PortQry.exe -n [storage account name].file.core.windows.net -p TCP -e 445

If the TCP 445 is blocked by a rule along the network path, you notice the following output:

TCP port 445 (microsoft-ds service): FILTERED

For more information about how to use Portqry, see Description of the Portqry.exe command-line utility.

Solution

If you‘re a common user, work with the IT organization to open Port 445 outgoing to Azure IP ranges.

If you’re an IT administrator, follow the instructions:

  1. Use tool PsPing to verify the client can communicate on TCP Port 445 with the following command:
     psping <Storage Account Name>.file.core.windows.net 445

   If you receive the Request timed out result, it indicates communication cann‘t occur over TCP Port 445.

  1. Use tool PortQry  to query the TCP:445 endpoint with the following command:
    PortQry.exe -n [Storage Account name].file.core.windows.net -p TCP -e 445
    If you receive the TCP port 445 (microsoft-ds service): FILTERED result, it indicates TCP 445 being blocked by a rule along the network path.
    For more information about how to use PortQry, see https://support.microsoft.com/kb/310099.
  2. If the customer or user is trying to access this port over Internet, that might be the Internet Service Provider (ISP) blocked the TCP port 445, when this happens you will notice the followings:
    1. SMB connectivity events could be seen under : \Winevt\Logs\Microsoft-Windows-SmbClient%4Connectivity.evtx
    2. You see Event 30803 when the connection try to any file share fails from a Windows Clients
      《log》

Comcast and some IT organizations might block this port. To unblock the TCP port 445, follow this article : Azure/Storage/TSG/What to do when an ISP Blocks TCP port 445

Did this fix your issue?

Symptom 1: Your application or service are not able to access mounted Azure Files drive which worked previously

 

Symptom 2: You receive an error message "Microsoft Windows Network: Multiple connections..."  that  resembles the following:

Microsoft Windows Network: Multiple connections to a server or shared resource by the same user, using more that one user name, are not allowed.

4022301_image3

Symptom 3: You receive an error message that resembles the following:

You are copying a file to a destination that does not support encryption   

 

Select the symptoms that you're experiencing:

Symptoms 1: When you try to access a mapped network which previously worked from Linux, you receive a "mount error(112)" message on existing file shares that resemblles as follow:  

mount error(112): Host is Down error

 

Symptom 2: The shell is hung when you try to access the mount point from Linux 

 

Select the symptoms that you're experiencing:

Cause

"System Error 53 or System error 87" can also be received if NTLMv1 communication is enabled on the clients. Azure Files will block the communication because having NTLMv1 enabled makes the clients less-secure.

To verify whether this is the cause of the error, verify that the following registry subkey is set to a value other than 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel.

For more information, see the LmCompatibilityLevel topic on TechNet.

Solution

Azure Files supports only NTLMv2 authentication, this corresponds to the LmCompatibilityLevel registry value should be set to 3. To fix this issue, follow one the the instrucrions per your situation:

  • If this error only happens on a single client, revert the LmCompatibilityLevel value in the HKLM\SYSTEM\CurrentControlSet\Control\Lsa registry key to the default value of 3 on the client.
  • If this error happens on multiple clients or in a domain, it is recommended to apply this setting via Group Policy. The relevant Group Policy setting is "Send NTLMv2 response only." To prevent this error occurs, make sure that Group Policy is applied to the clients with following:  
  1. The following article describes how to configure clients to use NTLMv2 using Group Policy: how to configure clients to use NTLMv2 using Group Policy

Note The recommended group policy setting for clients is Send NTLMv2 response only. It's also considered a security best practice.

  1. Make sure to run gpupdate /force from an elevated Command Prompt after applying this policy, and restart the machine that is having trouble connecting.

Did this fix your issue?

<need content here>

Symptom

  • In Windows, you receive error messages that resemble the following:

1816 ERROR_NOT_ENOUGH_QUOTA <--> 0xc0000044 STATUS_QUOTA_EXCEEDED Not enough quota is available to process this command Invalid handle value GetLastError: 53

  • In Linux, you receive error messages that resemble the following:

<filename> [permission denied] Disk quota exceeded

Cause

This problem occurs because you have reached the upper limit of concurrent open handles that a file enables.

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.

 

Did this fix your issue?

  • If you don't have a specific minimum I/O size requirement, we recommend that you use 1 MB as the I/O size for optimal performance.
  • If you know the final size of a file that you are extending with writes, and your software doesn't have compatibility issues when the not yet written tail on the file that containing zeros, then set the file size in advance instead of every write being an extending write.
  • Use the appropriate copy method:

Did this fix your performance issue?

For clients who are running Windows 8.1 or Windows Server 2012 R2, make sure that the hotfix KB3114025 is installed. This hotfix improves the create and close handle performance.

You can run the following script to check whether the hotfix has been installed on:

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

If hotfix is installed, the following output is displayed:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies{96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

 

Did this fix your issue?

A possible reason for slow performance could be that caching is disabled. In order to check whether caching is enabled, look for "cache=". cache=none indicates that caching is disabled. Please remount the share with default mount command or explicitly adding cache=strict option to mount command to make sure default caching or "strict" caching mode is enabled.

In some scenarios, serverino mount option can cause ls command to run stat against every directory entry and this behavior results in performance degradation when you list a big directory. You can check the mount options in your "/etc/fstab" entry:

//<storage-account-name>.file.core.windows.net/<file-share-name> <mount-point> cifs vers=3.0,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

You can also check if correct options are being used by just running the command sudo mount | grep cifs (sample output below).

If the cache=strict or serverino options are not present, unmount and mount Azure Files again by running the mount command from the documentation and re-check that "/etc/fstab" entry has the correct options in place.

Did this fix your issue?

 

We’re glad this troubleshooter help you to resolve your issue.

We're sorry for that this troubleshooter cannot resolve your issue. Contact support to get your issue resolved quickly. Please have the following information ready:

  1. First, it is important to understand when the issue occurs:
    1. Is this a new deployment?
    2. When was the last time the Azure Files share worked?
    3. What was the last change done before you started seeing this issue?
    4. Does the issue always happen, or is it sometimes possible to connect to the share?
  2. It is also important to understand where the issue occurs:
    1. Does the issue occur only in an Azure Virtual Machine, only from on-premises, or both?
    2. Does the issue occur only with Windows, only with Linux, or with both?
    3. Are you able to use other Azure Virtual Machines to connect to the share?
    4. Do you have other Storage Accounts in the same location which have file shares hosted? Can you connect to you?
  3. Finally, you should determine the specific failure
    1. Are there any error messages being displayed? If so, where are you seeing the error messages?
    2. Specific error message text - What is the exact error message that you are seeing? Does it provide any clues as to the cause of the failure?
  4. Collect a network trace of the issue (for an example, using tcpdump) on Linux or use PerfInsight with the scenario "Azure Files analysis" on Windows, and open a support ticket by using the Azure portal.

 

Cause

By default, Windows File Explorer does not 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 does not display the drives if they are mounted under a different user account.

Resolution

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

Did this fix your issue?

Symptoms

The customer is trying to map a network drive with "net use." The Storage Account key contains a forward slash. When they try to map the drive, they may receive an error message that resembles the following:

The option ID == is unknown.

Cause

The Command Interpreter (cmd.exe) is interpreting everything after the forward slash (/) as a command line option.

Resolution

To fix this issue, you can use PowerShell to map the network drive, as PowerShell will not interpret the forward slash as a command-line option.

  • Using PowerShell by itself

Open elevated PowerShell or PowerShell ISE, and run the following command:

New-SmbMapping -LocalPath z: -RemotePath \\StorageAccountName.file.core.windows.net\sharename -UserName StorageAccountName -Password "AccountPassword"

  • Using PowerShell in a script

You can invoke PowerShell from a script in the following way:

Echo New-SmbMapping -LocalPath z: -RemotePath \\StorageAccountName.file.core.windows.net\sharename -UserName StorageAccountName -Password "AccountPassword" | powershell -command -

Note: The trailing '-' is required.

Did this fix your issue?

Cause

Error 53 is ERROR_BAD_NETPATH, which is "The network path was not found." It's a generic error message when the SMB client is unable to communicate with the Azure Files server.

Error 67 usually occurs because Port 445 outgoing communication to Azure Files Azure region is blocked.

Error 87 occurs if the client has enabled the NTLMv1 communication when the LmCompatibilityLevel value in the registry key is set other than 3.

You have to investigate why the Windows client cannot communicate with Azure Files.

Resolution

To fix these issues, follow the instructions:

Step1: Check the SMB version and supported client operating system

When a client accesses File storage, a protocol called Server Message Block (SMB) Protocol performed the accessing File shares over the network. The SMB version used depends on the supported operating system, see supported Windows operating system and SMB version.

Note If you use SMB 2.1 to access a file share, you must access the share from a VM in the same region. If you want to access a file share from anywhere or use SMB encryption, you must use SMB 3.0 and the supported operating system.

Step2: Check DNS name resolution

Any network communication has to start with name resolution. Make sure we can resolve the URL to a valid IP address is a good test to make sure name resolution is working. To verify the DNS name resolution issue, follow the instructions:

  1. Ask the user to ping the Files storage URL, and check that it resolves to an Azure IP address.

    Note The IP address that's resolved for *.file.core.windows.net will differ from the IP address that's resolved for *.blob.core.windows.net, *.table.core.windows.net, or *.queue.core.windows.net.

  2. Check the SMB connectivity event logs under the following path :
    Application and services logs > Microsoft > SMBClient > Connectivity 

You can also access this event log file by using the following location: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-SmbClient%4Connectivity.evtx

Step3: Check whether communication can occur over TCP Port 445

When you mount an Azure file share, you receive error message "System Error 53" or "System Error 67" if Port 445 outgoing communication to Azure Files Azure region is blocked.

  1. Use tool PsPing to verify the client can communicate on TCP Port 445 with the following command:
    psping StorageAccountName.file.core.windows.net 445

If you receive the Request timed out result, it indicates communication can‘t occur over TCP Port 445.

  1. Use tool PortQry to query the TCP:445 endpoint with the following command:

    PortQry.exe -n StorageAccountName.file.core.windows.net -p TCP -e 445

    If you receive the TCP port 445 (microsoft-ds service): FILTERED result, it indicates TCP 445 being blocked by a rule along the network path.
    For more information about how to use PortQry, see https://support.microsoft.com/kb/310099.

  2. If the customer or user tries to access this port over Internet, that might be the Internet Service Provider (ISP) blocked the TCP port 445, when this happens you can check the SMB connectivity event logs in the followings path:

    \Winevt\Logs\Microsoft-Windows-SmbClient%4Connectivity.evtx

Step4: Check whether the Virtual Machine is part of an Corporate domain

  • If the Virtual Machine is part of a domain, check whether your organization implemented Group Policy for Windows Firewall settings on the domain members. Most times when the domain admins apply firewall policies, it will block the communication through Group Policy Object (GPO).
    To fix this issue, work with domain admins to add firewall rules to allow outgoing SMB communication.
  • If you had assigned any Network Security Groups to the Virtual machines for security compliance, that might block traffic to the Azure File Storage services. In this situation, you notice the state of the Virtual computers would be displayed as failed because Agent service has to communicate to the storage account to update the status: https://blogs.msdn.microsoft.com/mast/2016/04/27/vm-stuck-in-updating-when-nsg-rule-restricts-outbound-internet-connectivity

To fix this issue, create Network Security Group (NSG) rules to allow traffic from Virtual Machine to the Azure Storage (blobs/Files/Tables/Queues) IP address. This should restore connectivity to the storage.

4022301_image4

This screen shot is an example of an outgoing firewall rule, which allows TCP port 445 to any destination, and applies to all Firewall profiles.

Step5: Confirm that NTLMv2 authentication is enabled on the Windows clients

Azure Files supports only NTLMv2 authentication, this corresponds to the LmCompatibilityLevel registry value should be set to 3.  Azure Files will block the NTLMv1 communication because having NTLMv1 authentication enabled makes the clients less secure. If the clients enables NTLMv1 authentication, you might receive "System Error 53” or “System error 87".  To fix this issue, follow one of the instructions per your situation:

  • If this error only happens on a single client, revert the registry key LmCompatibilityLevel value to 3 in the following registry:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

  • If this error happens on multiple clients or in a domain, we recommend applying this setting through Group Policy. The relevant Group Policy setting is Send NTLMv2 response only. To prevent this error occurs, make sure that Group Policy is applied to the clients with following:
  1. The following article describes how to set clients to use NTLMv2 by using Group Policy: How to configure clients to use NTLMv2 using Group Policy

Note The recommended group policy setting for clients is Send NTLMv2 response only. It is also a security best practice.

  1. Make sure to run gpupdate /force from an elevated Command Prompt after applying this policy, and restart the machine that is having trouble connecting.

 

Did this fix your issue? 

Cause

Drives are mounted per user, if the application or service is running under different user context, you won’t see the Azure Files mounted drive.

Resolution

To resolve the issue, follow the instructions:

  1. Mount drive from the same user context that the application is running. You can use tools such as psexec to do this.
    1. Run the net use command after you run the command "psexec -i -s cmd.exe" in elevated mode to mount the drive under System context (as described in step b).
    2. Run the net use command after you run the command "psexec -i -u UserName cmd.exe" in elevated mode to mount the drive under a specific user context.
  2. Or, you can create a new user with the same permission as the network service or system account, and run cmd and net use under that user. The username should be the storage account name, and password should be the storage account key.
  3. Another option for net use is to pass in the storage account name and key in the username and password parameters of the net use command.

 

Did this fix your issue? 

Resolution

  1. First, add the Storage Account user with cmdkey, but provide a domain name of 'AZURE.' For example:
    cmdkey /add:StorageAccount.file.core.windows.net /user:AZURE\StorageAccount /pass:[Password]
  2. Then, when mapping the drive, use the /savecred option, and do not specify a username:
    net use K: \\StorageAccount.file.core.windows.net\sharename /persistent:yes /savecred

 

Did this fix your issue? 

Cause

Bitlocker-encrypted files can be copied to Azure Files. However, the File storage does not support NTFS EFS. Therefore, you are likely using EFS in this case. If you have files that are encrypted through EFS, a copy operation to the File storage can fail unless the copy command is decrypting a copied file.

Workaround

To copy a file to the File storage, you must first decrypt it. You can do this by using one of the following methods:

  • Use copy /d.
  • Set the following registry key:

Path=HKLM\Software\Policies\Microsoft\Windows\System

Value type=DWORD

Name = CopyFileAllowDecryptedRemoteDestination

Value = 1

Note Setting the registry key affects all copy operations to network shares..

 

Did this fix your issue?

Cause

This error might be logged when a Linux client is unable to communicate with the Azure Files server, or cannot resolve the address of the Azure Files server.

Resolution

To fix the issue, you have to investigate why the Linux client cannot communicate with Azure Files, or why there is a name resolution issue. Here are the steps:

  1. Verify the version of Linux and CIFS Client support SMB 2.1. The client must support at least SMB 2.1 to connect to Azure Files.
  2. Check whether Linux VM in the same datacenter as the Azure Files share. The Linux CIFS client doesn't support encryption yet. So, the VM must be in the same region as the share.
  3. Check the syntax of the mount command the user is using, to make sure it's correct.
    Here is an example:
    sudo mount -t cifs //StorageAccountName.file.core.windows.net/ShareName/DirectoryName ./azfiles -o vers=3.0,username=StorageAccountName,password=StorageAccountKey,dir_mode=0777, file_mode=0777
  4. Check DNS name resolution.

    You may receive the following error from the mount command if there are DNS name resolution issues: 

    mount error:
    could not resolve address for StorageAccountName.file.core.windows.net: Unknown error

    Any network communication has to start with name resolution. Make sure we can resolve the URL to a valid IP address is a good test to make sure name resolution is working. To verify the DNS name resolution issue, follow the instructions:

    1. Ask the user to ping the Files storage URL, and check that it resolves to an Azure IP address.

      NoteThe IP address that's resolved for *.file.core.windows.net will differ from the IP address that's resolved for *.blob.core.windows.net, *.table.core.windows.net, or *.queue.core.windows.net.

    2. Use telnet to verify the client can communicate with the server on TCP Port 445 by using the following command:

      telnet StorageAccountName.file.core.windows.net 445

      • If the port is open, you should see: Connected to file.Storage StampName.store.core.windows.net.
      • If the port isn't open, the command will freeze at: Trying IPAddress...

        Check the IP Tables on the VM to see if the VM is blocking outbound traffic on TCP Port 445 by using the following command: iptables -L

        If the entry in the IP Table displays as below:

        Chain OUTPUT (policy ACCEPT)
        target prot opt source destination
        DROP tcp -- anywhere anywhere tcp dpt:microsoft-ds

        In this situation, the TCP Port 445 is blocked, modify the TCP rules to allow outbound traffic on Port 445.

  5. Check if the user has assigned any Network Security Group to the Virtual Machines for security compliance, which might block traffic to the Azure File Storage services. In this situation, you notice the state of the Virtual computers would be displayed as failed because Agent service has to communicate to the storage account to update the status: https://blogs.msdn.microsoft.com/mast/2016/04/27/vm-stuck-in-updating-when-nsg-rule-restricts-outbound-internet-connectivity

    To fix this issue, create Network Security Group (NSG) rules to allow traffic from Virtual Machine to the Azure Storage (blobs/Files/Tables/Queues) IP address. This should restore connectivity to the storage.

Did this fix your issue?  

Resolution

For Mount Error 13, verify the username and password. The username should be the name of the storage account, and the password has to be the correct Storage Account key.

Example command:

sudo mount -t cifs //StorageAccountName.file.core.windows.net/ShareName /mnt_bkp -o vers=3.0,user=StorageAccountName,password=StorageAccountKey dir_mode=0777,file_mode=0777,serverino

 

Did this fix your issue? 

This issue sepecially been seen on Ubuntu 16.10.

Cause

Known issue in Ubuntu 16.10 kernel (v.4.8) where the client claims to support encryption. However, it does not.

Resolution

Until Ubuntu 16.10 is fixed, try use Ubuntu 16.04 or specify SMB version 2.1 instead of SMB version 3.0 with the "vers=2.1" when mounting the share.

For example:

    sudo mount -t cifs //StorageAccountName.file.core.windows.net/ShareName ./MountPoint -o vers=2.1,username=AccountName,password=StorageAccountKeyEndingIn==,dir_mode=0777,file_mode=0777

     

    Did this fix your issue?

    Symptoms

    You receive a mount error(112): Host is down error on existing file shares, you lose access to the share, or the shell stops responding when you run list commands on the mount point.

    This also affects VM Scale Sets.

    Cause

    This error occurs on the Linux client when the client has been idle for an extended period. When the client is idle for long time, the client disconnects, and the connection times out.

    The connection can be idle because of various reasons. One reason being network communication failures that prevent reestablishing a TCP connection to the server when "soft" mount option is used, which is the default.

    Another reason could be that there are also some reconnect fixes which aren't present in older kernels.

    Resolution

    Specifying a hard mount will force the client to wait until a connection is established or until explicitly interrupted, and can be used to prevent errors caused by network timeouts. However, users should be aware that this could lead to indefinite waits and should handle halting a connection as needed.

    The following change sets fix this reconnect issue now in Linux kernel:

    However this change may not be ported to all the Linux distributions yet. This is the list of known popular Linux kernels that have this and other reconnect fixes: 4.4.40+ 4.8.16+ 4.9.1+. You can move to the above recommended kernel versions in order to obtain the latest fix.

    Workaround

    If you are unable to move to latest kernel versions, to work around this issue, keep a file in the Azure File share that you write to every 30 seconds or less. This has to be a write operation, such as rewriting the created or changed date on the file. Otherwise, you might receive cached results, and your operation might not trigger the re-connection.

    1. Remount the share before you use it.
    2. Create a cron job to make some data transfer with the following value:

    */1 * * * * date>/mnt/MountPointName/time

    It will update OS time every minute to a file on the share. The information can also be useful to identify the "Last Known Good" time for share accessibility.

     

    Did this fix your issue? 

    What is the error that you receive:

    In Linux, you receive the following error message when you erform any operation on a particular file or directory:

    [permission denied] Disk quota exceeded

    Cause

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

    Resolution

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

    • If you don’t have a specific minimum I/O size requirement, we recommend that you use 1 MB as the I/O size for optimal performance.
    • If you know the final size of a file that you are extending by using writes, and your software doesn’t experience compatibility problems when an unwritten tail on the file contains zeros, then set the file size in advance instead of making every write an extending write.
    • Use the right copy method:
      • Use AzCopy for any transfer between two file shares.
      • RSync does not do parallel IO. That may be causing slowness.

    Sometimes the performance issue is related to the account level throttling or network latency. We can take the network packet trace and view the storage account metrics to narrow down the issue. See the following tutorials for more information.

    Monitor, diagnose, and troubleshoot Microsoft Azure Storage

    End-to-End Troubleshooting using Azure Storage metrics and logging, AzCopy, and Message Analyzer

    Did this fix your issue? 

    You might see slow performance when you try to transfer files to the Azure File service. Follow these guides to resolve the issue:

    • If you don’t have a specific minimum I/O size requirement, we recommend that you use 1 MB as the I/O size for optimal performance.
    • Check if the client reaches the IOPS limit 1000 or throughout limit 60MB/s
    • If you experience performance issue when you use Windows Explorer to transfer the files from/to File storage,  import the following registry keys to the clients. It will help to improve the performance.
       
      Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer]"UseDesktopIniCache"=dword:00000000"NoRemoteRecursiveEvents"=dword:00000001"NoRemoteChangeNotify"=dword:00000001"NoRecentDocsNetHood"=dword:00000001"NoDetailsThumbnailOnNetwork"=dword:00000001[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters]"InfoCacheLevel"=dword:00000010[HKEY_CLASSES_ROOT\*\shellex\PropertySheetHandlers\CryptoSignMenu]"SuppressionPolicy"=dword:00100000[HKEY_CLASSES_ROOT\*\shellex\PropertySheetHandlers\{3EA48300-8CF6-101B-84FB-666CCB9BCD32}]"SuppressionPolicy"=dword:00100000[HKEY_CLASSES_ROOT\*\shellex\PropertySheetHandlers\{883373C3-BF89-11D1-BE35-080036B11A03}]"SuppressionPolicy"=dword:00100000[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\SCAPI]"Flags"=dword:00100c02[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]"SafeDllSearchMode"=dword:00000001"SafeProcessSearchMode"=dword:00000001

       

    • If you know the final size of a file that you are extending with writes, and your software doesn’t have compatibility problems when the unwritten tail on the file contains zeros, then set the file size in advance instead of making every write an extending write.
    • Use the right copy method:
      • Use AzCopy for any transfer between two file shares.
      • Use Robocopy between file shares on an on-premises computer.

    Sometimes the performance issue is related to the account level throttling or network latency. We can take the network packet trace and view the storage account metrics to narrow down the issue. See the following tutorials for more information.

    Monitor, diagnose, and troubleshoot Microsoft Azure Storage

    End-to-End Troubleshooting using Azure Storage metrics and logging, AzCopy, and Message Analyzer

    Considerations for Windows 8.1 or Windows Server 2012 R2

    For clients that are running Windows 8.1 or Windows Server 2012 R2, make sure that the KB3114025 hotfix is installed. This hotfix improves the performance of create and close handles.

    You can run the following script to check whether the hotfix has been installed:

    reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

    If hotfix is installed, the following output is displayed:

    HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

    Note Windows Server 2012 R2 images in Azure Marketplace have hotfix KB3114025 installed by default, starting in December 2015.

    Did this fix your issue? 

     

    See Frequently Asked Questions about Azure Files.

    Did this fix your issue? 

    Cause

    Error 1816 happens when you reach the upper limit of concurrent open handles that are allowed for a file on the computer where the file share is being mounted.

    Solution

    Reduce the number of concurrent open handles by closing some handles, and then retry. On Windows, you can use Handle.exe to verify the active handles opened against the Azure File share

    For more information, see Microsoft Azure Storage performance and scalability checklist.

    Did this fix your issue? 

    Cause

    Common causes for this issue are:

    • You are using an incompatible Linux distribution client. We recommend you use the following Linux Distributions to connect to Azure file share:

      • Ubuntu Server 14.04+
      • RHEL 7+
      • CentOS 7+
      • Debian 8
      • openSUSE 13.2+
      • SUSE Linux Enterprise Server 12
    • CIFS-utils are not installed on the client.

    • The minimum SMB/CIFS version 2.1 is not installed the client.
    • SMB 3.0 Encryption is not supported on the client. SMB 3.0 Encryption is available in Ubuntu 16.4 and later version, SUSE 12.3 and later version. Other distributions require kernel 4.11 and later version.
    • You are trying to connect to a storage account over TCP port 445 that is not supported.
    • You are trying try to connect to Azure file share from an Azure VM, and the VM is not located in the same region as Storage account.

    Solution

    To resolve the issue, use the Troubleshooting tool for Azure Files mounting errors on Linux. This tool helps you to validate the client running environment, detect the incompatible client configuration which would cause access failure for Azure Files, gives prescriptive guidance on self-fix and, collects the diagnostics traces.

    Symptoms

    When you try to list files in an Azure file share by using ls command,  ls command hangs when listing directory or you receive the following error :

    ls: cannot access 'FilePath' : Input/output error

    Resolution

    Upgrade the Linux kernel to the following versions that have fix for this issue :

    • 4.4.87+
    • 4.9.48+
    • 4.12.11+
    • All versions that is greater or equal to 4.13

    Did this fix your issue? 

     

    Symptoms

    You see the following error when you try to mount an Azure file share in a Windows client:

    System Error 5 'Access Denied' or 'mount error(13): Permission denied'

    Resolution

    Scenario 1: I receive the error when trying to mount the Azure file share in on-premises or in a different Azure region

    To mount an Azure file share outside of the Azure region it is hosted in, such as on-premises or in a different Azure region, the client's OS must support SMB 3.0 with encryption.  Check the following table to see if the client that you used to mount the file share supports SMB 3.0.

    Windows Client

    SMB Version Supported

    Windows Server 2008 R2

    SMB 2.1 (access only from VM in same region as share)

    Windows 7

    SMB 2.1 (access only from VM in same region as share)

    Windows Server 2012

    SMB 3.0

    Windows Server 2012 R2

    SMB 3.0

    Windows 8 .1

    SMB 3.0

    Windows 10[1]

    SMB 3.0

    Windows Server 2016

    SMB 3.0

    Windows Server Semi-Annual Channel[2]

    SMB 3.0

    [1]: Windows 10, versions 1507, 1607, 1703, and 1709.

    [2]: Windows Server Semi-Annual Channel, version 1709.

    Scenario 2: I receive the error when trying to mount the Azure file share in Azure VM that is in the same Azure region as the Azure file share

    1. Sign in to Azure portal.
    2. Go to the storage account that hosts the Azure file share.
    3. Select Configuration, make sure that the Secure transfer required option is disabled.

      Imagen de la opción de transferencia segura requerida

    Did this fix your issue?  

    Symptoms

    You see the following error when you try to mount an Azure file share in a Linux client:

    System Error 5 'Access Denied' or 'mount error(13): Permission denied'

    Resolution

    Scenario 1: I receive the error when trying to mount the Azure file share in on-premises or in a different Azure region

    To mount an Azure file share outside of the Azure region it is hosted in, such as on-premises or in a different Azure region, the client's OS must support SMB 3.0 with encryption. SMB 3.0 encryption support was introduced in Linux kernel version 4.11.

    Scenario 2: I receive the error when trying to mount the Azure file share in an Azure VM that is in the same Azure region as the Azure file share

    1. Sign in to Azure portal.
    2. Go to the storage account that hosts the Azure file share.
    3. Select Configuration, make sure that the Secure transfer required option is disabled.

      Imagen de la opción de transferencia segura requerida

    Did this fix your issue?