Configuring Azure Files for Shared Network Storage

Overview and What You Will Learn

In this lab, you will create an Azure Files share, mount it on a Linux VM using the standard SMB protocol, and confirm that a file written from one VM is immediately visible to a second VM mounting the same share - the exact capability Blob Storage does not natively provide.

Why This Matters in Production

An engineering team at Swiggy needs several application servers to all read the same set of configuration files, and keeping those files in sync across separate local disks on each VM is error-prone - one server updates its copy, another doesn't, and the two servers start behaving inconsistently. Azure Files solves this by giving every VM a single shared location to read and write, exactly like a traditional network drive.

Core Principles

Azure Files provides fully managed file shares accessible over the standard SMB or NFS protocol - the same protocols a traditional on-premises network drive already uses, meaning existing applications expecting a mapped drive often need no code changes at all.

This is the key distinction from Blob Storage or a VM's own Managed Disk - a File Share is designed to be mounted by multiple compute resources simultaneously, while a Managed Disk can only be attached to one VM at a time.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group and Storage Account:

2. Create a file share inside that storage account:

3. Retrieve the storage account key needed to mount the share:

4. On a Linux VM, install the CIFS utilities needed to mount an SMB share, then mount it:

Note

serverino tells the mount to use inode numbers from the server rather than generating them locally - this specific option is required for Azure Files SMB mounts to behave correctly with certain applications that rely on stable inode numbers.

5. From this first VM, write a test file into the mounted share:

6. On a second VM, repeat the mount steps (steps 4) pointing at the exact same share, then confirm the file written from the first VM is immediately visible:

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Trying to achieve multi-VM shared access using Blob Storage, when the actual requirement is a real mountable file share. Blob Storage is not designed to be mounted as a network drive - Azure Files exists specifically for this shared-mount use case.

Tip

For production workloads, avoid mounting with the raw storage account key directly in a mount command visible in shell history or scripts. Use Azure Key Vault to store the key and retrieve it at mount time, or use Azure AD-based authentication for SMB where supported.

• Azure Files is the right choice specifically for multi-writer, multi-reader scenarios. If only one VM ever needs to read or write the data, a Managed Disk is usually simpler and often cheaper than a File Share.
• Quota is set at share creation and can be increased later, but plan realistically upfront. Under-provisioning the quota means running out of space unexpectedly; the quota itself does not affect cost until actual usage approaches it.

Quick Reference & Troubleshooting Commands