Edit

NFS file shares in Azure Files

  • Article

Azure Files offers two industry-standard file system protocols for mounting Azure file shares: the Server Message Block (SMB) protocol and the Network File System (NFS) protocol, allowing you to pick the 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. 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.

Important

NFS Azure file shares aren't supported for Windows. Before using NFS Azure file shares in production, see Troubleshoot NFS Azure file shares for a list of known issues. NFS access control lists (ACLs) aren't supported.

Common scenarios

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 I/O and hierarchical storage.

Features

  • 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, ACLs, and encryption-in-transit aren't supported.

Note

Creating a hard link from an existing symbolic link isn't currently 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 you must set up a VPN or ExpressRoute in addition to a private endpoint. Requests that do not originate from the following sources will be rejected:

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 table 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 ✔️
LRS to ZRS conversion ⛔
Azure DNS Zone endpoints (preview) ✔️
Private endpoints ✔️
Subdirectory mounts ✔️
Grant network access to specific Azure virtual networks ✔️
Grant network access to specific IP addresses ⛔
Premium tier ✔️
Standard tiers (Hot, Cool, and Transaction optimized) ⛔
POSIX-permissions ✔️
Root squash ✔️
Access same data from Windows and Linux client ⛔
Identity-based authentication ⛔
Azure file share soft delete ⛔
Azure File Sync ⛔
Azure file share backups ⛔
Azure file share snapshots ⛔
GRS or GZRS redundancy types ⛔
AzCopy ⛔
Azure Storage Explorer ⛔
Support for more than 16 groups ⛔

Regional availability

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.

Performance

NFS Azure file shares are only offered on premium file shares, which store data on solid-state drives (SSD). The IOPS and 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 the high number of open and close operations.

Note

You can use the nconnect Linux mount option to improve performance for NFS Azure file shares at scale. For more information, see Improve NFS Azure file share performance with nconnect.

Workloads

Important

Before using NFS Azure file shares in production, see Troubleshoot NFS Azure file shares for a list of known issues.

NFS has been validated to work well with workloads such as SAP application layer, database backups, database replication, messaging queues, home directories for general purpose file servers, and content repositories for application workloads.

The following workloads have known issues:

  • Oracle Database will experience incompatibility with its dNFS feature.

Next steps