NFS file shares in Azure Files
Here’s a concise summary of the article on NFS Azure file shares, preserving the original structure and key points.
Overview
Azure Files supports SMB and NFS protocols for mounting file shares. A single share cannot be accessed via both protocols, but a storage account can contain both SMB and NFS shares.
NFS Azure file shares are for Linux/UNIX clients only (not supported for Windows). NFS ACLs and some NFS features (delegations, callbacks, Kerberos auth) are not supported.
Before production use, review known issues: Troubleshoot NFS Azure file shares.
Applies to (high-level)
NFS is supported on SSD (premium) file shares in Provisioned (v1 and v2) models with LRS or ZRS redundancy. It is not supported on HDD (standard) tiers or pay-as-you-go HDD tiers.
Common scenarios
Backing storage for Linux/UNIX applications.
Workloads needing POSIX compliance, case sensitivity, or Unix-style permissions (UID/GID).
New apps requiring random I/O and hierarchical storage.
Features
Fully POSIX-compliant with hard and symbolic link support.
Implements most of NFS v4.1, but lacks delegations, callback mechanisms, Kerberos, and ACLs.
Note: Creating a hard link from an existing symbolic link is not supported.
Security and networking
Data encrypted at rest via Azure storage service encryption (SSE).
NFS shares use network-based authentication (no user-based auth). Access must be restricted via:
Private endpoints (private link) — provides a private static IP in a VNet.
Service endpoints — restrict access to specific subnets (no extra charge, but underlying storage IP can change in rare events, requiring remount).
On-premises access requires VPN or ExpressRoute plus private endpoint.
Requests are accepted only from: private endpoint, Azure VPN Gateway (P2S or Site-to-Site), ExpressRoute, or a restricted public endpoint.
See Azure Files networking considerations for details.
Support for Azure Storage features (highlights)
Supported: file management/data plane REST APIs, encryption at rest, LRS/ZRS redundancy, private endpoints, subdirectory mounts, POSIX permissions, root squash, soft delete, snapshots, AzCopy, Azure Storage Explorer.
Not supported: encryption in transit, LRS→ZRS conversion, granting access to specific public IPs, HDD media tier, identity-based authentication, Azure File Sync, file share backups, GRS/GZRS redundancy, Azure Storage Browser in portal, support for >16 groups.
Regional availability
Available in all regions that support SSD file shares. See Azure products by region.
Performance
NFS shares are SSD-only. In provisioned v2 you can configure capacity, IOPS, throughput independently; in v1 IOPS/throughput scale with capacity.
Typical small-IO latencies: low single-digit ms; metadata latencies: high single-digit ms. Metadata-heavy workloads (untar, many open/close ops) may see additional latency.
Use the Linux mount option nconnect to improve performance at scale.
Workloads
Validated for SAP application layer, database backups/replication, messaging queues, home directories, and content repositories.
Reminder: review troubleshoot guidance before production use.
Next steps
Create a classic file share
Compare Azure Files, Blob Storage, and Azure NetApp Files with NFS
Important reminders
NFS Azure file shares are not supported for Windows.
NFS shares lack user-based authentication and ACLs—ensure proper network restrictions (private/service endpoints).
Review Troubleshoot NFS Azure file shares before production deployment.
Last updated: 10/29/2025
If you’d like, I can produce a one-paragraph executive summary, a checklist for production readiness, or convert this into a GitBook-friendly stepper/tabs layout. Which would you prefer?
Was this helpful?