Technical Notes |
|
This technical note contains suggestions for troubleshooting authentication problems when using the Reflection NFS client.
The table below describes common authentication problems and identifies the troubleshooting sections that you should use to resolve the issue. If your problem is not listed in the table, begin with Troubleshooting Section A, and proceed consecutively through all the sections.
| Problem Descriptions |
Troubleshooting Sections |
| The user receives an error when trying to logon to the host through NFS but is able to log on fine from a Telnet connection. |
A, B, C, D, E, F, G, H |
| The user is unable to log on to the host using either NFS or Telnet. |
A, B |
| Users are unable to log on to the host using NFS. |
E, F, G, H, K |
| The NFS Logon menu choice is not available when users right mouse click on an NFS server through the Network Neighborhood or Find Computer. |
I |
| Users see one of the following errors when trying to map a drive: "An extended error has occurred," "Network name could not be found," "Share name could not be found - Error 67," or "The specified share directory cannot be found." |
J |
This section contains specific troubleshooting steps. See the table above to identify the troubleshooting sections that are relevant to your problem, or simply begin with Section A and proceed consecutively through all the sections.
The UNIX operating system is case sensitive. To verify that the case of the logon name and password are correct, make a Telnet connection to the host using a terminal emulator such as Reflection for Unix and OpenVMS. Log on to the host using the same UNIX account name that you are attempting to use for NFS authentication.
Verify that the username and password are valid on this host. Make a Telnet connection to the host using a terminal emulator such as Reflection for Unix and OpenVMS. Log on to the host using the same UNIX account name that you are attempting to use for NFS authentication.
By default, a Reflection NFS logon dialog box appears when Windows is started.
If NFS Password Caching was enabled during the deployment process, the server name, user name, and password are saved the first time you logon (with the password saved in encrypted format). Thereafter, NFS logon will occur automatically and silently at Windows startup.
You will be prompted for a new password at startup if the server name or user name is changed in Reflection NFS client properties, or if the password is no longer accepted by the NFS server.
If you do not log on at startup, you will be prompted for logon information when you attempt to connect to an NFS server. Note: It is recommended that you always log on at Windows startup.
The Reflection NFS Client allows multiple concurrent NFS logons for users who have several different NFS servers that do not have coordinated user IDs and group IDs. For information on using this feature, please see Technical Note 1847
Before attempting to establish NFS root authentication, verify that you are able to authenticate and access the host with a non-root user account.
To successfully authenticate to an NFS host as root (the UNIX super user account), the host must first be configured to allow root access through NFS. By default most hosts either change the user's NFS access permissions from root to anonymous, or block NFS root access entirely.
Most UNIX hosts require a -root switch be added to each line in the /etc/exports file that you want to configure for NFS root access. Refer to your host's Manual (Man) pages for information on configuring your specific host for NFS root access.
Note: Configuring a UNIX host to allow root access over NFS is a security concern and should be carefully considered.
To provide remote NFS access, the following server daemons must be running on the host using UDP networking: nfs (nfsd), portmapper, and mountd. For TCP support nfsd and mountd must also be available through both UDP and TCP. The TCP protocol is available when running Reflection NFS in Windows XP and Windows 2000. It provides more error checking than UDP, but also uses more Windows resources. If mountd is available over TCP Reflection NFS will use TCP for network browsing regardless of this setting.
Depending on the optional services you want to provide, you may also need to run other daemons on the host. Run the pcnfsd daemon to provide NFS authentication and printing support (only anonymous authentication is available without pcnfsd). Run the nlockmgr daemon to provide support for file locking and sharing.
If any of these daemons are not available, refer to your host's Manual (Man) pages for details on starting the daemons.
To verify that these daemons are present and running, open the NFS Utility. On the Services menu click Search for Server Daemons. Enter the host name or IP address of your host and click Retrieve Information. A green check indicates that the daemon is running.
For more information on NFS host side requirements, see Technical Note 1100.
Verify that the user's IP address and PC node name are in the host's /etc/hosts file. This is not necessary on all hosts, but is often required. Try adding the workstation information to the /etc/hosts file if you are unable to map NFS drives.
The /etc/hosts file is a text file and can be edited using a UNIX text editor such as VI. You do not need to re-export or compile the /etc/hosts file after editing.
Some versions of the pcnfsd daemon are not shadow password aware. This limitation is primarily seen in HPUX or Linux environments. If your host is configured for shadow passwords, and users are able to authenticate only as anonymous, then you may need to update your version of pcnfsd.
To determine if your host is configured for shadow passwords, use a terminal emulator such as Reflection for UNIX and OpenVMS to make a Telnet connection to the host. Using cat or a text editor such as vi, examine the host's /etc/passwd file for an asterisk (*), or other placeholder after the user name. The following example indicates that a shadow password is configured for user randyr:
randyr:*:224:32:Randy Rogers:/home/randyr:/bin/cshTo resolve the problem, contact your host vendor for the latest pcnfsd daemon or patch.
If you have multiple NFS hosts, try authenticating to the problem host from a second NFS host. If you are unable to access the problem NFS host from the second NFS host, then the problem host may not be configured properly for NFS client access.
If the NFS client is configured for NIS authentication, only one NFS logon is allowed. The user will be prompted to authenticate to the configured NIS server during Windows startup. No subsequent NFS logons will be possible.
Follow the steps below to determine if NIS authentication has been enabled for the NFS client.
Reflection NFS Client Version 12.0 or Higher:
Reflection NFS Client Version 11.x or Earlier:
Follow the steps below for your operating system.
WINDOWS XP:
WINDOWS 2000:
WINDOWS 98/ME/NT:
Windows associates each remote host name with one network transport type (NetID). Once this association is made, the host can be reached using only the specified transport type. If you have hosts configured to offer multiple transport types, such as NetBIOS and NFS, Windows will cache only one of these transport types with the host name. This situation can cause mapping, authentication, and browsing errors such as:
For further details on this issue, see Technical Note 1795.
The Reflection NFS client does not support HPUX NIS password aging.