Azure file storage change?

Question

When I store files from my application into Azure Government Azure File Storage containers, I use the Storage Account to connect then use a "filepath" of something like containername/accountname/image.jpg. I build that path then upload the image to Azure. It's location in Azure looks the same, containername/accountname/image.jpg. When I used to download the image to use in a report , I'd create a local temporary file path to put the image in and it would follow the similiar layout but for local so something like: "C:\TempFiles\containername\accountname\image.jpg". Now when I'm downloading the file, the path that is coming down from Azure is formatted with the containername & accountname combined so "C:\TempFiles\containernameaccountname\image.jpg" Did something change in Azure that is not recognizing the 2nd location name (in this case accountname) as it's own location when downloading the file? Could it be some setting my Azure sysadmin changed that's causing this? Am I missing something? Could this be a bug? Hope this makes sense. Any help is appreciated.

Answer 1

Azure Files provides SMB and NFS file shares, so the normal way to interact with an Azure file share is to mount it using one of those protocols on your local PC. Since you referred to paths on Windows, I'm going to assume that you're trying to mount with SMB on Windows. Since you used the term "container", and not file share, I want to make sure we're on the same page. For historical reasons, Azure Files is managed out of the same top-level Azure resource as other Azure storage services, including Azure Blob storage. You are already familiar with this object: the storage account. The storage account contains multiple different types of objects for the various services that are managed through it: file shares for Azure Files, containers for Azure Blob storage, queues for Azure Queue storage, and tables for Azure Table storage. You might be using the term "container" as a generic term meaning file share, but in the context of the storage account, "container" has a technical meaning associated with Azure Blob storage. Azure Files and Azure Blob storage are distinct services, used for different things.

You may already be familiar with SMB and NFS, but in case you're not (and in case other people find this question in the future), SMB and NFS are file sharing protocols that enable your computer (Windows, macOS, Linux, etc.), to surface remote file storage on your computer as if it were a locally attached disk. When a file share is mounted on your computer, you don't need to do anything special to access the data: just navigate to the path where the file share is mounted and open/modify a file. This works through an operating system component called a "kernel module" (often a "file system filter" in Windows terminology). These components ships natively in all three major OSes, and translate normal file open, read/write, etc. file system API calls into the file sharing protocol calls used by SMB or NFS. (All three OSes have native SMB kernel modules, whereas NFS is only available on Linux and macOS.)

The Azure Files section of the Azure storage account contains a "Connect" blade that provides pre-formatted mount commands for common operating systems. You can also see how to mount Azure file shares in our documentation, such as on the Windows documentation: https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows#using-an-azure-file-share-with-windows. These instructions have you mount the Azure file share to a particular drive letter, such as the Z:\ drive, but 1) you can choose whichever drive letter you prefer, and 2) you actually don't need to mount the file share to a particular drive letter at all to use it - you can directly access using the UNC path. A UNC path looks like \<servername>\<filesharename>\<path>\<to>\<file> where each component is specific to your environment. For public Azure, the <servername> component will be: <storageaccount>.file.core.windows.net. For US Gov Azure, it would be: <storageaccount>.file.core.usgovcloudapi.net.

If you mounted to a particular drive letter, such as Z:\, your files would be available at: Z:\<path>\<to>\<file>, not some path off of the C:\ drive. It is possible to mount file shares to folders on the C:\ drive, but this seems unlikely based on your commentary.

Finally, I want to address Sumanth's comment. In addition to the fact that Azure Files expose a file share through traditional file system protocols such as SMB or NFS, we also provide a REST API we call the FileREST API. This API is only available on SMB file shares today. We provide this primarily for first-party and third-party value-added services such as Azure Backup or Azure File Sync to integrate with. Although it is provided primarily for value-added service integrations, you also can use it directly to manipulate the contents of your file share. We provide multiple tools, as Sumanth mentioned - the Browse experience in the Azure Portal, Azure PowerShell, CLI, Storage Explorer, etc. You might find these tools useful in administrator contexts, but this is not the way that Azure Files is generally meant to be accessed - we provide SMB and NFS file shares so that you can use Azure Files to replace on-premises SMB or NFS file shares, or even locally attached storage for applications. If you do use one of the FileREST API tools, the experience will be uploading and downloading the file to your PC, rather than opening the file in place as you might expect from a normal file share. This might explain the source of your question.

Hope this helps disambiguate what Azure Files is and also I hoped this fully answered your question.

Thanks,

Will Gries
Program Manager, Azure Files