NFS Azure file shares

Applies to: ✔️ NFS file shares

Azure Files supports two industry-standard protocols for mounting file shares: the Server Message Block (SMB) protocol and the Network File System (NFS) protocol. Choose the protocol that best fits your workload. Azure file shares don't support accessing an individual Azure file share with both the SMB and NFS protocols. For classic file shares, you can create separate SMB and NFS file shares within the same FileStorage 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.

Common use cases for NFS Azure file shares

NFS file shares 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.

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
• Workloads that require POSIX-compliant file shares, case sensitivity, or Unix style permissions (UID/GID)
• New application and service development that requires random I/O and hierarchical storage

NFS Azure file share features

NFS Azure file shares offer a fully POSIX-compliant file system. Hard links and symbolic links are supported, however you can't create a hard link from an existing symbolic link.

NFS Azure file shares currently support most features from the NFSv4.1 protocol specification. Some features such as delegations and callback of all kinds, Kerberos authentication, and ACLs aren't supported.

Locally redundant storage (LRS) and zone-redundant storage (ZRS) are supported for NFS Azure file shares. Geo-redundant storage (GRS) and geo-zone-redundant storage (GZRS) aren't available for NFS shares because NFS requires SSD storage, which doesn't support geo-redundancy.

NFS Azure file share support for Azure Files features

The following table shows the current level of feature support for NFS Azure file shares.

The status of items that appear in this table might change over time as support continues to expand.

Security and networking for NFS Azure file shares

NFS Azure file shares protect data through encryption at rest and in transit, and require network-level access controls in place of user-based authentication.

Encryption

Azure Files encrypts all data at rest by using Azure storage service encryption (SSE). Storage service encryption works similarly to BitLocker on Windows: it encrypts data beneath the file system level. Because encryption happens beneath the Azure file share's file system as data is encoded to disk, you don't need 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.

The classic file shares support TLS encryption in transit through the AZNFS mount helper.

You configure Require Encryption in Transit for NFS on the storage account. For new storage accounts created through the Azure portal, this setting is enabled by default. When the setting is Not selected, Secure transfer required governs NFS encryption behavior. For creation defaults and configuration steps, see Enforce encryption in transit.

Azure provides a layer of encryption for all data in transit between Azure datacenters by using MACSec. Through this technology, encryption exists when data is transferred between Azure datacenters.

Authentication and network access

Because NFS Azure file shares don't support user-based authentication, they rely on network access rules to authenticate clients. Clients must therefore connect through a private endpoint or a service endpoint with virtual network restrictions.

Private endpoints

A private endpoint provides a private IP address in your virtual network for access to the file share. To allow access only through private endpoints, disable public network access. Private Link charges apply.

Clients can connect from the virtual network or from peered virtual networks. For on-premises access, connect your network to the virtual network through a VPN or ExpressRoute.

Service endpoints

A service endpoint lets clients in a subnet access the file share's public endpoint over the Azure backbone. Enable the service endpoint on the client subnet. Configure the file share's network rules to allow that subnet. Allowed subnets can be in the same subscription or a different subscription, including a different Microsoft Entra tenant. There's no extra charge for service endpoints.

A service endpoint doesn't assign a private IP address to the file share. If a rare event, such as a zone outage, changes the public endpoint's IP address, clients might need to remount the share.

Optional outbound filtering

The file share's network rules control which clients can access it. They don't limit which other storage resources those clients can access. For example, a client that can read your file share could copy data to another resource it has permission to write to.

For classic file shares, you can optionally use a service endpoint policy to limit which storage accounts clients in a subnet can access through service endpoints. Service endpoint traffic bypasses Azure Firewall and network virtual appliances. A policy filters destinations on this path. It doesn't restrict other outbound paths or replace the destination's network rules and authorization requirements.

For more information about networking options, see Azure Files networking considerations.

NFS Azure file share regional availability

Regional availability depends on the redundancy option:

See LRS regions and ZRS regions.

NFS Azure file share performance

NFS Azure file shares are only available on SSD file shares. The provisioned v2 billing model lets you set provisioned capacity, IOPS, and throughput independently. Classic file shares also support the provisioned v1 billing model, in which IOPS and throughput scale automatically with provisioned capacity. For details on both models, see Understand Azure Files billing.

Typical I/O latencies for SSD Azure file shares are in the low-single-digit millisecond range for small I/O operations. Metadata-heavy workloads such as untar might experience higher latencies due to the high volume of open and close operations.

For guidance on improving NFS performance at scale, see Improve NFS Azure file share performance.

Next steps

• Create a classic file share
• Compare NFS options across Azure storage services