NFS file shares in Azure Files (preview)
Azure Files offers two industry-standard protocols for mounting Azure file share: the Server Message Block (SMB) protocol and the Network File System (NFS) protocol (preview). Azure Files enables you to pick the file system protocol that is the best fit for your workload. Azure file shares don't support accessing an individual Azure file share with both the SMB and NFS protocols, although you can create SMB and NFS file shares within the same storage account. For all file shares, Azure Files offers enterprise-grade file shares that can scale up to meet your storage needs and can be accessed concurrently by thousands of clients.
This article covers NFS Azure file shares. For information about SMB Azure file shares, see SMB file shares in Azure Files.
We do not recommend using NFS for production during preview. See the Troubleshoot Azure NFS file shares article for a list of known issues.
NFS file shares are often used in the following scenarios:
- Backing storage for Linux/UNIX-based applications, such as line-of-business applications written using Linux or POSIX file system APIs (even if they don't require POSIX-compliance).
- Workloads that require POSIX-compliant file shares, case sensitivity, or Unix style permissions(UID/GID).
- New application and service development, particularly if that application or service has a requirement for random IO and hierarchical storage.
- Fully POSIX-compliant file system.
- Hard link support.
- Symbolic link support.
- NFS file shares currently only support most features from the 4.1 protocol specification. Some features such as delegations and callback of all kinds, Kerberos authentication, and encryption-in-transit are not supported.
Security and networking
All data stored in Azure Files is encrypted at rest using Azure storage service encryption (SSE). Storage service encryption works similarly to BitLocker on Windows: data is encrypted beneath the file system level. Because data is encrypted beneath the Azure file share's file system, as it's encoded to disk, you don't have to have access to the underlying key on the client to read or write to the Azure file share. Encryption at rest applies to both the SMB and NFS protocols.
For encryption in transit, Azure provides a layer of encryption for all data in transit between Azure datacenters using MACSec. Through this, encryption exists when data is transferred between Azure datacenters. Unlike Azure Files using the SMB protocol, file shares using the NFS protocol do not offer user-based authentication. Authentication for NFS shares is based on the configured network security rules. Due to this, to ensure only secure connections are established to your NFS share, you must use either service endpoints or private endpoints. If you want to access shares from on-premises then, in addition to a private endpoint, you must setup a VPN or ExpressRoute. Requests that do not originate from the following sources will be rejected:
- A private endpoint
- Azure VPN Gateway
- A restricted public endpoint
For more details on the available networking options, see Azure Files networking considerations.
Support for Azure Storage features
The following table shows the current level of support for Azure Storage features in accounts that have the NFS 4.1 feature enabled.
The status of items that appear in this tables may change over time as support continues to expand.
|Storage feature||Supported for NFS shares|
|File management plane REST API||✔️|
|File data plane REST API||⛔|
|Encryption at rest||✔️|
|Encryption in transit||⛔|
|LRS or ZRS redundancy types||✔️|
|Grant network access to specific Azure virtual networks||✔️|
|Grant network access to specific IP addresses||⛔|
|Standard tiers (Hot, Cool, and Transaction optimized)||⛔|
|Azure file share soft delete||⛔|
|Azure File Sync||⛔|
|Azure file share backups||⛔|
|Azure file share snapshots||⛔|
|GRS or GZRS redundancy types||⛔|
|Azure Storage Explorer||⛔|
|Create NFS shares on existing storage accounts*||⛔|
|Support for more than 16 groups||⛔|
* If a storage account was created prior to registering for NFS, you cannot use it for NFS. Only storage accounts created after registering for NFS can be used.
Azure NFS file shares is supported in all the same regions that support premium file storage.
For the most up-to-date list, see the Premium Files Storage entry on the Azure Products available by region page.
NFS Azure file shares are only offered on premium file shares, which stores data on solid-state drives (SSD). The IOPS and the throughput of NFS shares scale with the provisioned capacity. See the provisioned model section of the understanding billing article to understand the formulas for IOPS, IO bursting, and throughput. The average IO latencies are low-single-digit-millisecond for small IO size while average metadata latencies are high-single-digit-millisecond. Metadata heavy operations such as untar and workloads like WordPress may face additional latencies due to high number of open and close operations.
We do not recommend using NFS for production during preview. See the Troubleshoot Azure NFS file shares article for list of known issues.
NFS preview has been validated to work well with workloads such as home directories for general purpose file servers and content repositories for application workloads.
The following workloads have known issues. See the Troubleshoot Azure NFS file shares article for list of known issues:
- Oracle Database will experience incompatibility with its dNFS feature.
- SAP Application Layer will experience inconsistent behavior due to a known active issue with ls -l.