This section lists a few common issues you might encounter when working with Services for Network File System (NFS).

For more information about Services for NFS, see the Windows Server TechCenter (http://go.microsoft.com/fwlink/?LinkId=92798).

What problem are you having?

Despite appearing to have appropriate permissions, the user cannot access a folder or file

Cause

The user belongs to one or more groups that are not mapped consistently, Active Directory Domain Services is not accessible, or User Name Mapping is not running.

Solution

To ensure proper file access, ensure that Windows and UNIX groups that are mapped to each other, in either Active Directory Domain Services or User Name Mapping, contain the same users, and that the members of the Windows and UNIX groups are properly mapped to each other. Also, ensure that Active Directory Domain Services is accessible or the User Name Mapping service is running on the designated server.

Authenticated users cannot access Network File System resources

Cause

Active Directory Lookup or User Name Mapping is not properly configured to work with this computer.

Solution

If you are using Active Directory Lookup, ensure that Services for Network File System (NFS) is pointing to the proper Active Directory domain.

If you are using User Name Mapping, ensure that the .maphosts file on the computer running User Name Mapping specifies the names or IP addresses of computers that can map user accounts by using User Name Mapping. If users cannot access NFS resources intermittently and configuring the .maphosts file does not solve the problem, it might be that too many client computers are trying to access User Name Mapping simultaneously.

Users, including properly mapped users, cannot change the current directory to a shared directory or create files in the directory, even though anonymous access to the directory is allowed

Cause

Either the NFS client does not support NFS version 3, or Server for NFS is not configured to support NFS 3. Also, the discretionary access control list (DACL) protecting the shared directory does not have an entry for Everyone, and so the access mode bit for Other is reported as 0. Because NFS 2 clients rely on directory mode settings rather than performing a separate access check for the shared directory, the client incorrectly fails the attempted access.

Solution

Do one of the following:

  • To the DACL protecting the directory being shared, add an entry that grants Everyone read or read/write access, as appropriate.

  • Ensure that the NFS client supports NFS 3, and enable NFS 3 support by Server for NFS.

The shared directory is not accessible even though it is listed as available.

Cause

The directory was moved after it was shared.

Solution

Return the directory to its original location, or stop sharing the directory and then reshare it.

All files created on Server for NFS are owned by Anonymous

Cause

Authentication is not configured properly.

Solution

Ensure that mappings are set up correctly in Active Directory Domain Services or in User Name Mapping, and that Server for NFS is correctly configured to use either Active Directory Lookup or User Name Mapping. Also, be sure all domain controllers are properly configured.

Files created by a new user are owned by Anonymous

Cause

If you are using User Name Mapping, then User Name Mapping and Server for NFS have not yet refreshed data from the Network Information Service (NIS) server. Typically, User Name Mapping refreshes data from NIS once an hour, and Server for NFS refreshes data from User Name Mapping once an hour.

Solution

The new user should wait at least two hours before attempting to access or create files on Server for NFS, or the administrator of the computer running User Name Mapping can refresh the mapping database.

A user cannot write to a file

Cause

File permissions or attributes do not allow write access to the file or its directory.

Solution

If the directory is owned by the Administrators group, make an individual user account the owner of the directory. Ensure that the user's UNIX account is mapped to a valid Windows account and that the NTFS file system permissions of the directory and file allow write access to the Windows user account. Ensure that the read-only attribute is not set on the file or the directory.

Users of Japanese UNIX systems cannot view file names in Japanese

Cause

Extended UNIX character (EUC) set is not enabled.

Solution

Configure the shared resource to use the appropriate character encoding.

Server for NFS configuration settings are not replicated across nodes in a server cluster

Cause

The Cluster service is not running, was not running when Server for NFS started, or failed after Server for NFS started.

Solution

Take all NFS shared resources owned by the node offline, or move the cluster groups containing NFS shared resources to another node. Stop Server for NFS, start the Cluster service if needed, and then restart Server for NFS. Return the NFS shared resources online or move the cluster groups back to the node.

Server for NFS fails to stop on a server cluster

Cause

This is by design. When an NFS shared resource is online on a cluster node, the cluster service automatically restarts Server for NFS to keep the shared resources online.

Solution

Before stopping Server for NFS on a server cluster node, take all NFS shared resources owned by the node offline, or move the cluster groups containing NFS shared resources to another node.

An NFS shared resource on a server cluster node fails to come online

Cause

An NFS shared resource with the same alias or path already exists on the node.

Solution

Make sure that the shared path and alias are unique across the cluster. Also, avoid having nonclustered NFS shared resources on a server cluster node.

Cause

The user who installed the cluster service does not have read permission on the directory that is shared, so the path cannot be validated.

Solution

Grant read access to the directory for the user who installed the cluster service.

Cause

The disk resource containing the directory being shared is offline, so the cluster service cannot verify the path of the share.

Solution

Bring the disk resource online, and then bring the NFS shared resource online. We recommend that the NFS shared resource be made dependent on the disk resource that contains the shared folder.

Cause

The disk is inaccessible due to hardware error.

Solution

Take the NFS shared resources on the disk offline. Ensure that the disk is accessible from all cluster nodes, and then bring the NFS shared resources online.

Cause

There are a large number of subdirectories under a subdirectories-only share, and the resource times out before all the shared resources are created when the resource is coming online.

Solution

Increase the time-out interval for the resource.

Creating or modifying an NFS shared resource fails with the error: The share path specified does not exist, or you are trying to modify the properties of an online shared resource

Cause

The specified directory does not exist.

Solution

Make sure that the directory exists and that the path is correct.

Cause

The shared resource is online.

Solution

Take the shared resource offline, make the required modifications, and then bring the shared resource online.

Cause

The disk resource containing the shared directory is offline, so the cluster service cannot verify the path of the share.

Solution

Bring the disk online, make the necessary modifications to the NFS shared resource, and then bring the NFS shared resource online.

User Name Mapping is properly configured, but users are not being mapped correctly

Cause

Server for NFS is not set to use the correct User Name Mapping server.

Solution

Ensure that the specified User Name Mapping server is valid. If the User Name Mapping server is on a server cluster, ensure that the following conditions exist:

  • User Name Mapping is installed on all cluster nodes

  • User Name Mapping data is being replicated to all nodes in the cluster

  • Server for NFS is using the name of a Network Name cluster resource as the User Name Mapping server, not localhost or the name of any of the cluster nodes

Cause

Server for NFS has not received updated maps from the mapping server. If Server for NFS and User Name Mapping are on different computers, this occurs once every 30 minutes.

Solution

Force Server for NFS to refresh the maps by doing one of the following:

  • Use the nfsadmin server command to execute an operation, such as by setting a value to its current value.

  • Restart Server for NFS.

Cause

Account changes on the Windows domain controller or the Network Information Service (NIS) server have not been received by User Name Mapping.

Solution

Force Server for NFS to refresh the maps by doing one of the following:

  • In Services for Network File System, click Server for NFS, and then click Apply.

  • Use the nfsadmin server command to execute an operation, such as by setting a value to its current value.

  • Restart Server for NFS.

Cause

Local accounts on a cluster node were mapped to UNIX user accounts. Local accounts are not valid on all nodes in a cluster.

Solution

Ensure that all Windows accounts mapped to UNIX accounts on User Name Mapping running on a cluster are Windows domain accounts.

Cause

The passwd and group files are not at the same location on all nodes of the cluster, or on a network drive.

Solution

Ensure that the passwd and group files are identical and at identical locations on local disks of all nodes.

Cause

The Server for NFS server is not on the list of permitted User Name Mapping server clients.

Solution

Ensure that the .maphosts files on all User Name Mapping server cluster nodes are identical to permit the node running Server for NFS to obtain maps from the User Name Mapping server.

Cause

The server running User Name Mapping has failed.

Solution

Correct the cause of failure and then restart User Name Mapping on the server.

Cause

A Windows account mapped to a UNIX account is disabled or no longer exists.

Solution

If the Windows account exists but is disabled, enable it. If the account does not exist, create a new account and, if necessary, recreate the corresponding advanced map.

Cause

A Windows user account has not been granted the credentials to log on to the network.

Solution

Grant the required credentials to the Windows user account, and then force Server for NFS to refresh the maps by doing one of the following:

  • Use the nfsadmin server command to execute an operation, such as by setting a value to its current value.

  • Restart Server for NFS.

Cause

Windows and UNIX groups mapped to each other do not contain the same members.

Solution

Ensure that all Windows users in a group are mapped to UNIX users in the corresponding UNIX group, and that all UNIX users in a group are mapped to users in the corresponding Windows group.

Cause

User Name Mapping settings are not properly replicated on all nodes in a server cluster.

Solution

Ensure that User Name Mapping on a server cluster is configured properly to allow replication on all nodes.

A group containing an NFS shared resource fails to come online on a particular cluster server node

Cause

Server for NFS is not installed on the node.

Solution

Install Server for NFS on the node.

Cause

The node is not configured as the preferred owner of the group.

Solution

Configure the group properties to make the node the preferred owner of the group.

Cause

One of the resources in the group does not list the node as a possible owner even though the group specifies the node as a preferred owner.

Solution

Configure the resource's properties to specify the node as a possible owner.

The showmount –e command for a virtual server lists all shared resources on the node rather than those in the same group as the virtual server

Cause

This is by design. There is only one instance of Server for NFS running on a node that will enumerate all shared resources on that node. It does not distinguish between shared resources in different cluster groups.

Solution

Maintain different groups on different nodes.

The root user is not granted proper permissions

Cause

The shared resource does not have root access enabled.

Solution

Right-click the shared directory, click Properties, click NFS Sharing, click Permissions, and then click Allow root access.

Cause

The computer from which the root user is accessing the shared resource is not permitted root access.

Solution

Right-click the shared directory, click Properties, click Permissions, and then do one of the following:

  • Grant root access to ALL MACHINES.

  • Grant root access to a client group containing the computer.

  • Grant root access to the computer itself.

Cause

The root user does not have read/write permission.

Solution

Grant the appropriate permissions to the Windows user mapped to the root user. Right-click the shared directory, click Properties, click Permissions, and then click Root access allowed.

Cause

The root user account is not properly mapped to a Windows user account.

Solution

Map the root user to a Windows account in the Administrators or Domain Admins group, and map the root user's group to the same Windows group.

Cause

Server for NFS has not received updated maps from User Name Mapping.

Solution

Force Server for NFS to refresh the maps by doing one of the following:

  • Use the nfsadmin server command to execute an operation, such as by setting a value to its current value.

  • Restart Server for NFS.

Cause

The root user's user identifier (UID) is not 0. Server for NFS grants root access only to a UNIX user with a UID of 0.

Solution

Change the root user's UID to 0.

Anonymous access fails

Cause

Local security policy is not set to enable Everyone permissions to apply to anonymous users (the default).

Solution

Use the Local Security Policy manager to enable Network Access: Let Everyone permissions apply to anonymous users in Security Options in Local Policies.

  • Manage NFS Client Groups