To ensure that a shared directory cluster resource will be available after the node containing the resource fails, make the cluster resource dependent on the appropriate physical disk resource.
Although you can use Windows Explorer to view properties of an NFS share cluster resource, you should not use it to change those properties. You should only use Cluster Administrator or the cluster command to create and administer shared NFS directories on a server cluster.
Ensure that the share name of every shared directory on the server cluster is unique. Otherwise, when one node in the cluster fails over to another node, and if shared directories on the two nodes have the same name, only one of the shared directories will be available.
Do not designate a shared disk resource as the location of the Server for NFS audit log. Only one node in the cluster can own the log file. This means that if the ownership of a group is moved to another node, the audit events for the remaining shares on the original node cannot be recorded in the file. To ensure the availability of Server for NFS audit logs, you should log events to the Event Viewer event log.
When Server for NFS is stopped on a cluster node hosting active NFS share resources, the cluster service responds as though this were a failure of one of its managed resources. Consequently, the cluster service will try to restart the service in an attempt to keep the resource available. Before you attempt to stop Server for NFS on a server cluster node, either move all groups containing NFS file shares to another node on the cluster, or take offline all NFS file shares on the node.
Be sure to take an NFS share directory resource offline before modifying its properties. Failing to do so might produce unexpected results.
To ensure that Server for NFS configuration changes are properly replicated, always use a computer that belongs to a trusted domain when you administer Server for NFS running on a cluster. This is necessary because Server for NFS configuration changes are not properly replicated among nodes in a cluster if you run Services for UNIX Administration or nfsadmin on a computer that belongs to a domain that is not trusted by the domain of the cluster.
If the Cluster service must be restarted on a node in the cluster, stop and then restart the Server for NFS service on that node. This will ensure that Server for NFS configuration changes will be replicated properly among the nodes of the cluster.
When you create an NFS share directory resource, you have the option of sharing the root of the specified directory, or all the subdirectories in the directory. Before choosing this option, first decide whether you will need to control access to the subdirectories or change their share names. If you will, you must share the subdirectories separately because when you create an NFS share directory resource to share the subdirectories, you cannot set access permissions, allow (or deny) anonymous access, or change the share name of the subdirectories separately.
If you choose to share all the subdirectories in the directory, make sure that the permissions protecting the directory do not allow untrusted users to create subdirectories. Otherwise, an attacker can overwhelm the cluster service by creating a very large number of subdirectories that would automatically be shared as a cluster resource.
If you use the cluster command to create and modify NFS share cluster resources, the following considerations apply:
Users of client computers should be instructed to used hard mounts when mounting NFS directories shared on the server cluster. This will ensure that, if the node sharing the directory fails, the client computer will not time out before the failover to another node is complete.
Users of client computers should be instructed to mount NFS directories shared on the server cluster using the virtual server name from the same group as the shared directory. Using a virtual server name from another group or the node name will allow the client computer to mount the directory, but the mount can be lost in case of a failover.