- Windows NFSv3.0
- NetApp FAS controllers running clustered Data ONTAP
- Data ONTAP 7-Mode
- Data ONTAP 8.2
- Data ONTAP 8.2.3
- Data ONTAP 8.3
- Data ONTAP 8.3.1
This article lists the top known issues, limitations, workarounds, and best practices for a Windows NFS client, when used with NetApp FAS controllers running clustered Data ONTAP.
ONTAP Support Limitation:
The Microsoft Windows native NFS client implementation is supported with all currently supported Data ONTAP 7-Mode systems. In addition, clustered Data ONTAP 8.2 releases starting with 8.2.3 are supported. Also, clustered Data ONTAP 8.3 releases starting with 8.3.1 are supported.
Unavailability of 'Network Status Monitor (NSM)' protocol support results in IO disruptions in the Windows NFS client.
Description: By the current design, Windows NFSv3 clients do not support the NSM protocol. Due to this, share locks, byte range locks from the client are lost during storage failover operations which involves lif failovers (takeover-giveback,panic giveback,revert etc.) as well as the storage mobility operations (vol move/aggregate relocate). This results in IO disruptions in the client. Error messages similar to the following might be reported: '
Error no.59 (unexpected network error)'.
The following error message is reported in the Windows NFS client during I/O with Storage Failover / Mobility Operations:
winerror=158-The segment is already unlocked'
Description: NFS servers maintain a replay cache for non-idempotent operations sent from clients. This replay cache holds the response to the original non-idempotent operation from the client. This is required to provide the same response to re-transmit the requests. Processing the re-transmitted request again, has different and unexpected results.
For example, without the replay cache, an UNLINK operation could get a SUCCESS result for the first time but an
ENOENT error on the retransmitted request. In Data ONTAP, the replay cache is not persistent. Therefore, in events like Storage Failover (SFO) / Aggregate Relocate (ARL) where the storage is moved from one node to another, the replay cache for NFS operations on that storage is lost. Retransmitted NFS operations do not have the protection of the replay cache immediately following an SFO/ARL event.
"Network Error - 53" while trying to mount NFS share on Windows
Description: Customer is attempting to mount an NFSv3 mount on windows but receiving generic
"Network Error - 53".
Example of command:
C:\Users\admin> mount 10.0.0.1:\share Z:
- Storage Virtual Machine (SVM) settings are required for Windows NFSv3 enablement:
To enable Windows NFSv3 client on Storage Virtual Machines (SVMs), run the following command:
vserver nfs modify -vserver svm_name -v3-ms-dos-client enabled
Run the following command to disable the
-enable-ejukebox and -v3-connection-dropparameters, on all SVMs that support Windows NFSv3 clients. Also, this makes the volume move non disruptive.
vserver nfs modify -vserver vserver_name -enable-ejukebox false -v3-connection-drop disabled
- Windows NFSv3 clients use soft mounts by default. However, always use hard mounts when mounting exports on the storage system from Windows NFSv3 clients by specifying the
- Prior to a planned storage failover, make sure all the Windows NFS clients are unmounted. This prevents any outstanding NLM locks from being left in the cluster.
- After unplanned storage failures, remount Windows NFS clients. This operation will force the client to properly cleanup any stale NLM locks created by client.
- Starting clustered Data ONTAP 8.3 , Windows NFSv3 clients must include the string
ROOT-pathbetween the IP address or host name and the junction path to properly mount the export:
mount -o mtype=hard\10.53.33.10ROOT-pathvolvol1 z:
Mentioning ROOT-path is not required for Data ONTAP 8.3.1.
mount -o mtype=hard\10.53.33.10volvol1 z:
- Starting clustered Data ONTAP 8.3 release, the
showmountcapability is available in the storage system. Run the
nfs server modify -vserver NFS83-showmount enableto enable it. Once enabled, any new volumes or qtrees created will be reflected in the output of the
showmount -e <dataip>command on the client. To view previously created volumes or qtrees, run the cache clear
export-policy cache flush -vserver SVM -cache showmountcommand.
For more information on the use of
showmount, see page 51 of the TR-4067: Clustered Data ONTAP NFS Best Practice and Implementation Guide.
TR-4067 - Clustered Data ONTAP NFS Best Practice and Implementation Guide