Best Practices for Services for Network File System

You cannot use Services for NFS or command-line utilities to administer earlier versions of Services for NFS. Also, you cannot use earlier versions of Services for NFS or command-line utilities to administer newer versions of Services for NFS.

You can use Services for NFS to administer Services for NFS components on a remote computer if both computers are running Windows Server 2008.

Services for NFS requires several ports that must be open in Windows Firewall and other firewalls. When prompted, make sure that you allow Services for NFS components.

With Server for NFS, you can control access by users and groups to Services for NFS resources. You must configure and populate Active Directory Domain Services with user identifier (UID) and group identifier (GID) information or install User Name Mapping on one computer in your network to associate Windows user accounts with UNIX user accounts. In some cases you may also need to install Server for NFS Authentication.

Server for NFS only supports storage volumes that are formatted for the NTFS file system. NTFS volumes enable you to provide file-level security by allowing and denying file access to specific users and groups. When you want anonymous users to access files, make sure that directory and file permissions provide appropriate access for anonymous users. In addition, when sharing the directory, use host-level NFS access control when creating the NFS shared resource to provide an additional level of security to protect the files in the directory.

When you add a new drive to a computer running Server for NFS, be sure to modify the permissions protecting the root directory of the drive to make sure that untrusted users, including Everyone users, cannot write to the directory. This will prevent untrusted users from being able to compromise Server for NFS security by protecting shared directories on the drive.

Before you stop Server for NFS or uninstall it, notify users who are connected to Services for NFS shared resources that you are about to stop the service. You can then stop the service after the users have had the opportunity to close open files and disconnect from shared directories.

If a directory is shared with one type of Extended UNIX Code (EUC) encoding (such as EUC-JP) and a client that is configured to use a different EUC encoding (such as EUC-TW) attempts to connect to the shared directory, unexpected results can occur. To prevent this, establish a naming convention to use when sharing directories with EUC encoding so that users of client computers can know how shared directories are encoded.

If you create configuration files (such as a character translation file or an audit log file), be sure to protect them with a discretionary access control list (DACL) that grants Full Control to the built-in System account and to the Administrators group. The DACL should contain no other entries.

To ensure proper operation of Server for NFS in a server cluster, when stopping the server cluster, first stop Server for NFS, then stop the server cluster.

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 the 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, if one node in the cluster fails over to another node, and if shared directories on the two nodes have the same name, then 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 shared resources 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 shared 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 shared resources to another node on the cluster, or take all NFS shared resources on the node offline.

Be sure to take an NFS shared 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 NFS 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 shared 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 need to do this, you must share the subdirectories separately because when you create an NFS shared 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, a malicious user 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:

• When you create the cluster resource using the cluster command, you can set some nonprivate properties, but not all.
  
  
• When using the cluster command to set properties, do not rely on default values because they might not be valid for an NFS Share cluster resource. Always set property values explicitly.
  
  
• To set or view permissions on an NFS Share cluster resource, use Cluster Administrator. You can also use the nfsshare command to view permissions, but not to set them.
  
  

Users of client computers should be instructed to use 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 using the node name allows the client computer to mount the directory, but the mount can be lost in case of a failover.