Skip to main content
NetApp Knowledge Base

Top Windows NFSv3.0 Issues, Workarounds and Best Practices

Views:
4,841
Visibility:
Public
Votes:
4
Category:
data-ontap-8
Specialty:
nas
Last Updated:

Applies to

  • 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

Answer

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. 

Issues:

Issue 1:

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)'.

Workaround: None

Issue 2:

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.

Workaround: None

Issue 3:

"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:

Workaround:
1. Check syntax of command
Correct syntax can be found here.
2. Mismatch of NFS versions between client and server
3. Last workaround can be found here.

Best Practices

  1. 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-drop parameters, 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 
  2. 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 -o mtype=hard option.
  3. 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.
  4. After unplanned storage failures, remount Windows NFS clients. This operation will force the client to properly cleanup any stale NLM locks created by client.
  5. Starting clustered Data ONTAP 8.3 , Windows NFSv3 clients must include the string ROOT-path between the IP address or host name and the junction path to properly mount the export: \IPaddress_or_hostnameROOT-pathjunction_path.
    Example: mount -o mtype=hard  \10.53.33.10ROOT-pathvolvol1 z:
    Mentioning ROOT-path is not required for Data ONTAP 8.3.1.
    Example: mount -o mtype=hard \10.53.33.10volvol1 z:
  6. Starting clustered Data ONTAP 8.3 release, the showmount capability is available in the storage system. Run the nfs server modify -vserver NFS83-showmount enable to 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 showmount command.
    For more information on the use of showmount, see page 51 of the TR-4067: Clustered Data ONTAP NFS Best Practice and Implementation Guide.

Additional Information

TR-4067 - Clustered Data ONTAP NFS Best Practice and Implementation Guide

 

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.