Support NFS File Shares

[MRayermannMSFT]

Assuming the existence of a REST API for Azure Files NFS v4.1, we should consider adding support for viewing file share data over the NFS REST API.

NFS file share support will come gradually, so file share features need to be examined and tested individually for support. If a feature is not available for NFS yet, we should disable the feature/command if possible.

In addition, support for various combinations of SMB or NFS sources/destinations for file transfers should be verified and tested.

[craxal]

Support, Findings, and Caveats

NFS file shares can only be created in premium storage accounts configured for file shares.

The Azure REST API currently has support for NFS file shares as of 2025-05-05. However, some API parameters are only supported for SMB file shares. Attempting to send requests with SMB-only parameters to NFS file shares results in failures.

The Azure client library for JS has support for NFS file shared, but it requires explicitly setting the API version to at least 2025-05-05. Some API calls will also require fine-tuned REST parameter adjustments, because the client library automatically inserts certain SMB-only parameters.

AzCopy does not yet support NFS file shared, but they are working on it.

Design Plan

Although the protocol is not necessarily part of a REST API request, it is essential information for forming a valid request. The purpose of connection objects is to contain all information necessary to connect to the target resource. Therefore, the file share protocol should be part of the file share connection object. Adding protocols to the connection object has the benefit of supporting features like Quick Access and attached shares without needing add lot of extra code to these separate systems.

Backwards Compatibility

It should be noted that current published versions of Storage Explorer already provide limited interactivity with NFS file shares. For example, Storage Explorer will show file share nodes for both NFS and SMB protocols despite not having any code for handling NFS. Users can even pin them to Quick Access or create attached connections to them (assuming they have storage account keys). However, most interactions, such as opening a tab on the NFS file share, will result in the same errors described above.

Adding NFS file share support to Storage Explorer will not fix existing Quick Access or attachments, because they will be missing the essential protocol information. There are several options to work around this:

• Query the file share service for the protocol. This won't work for cases where the user does not have permission to list file shared or get file share properties (such as for a SAS-attached file share).
• Try an NFS request after an SMB request fails. This would result in a lot of failed requests unless we cached the result somewhere. I don't think making guesses over using the data Azure gives us in this case is a good idea.
• Do nothing. Considering prexisting Quick Access and attachment items would be of very little use prior to NFS support anyway, it is not likely users would have these items.

[craxal]

Follow up with SDK and AzCopy to determine release dates for phase 2 support.