nfs share facing a connection issues

Question

nfs share facing a connection issues

Shing Fan LEE 20

We have one mount on nfs having a connectivity issues

Shing Fan LEE 20 Reputation points

2026-06-30T15:59:47.0633333+00:00

when i want to check some values from the portal it show me nothing, and it looks likely not from our end issue.
Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2026-09-04T02:51:31.62+00:00
Hello Shing Fan LEE

You’re running into that—when an NFS mount has connectivity issues, it can definitely look like “nothing shows in the portal” / no useful data, but the root cause is usually networking, mount configuration, or access rules (not the portal itself).

Here are the most common things to check for Azure Files NFS connectivity, based on the troubleshooting guidance:

Confirm NFS connectivity to the storage endpoint (port 2049)

NFS uses TCP port 2049. Make sure it’s open from the client to the storage account (NFS server).

On the Linux client you can test:

sudo nc -zv <storageaccountname>.file.core.windows.net 2049

Also confirm DNS resolution works (you should use the storage account FQDN when mounting/accessing).

If your request comes from an untrusted network/IP, validate endpoint access rules

For NFS, authentication depends on the network security rule configuration (unlike SMB user-based auth). If the client is coming from an “untrusted” IP/network, you must allow it using one of these supported approaches:

Service endpoint (public endpoint access restricted)

Private endpoint (more secure)

If this isn’t set up correctly, mounting and access can fail or behave inconsistently.

Check whether “secure transfer” / encryption-in-transit is causing the mount failure

If secure transfer/encryption-in-transit is enabled for your storage account, NFS mounts may fail unless you use the correct secure-mount approach.

Guidance:

Either disable both the secure transfer requirement settings that affect NFS, or

Mount using the AZNFS Mount Helper (designed to establish TLS tunnels for NFSv4.1 secure mounting with auto-reconnect).

Verify the client has NFS utilities installed

On the Linux client, ensure the NFS client packages are installed:

nfs-utils (and/or nfs-client / nfs-common depending on distro)

Double-check mount options / NFS version compatibility

Common causes include:

Incorrect or unsupported mount options

Incompatible NFS version (ensure client/server use the same NFS version)

Also, make sure you’re using the supported mount options from Azure’s documented list.

Quick questions so we can narrow it down fast

What exact mount command are you using (including mount options like vers= if present)?

Are you using public endpoint, restricted public endpoint, or a private endpoint?

What do you see in the Linux system logs or mount output when it fails? (Any mount.nfs: error text is very helpful.)

Does the client pass this test?

- nc -zv <storageaccountname>.file.core.windows.net 2049

Is encryption in transit / secure transfer required enabled on the storage account?

Reference list (relevant docs) Troubleshoot NFS Azure file shares (common NFS causes/solutions): https://learn.microsoft.com/troubleshoot/azure/azure-storage/files/security/files-troubleshoot-linu… Troubleshoot Azure Files connectivity (general DNS + port connectivity checks): https://learn.microsoft.com/troubleshoot/azure/azure-storage/files/connectivity/files-troubleshoot Mount NFS Azure file shares on Linux (mounting + options): https://learn.microsoft.com/azure/storage/files/storage-files-how-to-mount-nfs-shares Encryption in transit for NFS Azure file shares: https://learn.microsoft.com/azure/storage/files/encryption-in-transit-for-nfs-shares AZNFS Mount Helper (GitHub): https://github.com/Azure/AZNFS-mount Troubleshoot Azure Files general issues / mount diagnostics & tools overview: https://supportabilityhub.microsoft.com/solutions/apollosolutions/695032f0-8d10-2ab3-6a67-da09b02ab…

If you reply with the mount command + the error output + whether private endpoint / secure transfer is enabled, I can suggest the most likely fix path.

1 answer

Your answer

Shing Fan LEE 20 Reputation points

2026-06-30T15:59:47.0633333+00:00

when i want to check some values from the portal it show me nothing, and it looks likely not from our end issue.

Answer 1

For connectivity issues to an NFS Azure file share, validate these key areas on the Linux client and in Azure:

Verify NFS client packages are installed
Azure Files NFS requires the appropriate NFS utilities on the client:

RHEL/CentOS/Oracle Linux:

     sudo rpm -qa | grep nfs-utils

If missing:

     sudo yum install nfs-utils      # OS 7.x
     sudo dnf install nfs-utils      # OS 8.x or 9.x

SLES:

     sudo rpm -qa | grep nfs-client

If missing:

     sudo zypper install nfs-client

Ubuntu/Debian:

     sudo dpkg -l | grep nfs-common

If missing:

     sudo apt update
     sudo apt install nfs-common

Check network path and firewall (port 2049)
NFS uses TCP port 2049. Ensure the client can reach the Azure Files NFS endpoint:
```
   sudo nc -zv <storageaccountname>.file.core.windows.net 2049
```
- If this fails, open outbound TCP 2049 on any local firewall and verify NSGs and network devices allow this traffic to the storage account.
Confirm trusted network / endpoint configuration
NFS Azure file shares rely on network-based access control:
- Use service endpoints or private endpoints for access.
- For on-premises access, use VPN or ExpressRoute with private endpoints for more secure connectivity.
- With private endpoints, ensure:
  - The VM’s virtual network/subnet is associated with the private endpoint.
  - Private DNS integration is correctly configured so the storage account name resolves to the private IP.
Validate encryption-in-transit settings vs mount method
If the storage account has:
- Secure transfer required and/or
- Require encryption in transit for NFS
then:
- Native NFS client mounts will fail; use the AZNFS Mount Helper to mount the share.
- Alternatively, disable both Secure transfer required and Require encryption in transit for NFS if encryption in transit is not required.
Use correct NFS mount options (Azure Files NFS)
When mounting, ensure the options match Azure Files requirements, for example:
- vers=4 and minorversion=1 (Azure Files supports NFSv4.1 only).
- sec=sys (AUTH_SYS using local UNIX UIDs/GIDs).
- Recommended performance options: rsize=1048576, wsize=1048576, actimeo=30-60, nconnect=4.
- For kernels before 5.18, use noresvport to improve reconnection behavior.
Check for storage account deletion if timeouts occur
If mounts fail with connection timed out, verify the storage account still exists. If it was deleted and recovered, recreate the private endpoint so it points to the new resource ID.
Kernel version issues (directory listing hangs)
If ls or directory enumeration hangs on large directories:
- Linux kernel v5.11–v5.12.4 has a bug causing endless READDIR sequences.
- Upgrade or downgrade the kernel outside this range (for example, RHEL 8.4 uses the affected kernel).

If the issue persists after these checks, focus on verifying endpoint configuration (service vs private), DNS resolution to the correct endpoint, and whether encryption-in-transit settings align with the chosen mount method (native NFS vs AZNFS helper).

References: