This chapter covers Azure Files, a managed file share service in the cloud that supports both SMB and NFS protocols. As a core Azure Storage offering, Azure Files is a high-probability topic on the AZ-204 exam, appearing in roughly 10-15% of questions related to the 'Implement Azure Storage' domain. You will learn how to create and configure Azure file shares, understand the differences between SMB and NFS protocols, manage access control, and integrate with on-premises environments using Azure File Sync. Mastery of this topic is essential for any Azure developer building applications that require shared file storage accessible from multiple VMs or on-premises clients.
Jump to a section
Imagine a company's office building with a centralized file server room. The server room has many hard drives, but employees access files through shared network drives (like S: drive for sales, M: drive for marketing). The server room has two main doors: one for Windows-based employees (SMB protocol) and one for Linux-based employees (NFS protocol). Both doors lead to the same file cabinets, but each has its own access rules. The SMB door requires employees to swipe a badge that includes their Windows domain credentials, and the door logs every access with user identity. The NFS door uses a simpler keycard that only shows a numeric ID, and access is granted based on IP address ranges. The file server administrator can set quotas on how much each department can store, and can create snapshots of the entire file system at scheduled times. If an employee accidentally deletes a file, they can go to the 'Previous Versions' tab (like Shadow Copies) to restore it, provided the administrator has enabled that feature. The administrator can also set up replication to a secondary office across town (Azure File Sync) so that if the main server room burns down, the secondary office still has all the files. This whole setup is managed through a web portal (Azure portal) where the administrator can monitor usage, set permissions, and configure backups.
What is Azure Files?
Azure Files is a fully managed file share service in the cloud that uses the Server Message Block (SMB) protocol (versions 2.1, 3.0, and 3.1.1) and the Network File System (NFS) protocol (version 4.1). It provides shared storage that can be mounted concurrently by multiple virtual machines or on-premises clients, similar to a traditional file server but without the need to manage the underlying hardware or operating system. Azure Files is part of Azure Storage and uses the same storage account as blobs, queues, and tables. However, file shares are a separate resource type within a storage account.
Why Azure Files Exists
Traditional file servers require ongoing maintenance, patching, capacity planning, and high availability configurations. Azure Files offloads all of this to Microsoft. It provides a fully managed service with built-in redundancy (LRS, ZRS, GRS, or GZRS), encryption at rest (Azure Storage Service Encryption) and in transit (SMB 3.0+ encryption), and integration with Azure Active Directory for identity-based access. For developers, Azure Files is a simple way to add shared file storage to applications without managing infrastructure.
How Azure Files Works Internally
When you create an Azure file share, it is provisioned within a storage account. The storage account can be either a FileStorage account (for premium file shares) or a general-purpose v2 (GPv2) account (for standard file shares). The file share has a maximum size depending on the tier: standard shares can be up to 100 TiB, premium shares up to 100 TiB as well. The share is accessible via a UNC path like \\storageaccount.file.core.windows.net\sharename.
For SMB, the client initiates a connection to the Azure Files endpoint on port 445 (TCP). If the client is on-premises or in a different network, port 445 must be open. For clients that cannot use port 445 (e.g., due to corporate firewall restrictions), Azure Files supports connecting over HTTPS via the File REST API (port 443) or using Azure File Sync with a local cache. For Linux clients using SMB, the cifs-utils package is required.
For NFS, the client connects to the Azure Files endpoint on port 2049 (TCP). NFS shares must be created in a FileStorage account with the --protocol NFS option. NFS shares do not support Azure AD authentication; instead, they rely on network-level security using virtual networks and IP-based access rules.
Key Components, Values, Defaults, and Timers
Storage Account Types:
FileStorage: Only for premium file shares (SSD-backed). Provides higher IOPS and throughput. Supports both SMB and NFS.
General-purpose v2 (GPv2): For standard file shares (HDD-backed). Supports SMB only (NFS not supported).
Tiers:
Standard: Transaction-optimized, hot, cool tiers. Transaction-optimized is default for standard shares.
Premium: Provisioned billing model, consistent performance.
Share Quota: Maximum size of the share. For standard shares, the default quota is 5 TiB, but can be increased up to 100 TiB. For premium shares, the quota is set at creation and determines the provisioned IOPS and throughput.
Protocols: SMB (default) or NFS. NFS must be specified at share creation; cannot be changed later.
Authentication for SMB:
Azure AD (Kerberos) for domain-joined Windows VMs.
Storage account key (username/password) for non-domain-joined clients.
Azure AD DS or on-premises AD DS integration.
Encryption:
At rest: Azure Storage Service Encryption (SSE) using AES-256.
In transit: SMB 3.0+ encryption (mandatory for Azure File Shares when accessed from outside Azure region). NFS does not encrypt in transit; use VPN or ExpressRoute.
Snapshots: Point-in-time read-only copies. Up to 200 snapshots per share. Can be created manually or via Azure Backup.
Soft Delete: Enabled by default for standard file shares. Retains deleted shares for a configurable retention period (1-365 days).
Azure File Sync: A service that syncs Azure file shares with on-premises Windows Servers. Supports cloud tiering to free up local space.
Configuration and Verification Commands
To create an Azure file share using Azure CLI:
# Create a storage account (GPv2 for standard)
az storage account create -n mystorageaccount -g myResourceGroup -l eastus --sku Standard_LRS
# Create a file share
az storage share create --account-name mystorageaccount --name myshare --quota 50For premium NFS share:
az storage account create -n mystorageaccount -g myResourceGroup -l eastus --sku Premium_LRS --kind FileStorage
az storage share create --account-name mystorageaccount --name myshare --quota 100 --enabled-protocol NFSTo mount an SMB share on Windows:
net use Z: \\mystorageaccount.file.core.windows.net\myshareTo mount an NFS share on Linux:
sudo mount -t nfs mystorageaccount.file.core.windows.net:/mystorageaccount/myshare /mnt/myshare -o nfsvers=4.1Interactions with Related Technologies
Azure Virtual Machines: File shares can be mounted by multiple VMs simultaneously, enabling shared application configuration or user home directories.
Azure App Service: Can access file shares via the REST API or by mounting as a path in the App Service plan (Windows only).
Azure Functions: Similar to App Service, can access file shares.
Azure Kubernetes Service (AKS): Can mount Azure Files as persistent volumes using the CSI driver.
Azure Backup: Can back up Azure file shares, including snapshots.
Azure File Sync: Syncs with on-premises file servers, enabling hybrid scenarios.
Create Storage Account
First, decide on the type of file share you need. For standard shares (SMB only), create a general-purpose v2 (GPv2) storage account. For premium shares (SMB or NFS), create a FileStorage account. Choose the appropriate redundancy (LRS, ZRS, GRS, etc.). The storage account name must be globally unique within Azure, 3-24 characters, lowercase letters and numbers only. This step is done via Azure Portal, CLI, or PowerShell.
Create File Share
Within the storage account, create a file share. Specify the name (3-63 characters, lowercase letters, numbers, hyphens), quota (max size in GiB), and protocol (SMB or NFS). For standard shares, the default protocol is SMB. For premium shares, you can choose SMB or NFS, but NFS must be selected at creation time and cannot be changed later. The share is immediately available for mounting once created.
Configure Networking
By default, Azure file shares are accessible from the internet if the client has the storage account key and the correct port is open. For SMB, port 445 must be open. For NFS, port 2049. To restrict access, you can configure firewall rules and virtual network service endpoints. For NFS shares, you must use private endpoints or service endpoints; public access is not supported. This step is crucial for security and compliance.
Set Up Authentication (SMB)
For SMB shares, you can use Azure AD (Kerberos) for identity-based access if the client is domain-joined. Alternatively, use the storage account key (which is like a shared secret). For on-premises clients, you can integrate with on-premises AD DS via Azure AD DS or AD DS authentication. This step involves configuring role-based access control (RBAC) for the share, assigning the appropriate roles (e.g., Storage File Data SMB Share Contributor) to users or groups.
Mount the Share
On the client machine, mount the file share. For Windows SMB, use the `net use` command or Map Network Drive in File Explorer. For Linux SMB, use `mount.cifs` with the appropriate options. For Linux NFS, use `mount -t nfs`. Ensure the client has the required packages installed (e.g., cifs-utils for Linux SMB). The mount point will be accessible as a local directory on the client.
Enterprise Scenario 1: Lift-and-Shift of On-Premises File Server
A large enterprise is migrating its on-premises file server to Azure to reduce hardware costs and maintenance. They have hundreds of users accessing files via SMB from Windows workstations. The solution uses Azure Files with Azure AD DS authentication to preserve existing user permissions. They configure Azure File Sync to cache frequently accessed files on a local Windows Server, ensuring low latency for remote offices. The file share is backed up daily using Azure Backup. Performance considerations: They choose premium file shares for high IOPS workloads (e.g., database files) and standard shares for general office documents. They monitor share metrics using Azure Monitor and set alerts for high latency or throttling.
Enterprise Scenario 2: High-Performance Computing with NFS
A research organization runs Linux-based HPC clusters that require shared storage for simulation data. They deploy Azure Files NFS shares in a FileStorage account with premium performance. The shares are mounted on all compute nodes using NFSv4.1. They use private endpoints to ensure traffic stays within the Azure backbone, avoiding public internet. They provision the share with enough quota to meet IOPS requirements. Common issues: If the share is under-provisioned, clients experience throttling. They use Azure NetApp Files for even higher performance, but Azure Files is sufficient for moderate workloads.
Enterprise Scenario 3: Multi-Site Application Configuration
A SaaS company runs a web application across multiple Azure regions. They use Azure Files to store shared configuration files that are read by all instances. Each region has its own file share, and they use Azure File Sync to keep them in sync. The application uses the File REST API to read configuration, avoiding the need to mount the share. They use soft delete to protect against accidental deletion. Misconfiguration: If they set the share quota too low, writes fail; they monitor usage and set alerts at 80% capacity.
What AZ-204 Tests on Azure Files
Objective 2.2: Implement Azure Storage. Specifically, candidates must be able to create and configure file shares, manage snapshots, and implement Azure File Sync.
Common question types: Choose the correct protocol for a scenario (SMB vs NFS), identify authentication methods, configure soft delete, and select redundancy options.
Most Common Wrong Answers
Choosing NFS when SMB is required: Candidates often pick NFS because it's newer, but the exam expects you to know that NFS does not support Azure AD authentication and is Linux-only. If the scenario mentions Windows clients or identity-based access, SMB is correct.
Using GPv2 for NFS: GPv2 accounts do not support NFS. Only FileStorage accounts support NFS. Candidates may incorrectly assume any storage account can create NFS shares.
Enabling public access for NFS: NFS shares do not support public internet access. They require private endpoints or service endpoints. Candidates may forget this and choose a public endpoint.
Assuming Azure Files supports both SMB and NFS simultaneously: A single file share can only use one protocol. You cannot change the protocol after creation.
Specific Numbers and Terms
Port 445 for SMB, port 2049 for NFS.
Maximum share size: 100 TiB (both standard and premium).
Maximum snapshots per share: 200.
Soft delete retention: 1 to 365 days.
Azure File Sync: cloud tiering, sync groups, server endpoints.
Authentication: Storage account key (shared key), Azure AD (Kerberos), AD DS, Azure AD DS.
Edge Cases and Exceptions
If a client cannot use port 445, you can use Azure File Sync with a local cache, or use the REST API over HTTPS.
NFS shares cannot be accessed from the Azure portal; they must be mounted from a client.
SMB shares from on-premises require the client to be domain-joined for identity-based access; otherwise, use storage account key.
For Azure VM mounting, ensure the VM is in the same region or use VNet peering.
How to Eliminate Wrong Answers
If the scenario mentions 'Windows', 'Active Directory', 'identity', 'user permissions' -> SMB.
If the scenario mentions 'Linux', 'no authentication', 'high performance', 'private network' -> NFS.
If the question asks about 'backup' or 'snapshot' -> snapshots are available for both, but Azure Backup provides managed backup.
If the question asks about 'hybrid' -> Azure File Sync.
Azure Files supports SMB (2.1, 3.0, 3.1.1) and NFS (4.1) protocols.
SMB shares support Azure AD authentication; NFS does not.
NFS shares require a FileStorage (premium) account and private network access.
Maximum share size is 100 TiB for both standard and premium tiers.
Soft delete is enabled by default for standard file shares with 1-365 day retention.
Azure File Sync enables hybrid cloud scenarios with on-premises Windows Servers.
Snapshots are point-in-time read-only copies; up to 200 per share.
Port 445 must be open for SMB; port 2049 for NFS.
These come up on the exam all the time. Here's how to tell them apart.
SMB Shares
Uses TCP port 445.
Supports Azure AD, AD DS, and storage account key authentication.
Accessible from Windows, Linux, and macOS clients.
Encryption in transit required for cross-region access.
Can be accessed over the internet with proper firewall rules.
NFS Shares
Uses TCP port 2049.
No identity-based authentication; relies on network security.
Primarily used by Linux clients.
No encryption in transit; use VPN or ExpressRoute.
Requires private endpoints or service endpoints; no public access.
Mistake
Azure Files NFS shares can be accessed over the internet using public endpoints.
Correct
NFS shares do not support public internet access. They must be accessed via private endpoints or service endpoints within a virtual network.
Mistake
You can change the protocol of an existing Azure file share from SMB to NFS or vice versa.
Correct
The protocol is set at creation time and cannot be changed. You would need to create a new share with the desired protocol and migrate data.
Mistake
Azure Files supports both SMB and NFS protocols on the same share simultaneously.
Correct
A single file share supports only one protocol. You cannot mount the same share via both SMB and NFS.
Mistake
Standard file shares can be created in a FileStorage account.
Correct
FileStorage accounts only support premium file shares. Standard file shares require a general-purpose v2 (GPv2) storage account.
Mistake
Azure Files encryption in transit is optional for SMB 3.0+.
Correct
For Azure Files, SMB 3.0+ encryption is mandatory when accessing from outside the Azure region. Within the same region, it is still strongly recommended.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can mount an Azure file share from on-premises as long as port 445 (for SMB) or port 2049 (for NFS) is open outbound. For SMB, you need the storage account key or Azure AD credentials. If port 445 is blocked, consider using Azure File Sync or the File REST API over HTTPS.
Azure Files is a fully managed file share service that supports SMB and NFS, suitable for general-purpose file sharing. Azure NetApp Files is a high-performance file storage service built on NetApp technology, supporting SMB and NFS with advanced features like snapshots, cloning, and low-latency performance. NetApp Files is more expensive and designed for enterprise workloads requiring high IOPS and low latency.
You can back up Azure file shares using Azure Backup, which automates snapshot creation and retention. Alternatively, you can manually create snapshots using PowerShell, CLI, or the Azure portal. Azure Backup provides a managed backup solution with policy-based scheduling and long-term retention.
Yes, Azure Files can be used as persistent storage for AKS pods. You can dynamically provision persistent volumes using the Azure Files CSI driver. Both SMB and NFS shares are supported, but NFS requires the premium tier and appropriate networking.
On premium file shares, the quota determines the provisioned IOPS and throughput. If you exceed the quota, writes may fail with an 'insufficient quota' error. You must increase the quota to accommodate more data. Standard shares do not have provisioned IOPS; they are pay-per-use with limits based on the share size.
Azure Files uses Azure Storage Service Encryption (SSE) which is FIPS 140-2 compliant for encryption at rest. For encryption in transit, SMB 3.0+ encryption uses AES-256, which is also FIPS 140-2 compliant.
Yes, you can mount an Azure file share to an Azure App Service (Windows) as a path. This is useful for sharing files across multiple instances of an app. On Linux App Service, you can use the REST API or mount via custom containers.
You've just covered Azure Files SMB and NFS Shares — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?