13.6 Azure File Shares, Tiers & Hybrid Permissions
Key Takeaways
- Azure Files delivers fully managed cloud file shares over SMB 3.1.1 and NFS 4.1; the SSD (premium) media tier gives single-digit millisecond latency while the HDD (standard) tier offers Transaction Optimized, Hot, and Cool access tiers.
- A single Azure file share is either SMB or NFS but never both, NFS 4.1 requires the SSD tier, and the media tier cannot be changed in place — moving between tiers means creating a new share and copying the data.
- HDD file shares support LRS, ZRS, GRS, and GZRS redundancy, but SSD file shares support only LRS and ZRS, and Azure Files never supports reading from the secondary region of an RA-GRS account.
- Each Azure file share supports up to 200 incremental snapshots retainable for up to 10 years, and soft delete is a storage-account-level setting that is enabled by default on new storage accounts.
- Securing SMB access requires two layers evaluated in sequence — Azure RBAC share-level roles (Storage File Data SMB Share Reader, Contributor, Elevated Contributor) then Windows NTFS ACLs — with the most restrictive result winning.
Azure File Shares, Tiers & Hybrid Permissions
Azure Files provides fully managed cloud file shares reachable over standard SMB and NFS 4.1, with no file server, NAS appliance, or disk swap to manage. Before a Windows Server administrator can cache those shares on-premises with Azure File Sync (section 13.7), they have to get two things right: the share's media tier and redundancy, and the two-layer permission model that governs SMB access.
1. Azure Files Architecture: Standard vs. Premium Tiers
Azure Files delivers serverless, fully managed cloud file shares accessible from Windows, Linux, and macOS clients via standard SMB 3.1.1 and NFS 4.1 protocols.
+-----------------------------------------------------------------------------------+
| AZURE FILES STORAGE TIERS |
| |
| +------------------------------------+ +-------------------------------------+ |
| | Standard File Shares | | Premium File Shares | |
| |------------------------------------| |-------------------------------------| |
| | - Backed by Hard Disk Drives (HDD) | | - Backed by Solid-State Drives (SSD)| |
| | - General Purpose v2 (GPv2) account| | - FileStorage Storage Account | |
| | - Pay for data stored + I/O ops | | - Provisioned IOPS & Throughput | |
| | - Tiers: Trans-Optimized, Hot, Cool| | - Single-digit ms latency | |
| | - Protocols: SMB 3.x only | | - Protocols: SMB 3.x & NFS 4.1 | |
| +------------------------------------+ +-------------------------------------+ |
+-----------------------------------------------------------------------------------+
Storage Tier Breakdown
| Tier / Feature | Underlying Media | Billing Model | Recommended Workloads |
|---|---|---|---|
| Premium | Solid-State Drives (SSD) | Provisioned capacity (includes baseline IOPS & throughput) | I/O-intensive workloads, databases, Hyper-V VHDX storage, enterprise application shares. |
| Transaction Optimized | Hard Disk Drives (HDD) | Storage capacity + low transaction fee | High-transaction workloads that do not require SSD latency (e.g., active team working folders). |
| Hot | Hard Disk Drives (HDD) | Storage capacity + moderate transaction fee | General enterprise file shares, core departmental data repositories. |
| Cool | Hard Disk Drives (HDD) | Lower storage cost + higher transaction fee | Historical archives, backup retention targets, infrequently accessed data. |
Current naming: Microsoft now leads with two media tiers — SSD (formerly "premium") and HDD (formerly "standard") — and recommends the provisioned v2 billing model for new deployments. The Transaction Optimized, Hot, and Cool access tiers above apply to HDD shares on the older pay-as-you-go billing model. Expect either vocabulary on the exam.
2. Creating & Managing Azure File Shares
An SMB share is created inside a storage account (a "classic" file share, from the Microsoft.Storage resource provider). A newer top-level Microsoft.FileShares resource exists, but it currently supports NFS only and does not support Azure File Sync — so every AZ-800 hybrid scenario uses classic file shares in a storage account.
# Create a storage account and an SMB file share, then mount it from Windows
New-AzStorageAccount -ResourceGroupName 'RG-Storage' -Name 'corpfiles01' `
-Location 'eastus' -SkuName 'Standard_ZRS' -Kind 'StorageV2'
New-AzRmStorageShare -ResourceGroupName 'RG-Storage' -StorageAccountName 'corpfiles01' `
-Name 'corp-cloud-share' -QuotaGiB 5120
# Mount over SMB (identity-based auth; no key in the command)
New-SmbMapping -LocalPath 'Z:' -RemotePath '\\corpfiles01.file.core.windows.net\corp-cloud-share'
Protocol, Redundancy & Tier Decisions Are Made at Creation
| Setting | Rule you must know |
|---|---|
| Protocol | A single share is either SMB or NFS, never both. You can, however, host an SMB share and an NFS share in the same storage account. |
| NFS availability | NFS 4.1 requires the SSD media tier. HDD shares are SMB-only. |
| Redundancy | HDD shares support LRS, ZRS, GRS, and GZRS. SSD shares support only LRS and ZRS. |
| Read-access geo options | You can provision into an RA-GRS/RA-GZRS account, but Azure Files does not support reading from the secondary region. |
| Changing media tier | Not possible in place. To move an HDD share to SSD you must create a new share and copy the data. |
Protecting the Share
- Soft delete is a storage-account-level setting that moves a deleted share into a recoverable state for a configurable retention period rather than erasing it. It is enabled by default on new storage accounts.
- Share snapshots are read-only, incremental, point-in-time copies. Each share supports up to 200 snapshots, retainable for up to 10 years.
- Azure Backup schedules those snapshots with grandfather-father-son retention, automatically enables soft delete, and places a delete lock on the storage account.
- Encryption at rest is always on via service-side encryption. Encryption in transit is on by default, which means Azure Files accepts only SMB 3.x with encryption or HTTPS; disabling it is a legacy-compatibility action, not a tuning knob.
The Port 445 Problem
Many ISPs and corporate firewalls block outbound TCP 445, which SMB requires. This single fact drives most Azure Files network design:
- SMB clients inside Azure need no special configuration.
- SMB clients on-premises need a VPN or ExpressRoute connection with the storage account exposed through a private endpoint.
- Azure Files does not itself support SMB over QUIC; the supported workaround is to front the share with an Azure File Sync cache on a Windows Server VM that does.
3. Hybrid Identity & Multi-Tier Permissions for Azure Files
Securing Azure File Shares over SMB requires a two-tier permission model: evaluating Azure Role-Based Access Control (Azure RBAC) at the share level, followed by Windows NTFS ACLs at the directory/file level.
+-----------------------------------------------------------------------------------+
| TWO-TIER PERMISSION PIPELINE |
| |
| [Incoming SMB Request] ---> \\mystorageacct.file.core.windows.net\share |
| | |
| v |
| [Layer 1: Azure RBAC Role] ---> Evaluates Share-Level Permissions |
| - Storage File Data SMB Share Reader |
| - Storage File Data SMB Share Contributor |
| - Storage File Data SMB Share Elevated Cont.|
| | |
| v |
| [Layer 2: Windows NTFS DACL] ---> Evaluates Active Directory File/Folder ACLs |
| (Read, Write, Modify, Full Control) |
| | |
| v |
| [Effective Permission] ---> Most Restrictive Wins |
+-----------------------------------------------------------------------------------+
Share-Level Azure RBAC Roles
- Storage File Data SMB Share Reader: Grants read access to files and directories over SMB.
- Storage File Data SMB Share Contributor: Grants read, write, and delete access to files and directories over SMB.
- Storage File Data SMB Share Elevated Contributor: Grants read, write, delete, and the right to modify Windows NTFS permissions (ACLs) over SMB. Required for administrators configuring ACL baselines.
Directory and File-Level Identity Sources
To evaluate NTFS permissions, Azure Files must authenticate identity tokens against an identity provider:
- On-Premises Active Directory Domain Services (AD DS): The storage account is joined to on-premises AD DS, creating a computer account or service logon account. Domain-joined clients authenticate using standard Kerberos tickets.
- Microsoft Entra Domain Services (formerly Azure AD DS): Clients authenticate against managed Entra Domain Services domain controllers.
- Microsoft Entra Kerberos (Hybrid Identities): Allows hybrid user accounts managed in Microsoft Entra ID to access Azure File Shares over SMB using Kerberos tickets issued directly by Entra ID without requiring line-of-sight to on-premises domain controllers.
Exam trap: the two layers are evaluated in sequence and the most restrictive result wins. Granting Storage File Data SMB Share Elevated Contributor does not override a Deny NTFS ACL — and conversely, perfect NTFS permissions are useless if the user holds no share-level RBAC role at all. Note also that mounting with the storage account key bypasses NTFS ACLs entirely and authenticates with NTLMv2, which is why identity-based authentication is the recommended path in every production scenario.
An administrator is configuring security for an Azure File Share named 'Finance'. The administrator must grant a security group named 'Finance-Managers' the ability to mount the share over SMB and modify Windows NTFS permissions on subfolders. Which Azure RBAC role should be assigned at the storage account or share level?