Azure Files Premium (NFSv4.1) — "Remote I/O error" from both Azure and on-prem clients

Hello Shing Fan LEE,

You’re hitting intermittent Remote I/O error (EREMOTEIO) on an Azure Files Premium share using NFSv4.1. Since it happens from both Azure-hosted and on-prem Linux clients (over private connectivity) it’s a good signal to focus on the NFS client + Azure Files NFS troubleshooting checks, not just a single network path.

Based on the provided docs, here are the most relevant things to try/check for this kind of Azure Files NFS behavior.

1) Confirm the NFS packages are installed

Before mount/options changes, make sure the correct NFS packages are installed on each

• RHEL/CentOS/Oracle Linux: nfs-utils

    sudo rpm -qa | grep nfs-utils
  

  SLES: nfs-client

    sudo rpm -qa | grep nfs-client
  

  Ubuntu/Debian: nfs-common

    sudo dpkg -l | grep nfs-common
  

If missing, install via distro package manager (examples in the doc).

2) Verify NFS port 2049 is open/reachable from user

Even if mounts succeed, intermittent I/O failures can occur if the path isn’t consistently allowing NFS traffic. NFS uses port 2049, so validate connectivity from both the Azure VMs and the on-prem clients:

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

Do this for every client that experiences the error.

3) Validate private endpoint / endpoint routing is correct for NFS

The NFS troubleshooting guidance emphasizes that authentication for NFS is network-rule based and that you must use the correct access method (service endpoint or private endpoint). For your scenario, ensure:

• clients are consistently using the private endpoint path (DNS resolution + routing remains stable)
• network security rules / firewall paths allow the NFS traffic via that private endpoint configuration

4) Check for stale/orphaned NFS file handles on the clients (.nfs*), then unmount/remount

The troubleshooting content calls out a situation where the client can end up with orphaned/stale state (e.g., .nfs* artifacts / open handles), which can lead to abnormal I/O behavior.

On a client where the issue is observable, check for orphaned handles:

lsof /path/to/nfs/share
lsof +D /path/to/nfs/share
find /path/to/nfs/share -name ".nfs*"

If you find .nfs* files or see deleted/open files still held:

• restart the process using the mount, and/or
• unmount and remount the share

5) If you’re using NFSv4.1 ID domain features, double-check ID mapping alignment

You mentioned permission/root-squash mismatches aren’t the cause (mid-I/O failures), but the docs also include an NFSv4.1 troubleshooting lab focused on ID domain alignment (fixes symptoms like nobody:nogroup / UID/GID resolution issues). If anything about ownership/IDs looks inconsistent, it’s worth verifying ID domain configuration and client idmapd alignment.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.