Troubleshooting

What trouble are you having?

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

Cause:  The user belongs to one or more groups that are not mapped consistently, 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 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 the User Name Mapping service is running on the designated server.

Authenticated users cannot access network file system (NFS) resources.

Cause:  User Name Mapping is not properly configured to work with this computer.

Solution:  Ensure that the .maphosts file on the computer running User Name Mapping specifies the names or Internet Protocol (IP) addresses of computers that can map user accounts by using User Name Mapping. For more information, see Controlling access to 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. See "Error message: Unable to perform the requested operation as the mapping service cannot be contacted" in User Name Mapping Troubleshooting.

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 v3, or Server for NFS is not configured to support NFS v3. 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 v2 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:

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 User Name Mapping and that Server for NFS is configured to use the correct User Name Mapping server. Also, ensure that Server for NFS Authentication is installed on all domain controllers in the domain.

Files created by a new user are owned by Anonymous.

Cause:  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. See Refresh data now.

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 share 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 shares owned by the node offline, or move the cluster groups containing NFS shares to another node. Stop Server for NFS, start the cluster service if needed, and then restart Server for NFS. Return the NFS shares 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 share is online on a cluster node, the cluster service automatically restarts Server for NFS to keep the shares online.

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

An network NFS share on a server cluster node fails to come online.

Cause:  An NFS share on that node 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 shares 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 share online. It is recommended that the NFS share 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 shares on the disk offline. Ensure that the disk is accessible from all cluster nodes, and then bring the NFS shares online.

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

Solution:  Increase the time-out interval for the resource.

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

Cause:  The specified directory does not exist.

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

Cause:  The share is online.

Solution:  Take the share offline, make the required modifications, and then bring the share 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 share resource, and then bring the NFS share 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:

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:

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:

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 privilege to log on to the network.

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

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 share 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's 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 shares 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 shares on that node; it does not distinguish between shares in different cluster groups.

Solution:  Maintain different groups on different nodes.

The root user is not granted proper permissions.

Cause:  The share does not have root access enabled.

Solution:  Right-click the shared directory, click Properties, click Permissions, and then click Root access allowed.

Cause:  The computer from which the root user is accessing the share is not permitted root access.

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

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:

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 on Windows XP.

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 Everyone permissions to apply to anonymous users.