Blog Post

Azure Database Support Blog
2 MIN READ

Lesson Learned #430: Addressing Error 3201 with Azure Blob Storage: "Operating system error 86"

Jose_Manuel_Jurado's avatar
Jose_Manuel_Jurado
Icon for Microsoft rankMicrosoft
Sep 20, 2023

Today, I worked on a service request that our customer got the following error message: Cannot open backup device 'https://XXX.blob.core.windows.net/NNN/YYY.bak'. Operating system error 86(The specified network password is not correct.). RESTORE HEADERONLY is terminating abnormally. (Microsoft SQL Server, Error: 3201). Following I would like to share with you some details why this issue and the activities done to resolve it. 

 

The Core Issue: Error 3201

 

Error 3201 essentially signifies that SQL Server is facing challenges accessing the backup device or file specified during a backup or restore operation.

 

Diving Deeper: "Operating system error 86"

 

This error explicitly states: "The specified network password is not correct." When we're dealing with Azure Blob Storage as the backup destination, this "network password" can often be a reference to the Shared Access Signature (SAS) token used for authentication.

 

Common Triggers and Solutions

 

  1. Incorrect SAS Token: Azure Blob Storage uses SAS tokens to grant limited access to its objects. If this token is either wrong or expired, an authentication error like "Operating system error 86" will manifest. Ensure that the SAS token is correctly generated and still valid. Also, you could receive message with "Access Denied"

  2. Network Configuration Issues (Firewall): Network barriers like firewalls can block Azure SQL Managed Instance from reaching Azure Blob Storage. Ensure that there are appropriate rules allowing traffic between your Azure SQL Managed Instance and Azure Blob Storage.

  3. Azure SQL Managed Instance and Azure Blob Storage Communication: When using Azure SQL Managed Instance, ensure that you have set up the necessary networking components, like Virtual Network (VNet) peering or VNet service endpoints, to allow smooth communication with Azure Blob Storage.

  4. File Path or Backup Device Misconfiguration: This can be a straightforward issue where the specified file path is incorrect or the backup device has issues. Double-check the path and the device's status.

 

Conclusion

Error 3201, combined with "Operating system error 86," points to challenges in Azure SQL Managed Instance accessing backup devices in Azure Blob Storage, often due to incorrect SAS tokens or network barriers. In this case, we found the firewall/network/UDR configuration prevents the access from Azure SQL Managed Instance to Azure Blob Storage causing this problem. 

Updated Sep 20, 2023
Version 2.0
azure sql managed instance
Restoring backup
System Error 86

1 Comment

  • readparse37854's avatar
    readparse37854
    Copper Contributor
    Dec 14, 2024

    This is an interesting post, and I followed the rabbit just a little farther.  I had the same problem in multiple SQL Server contexts:

    • Azure SQL Server Managed Instance
    • Azure SQL Server (I think that's what it's called)
    • SQL Server for Linux running in a Docker container
    • I was going to try legit on-prem SQL Server in the data center, and then remembered that actual DBAs own that and I didn't want to involve them in this experiment
    • The last place I tested was an Azure Container instance, running the same docker container

    I got this same error on all of them (except on-prem SQL Server on Windows, which I admittedly didn't try).

    The way I eventually resolved it was to download the file myself, outside of SQL Server, proving that it wasn't a network limitation from the instance at all, but rather something in the SQL Server code that had a problem with the URL -- a URL that was known to be good, by the way.  I tested this not just on Azure blob storage, but S3 as well, and had the same problem both times.

    Once I had it downloaded locally, I of course did not need the URL method anymore.  It's cool, but I have not seen it work, and there is usually a way to get a file downloaded.  In my case, I'm going to change my container to run a script on startup, which will startup SQL server, download the file, and create the database.  Then it will call the Azure CLI to retrieve its own hostname and put that hostname elsewhere in blob storage, so another process can get the hostname to utilize the server.