Unable to mount Azure Files Share (works with aznfs but fails with nfs)

Marius Shekow 45 Reputation points
2025-08-23T17:19:58.1633333+00:00

On a RedHat Linux VM, I'm unable to mount an Azure File share using NFS 4.

It works when running a command such as "mkdir testmount && sudo mount -t aznfs -o actimeo=30,nconnect=4,noresvport,vers=4,minorversion=1,sec=sys MYSTORAGEACCOUNT.file.core.windows.net:/MYSTORAGEACCOUNT/myfileshare testmount"

But it fails if I replace "-t aznfs" with "-t nfs", with an "access denied" error. This is the output when also providing the "-vvv" flag to the mount command:

mount.nfs: timeout set for Sat Aug 23 17:02:13 2025
mount.nfs: trying text-based options 'actimeo=30,nconnect=4,noresvport,vers=4,sec=sys,vers=4.1,addr=192.168.5.73,clientaddr=192.168.5.132'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting MYSTORAGEACCOUNT.file.core.windows.net:/MYSTORAGEACCOUNT/myfileshare

My Storage account has "Public access" disabled, and I created a Private endpoint (with DNS Zone integration) for the "files" target (and the above log shows that it is properly resolved). And obviously, connectivity is fine in principle (when using the "aznfs" mount helper). Why on earth would it fail with "nfs" helper? I ran these two commands on the same Linux VM right after another.

Note: there are no debug logs on the Files Share! I set up a "Diagnostic setting" to send all log categories to a Log Analytics Workspace. However, the "StorageFileLogs" table does not show anything during the time frame of the failed requests (but it shows successful requests that happened when I used the "aznfs" helper).

In case you are wondering why I simply don't keep using "aznfs": I actually want to mount the Files share in Kubernetes (AKS) which uses "-t nfs" and I don't think I can change this.

Azure Files
Azure Files

An Azure service that offers file shares in the cloud.

0 comments

Answer accepted by question author

Vinodh247-1375 43,346 Reputation points Volunteer Moderator
2025-08-24T04:48:58.4266667+00:00

Hi ,

Thanks for reaching out to Microsoft Q&A.

For me it looks like you are hitting a platform limitation, not a configuration mistake. Your azure Files share looks fine, the issue is that the native mount -t nfs client does not fully support azure files NFS, while the aznfs helper does.

The aznfs mount helper that microsoft provides is not just a wrapper for the mount command. It handles Azure-specific logic like session negotiation and correct mount options that the standard NFS client does not. That is why aznfs works and nfs fails with “access denied”, even though DNS and private endpoint connectivity are working.

Also, azure NFS shares only use networkbased access. There is no user authentication, so the server just rejects requests that do not match what it expects from the client. The native NFS client does not align properly with those requirements in private endpoint mode.

If your goal is to mount in Kubernetes (which defaults to -t nfs), you have two options:

  1. Use or build a CSI driver that wraps aznfs so it mounts correctly in AKS
  2. Mount the share on the node with aznfs first (through a DaemonSet or node bootstrap script?), and then mount the local path into your pods.

There is no fix to make the plain mount -t nfs command work with azure Files NFS in a private endpoint scenario. If you switch back to service endpoints (not recommended for security), you might get it to work, but it is still not officially supported.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Was this answer helpful?

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jerry Osemwenkha 0 Reputation points Microsoft Employee
    2026-06-02T19:25:39.5133333+00:00

    Yes. That is correct @Blazhko, Alexey

    The Secure transfer required setting enforces encryption in transit for all file shares within the storage account unless the Require encryption in transit for NFS setting is enabled, in which case Secure transfer required only applies to REST/HTTPS traffic. For NFS file shares, using encryption in transit requires mounting the share using the AZNFS Mount Helper, a client utility package that abstracts the complexity of establishing secure tunnels for NFSv4.1 traffic.

    To fix this, you can either disable both the Secure transfer required setting and the Require encryption in transit for NFS setting on the storage account or use the AZNFS mount helper to mount the share.

    Similar issue can be found here:
    https://github.com/Azure/AKS/issues/5230

    Was this answer helpful?

    0 comments
  2. Blazhko, Alexey 0 Reputation points
    2025-08-25T09:48:33.8266667+00:00

    Hi Marius,

    Could it be that the "Secure transfer required" setting is Enabled for your Storage account? This will prevent unencrypted connection attempts with mount -t nfs or -notls options.

    See the screenshot:

    https://learn.microsoft.com/en-us/azure/storage/files/media/encryption-in-transit-nfs-shares/storage-account-settings.png#lightbox

    Alexey

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.