NFS 3.0 and NFAU install and setup issues

-------------------------------------

Issue #1:

1.0 Symptoms

Error: "NFS Server: Root is not mapped to any user. Exiting..." (NFSSTART)

NFSSERV.NLM attempts to load, gives error: "Root is not mapped to any user."

1.1 Cause

Generally, if the current support packs for you products are in place, you will not run into this problem. However, the basic meaning of this messages is: Either no NetWare user object has a Unix ID (UID) of 0 (zero) in it's UNIX profile, or the one that does have the 0 UID cannot be found.

1.2 Solution

The best solution is simply to update to the current support pack, which will likely resolve the problem. The way NFS-related products functioned in regard to a "root user" (and in regard to a special user of its own) changed over time, so explaining it all quickly and concisely is difficult.

Basically, in the original NFS 3.0 product, the ADMIN user was assigned UID 0. If that assignment failed, this problem could occur. Or, the assignment might have worked, but the ADMIN user might not be in an area that the NFS product was searching. Or the search method might fail due to problems with a special user created for various NFS purposes, including searching the tree.

In later support packs, Novell abandoned the idea of assigning UID 0 to Admin, and instead assigned UID 0 to a special user called "NFAUuser". This user object performs many functions, only one of which is acting as UID 0. So the best approach is to be up-to-date on your support packs, then focus primarily on the NFAUUser, as having that user properly created and functioning is the biggest priority, and will do many things to insure your NFS product functions properly.

If we get a little more "nitty-gritty" than that, the newer, better approach with the "NFAUuser" is available with NFS 3.0 SP3 or above, or Native File Access for NetWare 5.1 SP1 or above, or NetWare 6.0 SP1 or above. If you are updated at least to those points, skip to section 1.2.3.

1.2.1 If you are using NFS 3.0 with SP2, SP1, or no support pack, shame on you. But in those cases, you can manually verify / assign UID 0 the Admin user. This is accomplished in ConsoleOne. First, identify or create a group object. In the "UNIX Profile" tab, set a GID for the group to match the UNIX root user's primary GID (determined on the UNIX host). Then in the properties of ADMIN (or equivalent), enter the UNIX Profile and set the UID to 0 (zero) and set the GID by browsing to the group that was just previously configured. Then try NFSSTART again.

NOTE: For those of you on the older product levels: The special user name was not always "NFAUuser". Unpatched Native File Access used "NISUser" instead of "NFAUuser". If NFS 3.0 SP2 or earlier is being used, there was a special user "NISUserDef", but typically ADMIN was given the UID 0 instead. If, subsequently, this document refers to NFAUuser, but you are using one of those older product levels, you may need to substitute the other appropriate name.

1.2.2 User with UID 0 exists, but Cannot Be Found by NFS

This section still applies only to those shameful people using NFS 3.0 SP2, SP1, or no support pack. It may be necessary to expand the area of the tree that is being searched for the root user. There are two ways to expand the areas of the tree that NFS searches for mapped users. Both have the same effect. One deals with a configuration file directly, the other goes through a graphical user interface.

(1) Edit the SYS:ETC/NFS.CFG file and set the "SEARCH_ROOT" parameter. List any appropriate containers to be searched. Use fully distinguished, typeful names, with leading dots. (I.E. .OU=provo.O=novell). It is not necessary to list sub-containers, just the top containers of whatever "branches" of the tree are to be searched.

(2) The SEARCH_ROOT setting is also available through ConsoleOne. After clicking on NFSAdmin and logging into the NetWare Service which runs NFS, right click on the server object that appears within the NFSAdmin section. Select PROPERTIES and then the DIRECTORIES tab. NDS should be selected and the search list populated using fully distinguished, typeful naming, with leading dots (i.e. .OU=PROVO.O=NOVELL). After setting this, do a NFSSTOP and NFSSTART and see if the error still occurs.

In some cases, early NFS 3.0 had trouble searching large containers. NFS 3.0 Support Pack 2 and newer contain a fix for this problem.

If the error still occurs when NFSSERV.NLM loads, verify the bindery context of the server. Edit the AUTOEXEC.NCF file. If it contains a command "set bindery context," check how it is set. If any of the contexts in the list include the Tree name, remove the tree name and the dot which separates it from the O level. For example, if the context is listed as .O=novell.novtree, change it to .O=novell (a helpful rule of thumb is that if there are any dots AFTER the "O=", then data after that dot is a treename). After changing the setting in AUTOEXEC.NCF, down the server and bring it back up. If the AUTOEXEC.NCF already had a bindery context set, and it hasn't been changed, then go to the server console and give the command CONFIG. (Not LOAD CONFIG). The last information displayed should be the bindery context. If it is not displayed, set it with the command "set bindery context=.container" where .container is replaced by the full context (with leading dot) that is used as the bindery context. If unsure of what container to use, use the one where the server object itself resides. Then NFSSTOP and NFSSTART and check for the error again.

It may be necessary to have a Read/Write replica placed on the NFS server. It should be of a partition containing the object with the UID 0. This is the NFAUUSER object, if your support pack is up-to-date.

In some cases, NFSSERV has been inexplicably unable to find the root user despite the above steps. It often helps to create the group and user for this mapping in the first bindery context of the server. Then try 2 alternative ways of setting the SEARCH_ROOT (whose location was described above):

(1) Set the SEARCH_ROOT to the first bindery context of the server.

(2) Rem out the SEARCH_ROOT parameter, which should cause it to default to the first bindery context. After either of these configuration methods, try NFSSTART again.

Continue to section 1.2.3.

1.2.3 In some cases, deleting and recreating the "special user" (usually NFAUuser) in NDS will eliminate the error.

There can be more than one instance of the NFAUuser in the tree. You must determine what location your server *wants* to find the user. The NFS product will initially search the first bindery context of the server, if one has been set. Second or third (and so on) bindery contexts will not be set. To check for a bindery context, go to the console prompt and type "CONFIG" (*not* LOAD CONFIG). The last few lines of information will be the tree name, followed by any bindery contexts which have been set.

If there is no bindery context set, then NFS will want to find the NFAUuser in the server object's own context.

Once you have identified the target context, see if there is a NFAUuser present. If not, skip to section 1.2.4. Otherwise, first delete the object and then proceed to 1.2.4.

NOTE: In one case, the NISUSERDEF object (a pre-cursor of NFAUuser) had been manually configured (inappropriately) to have its password expire, and this caused the 'root is not mapped' error. It may be possible to fix the expiration setting without resetting the password or deleting the user; but if all else fails, delete the user and recreate it.

1.2.4 NFAUuser Does Not Exist

If there simply is not any NFAUuser object:

Load SCHINST -N

(or, if you are on NFS 3.0 SP2 or earlier, leave off the -N)

When it prompts for credentials, use typeful, fully-distinguished syntax for the admin account. I.E.

.CN=ADMIN.O=NOVELL

Afterwards, check SYS:ETC\SCHINST.LOG and verify that NFAUUSER has been created. Also, unless you are still on NFS 3.0 SP2 or earlier, there should be a note that it has been designated as the UNIX Root user.

If the system has still failed to create NFAUUSER, or to set NFAUUSER as the UNIX Root user, proceed to Issue #2.

-------------------------------------

Issue #2

2.0 Symptoms

Error: "Could not add the object : .CN=NFAUUser.O=<org>"

NFAUUSER is not set as the UNIX Root user.

NFAUUSER is not created by SCHINST.

2.1 Cause

SCHINST may have failed to extend the schema so NFAUUSER could not be created.

2.2 Solution

Go into NWCONFIG, Directory Options, Extend Schema, and extend the schema specifying the path of:

SYS:SYSTEM\SCHEMA\UAM.SCH

Repeat the process for the following paths:

SYS:SYSTEM\SCHEMA\NIS.SCH

SYS:SYSTEM\SCHEMA\NISUPGD.SCH

If they have extended cleanly as verified in SYS:SYSTEM\DSMISC.LOG, run SCHINST again as in section 1.2.4 above. It should create NFAUUSER and set it as the UNIX Root user.

If these schema extensions fail (errors in DSMISC.LOG), see the eDirectory/Directory Services Health Check document at

https://support.microfocus.com/kb/doc.php?id=10060600

After verifying eDirectory/NDS health repeat the above schema extension steps.

Additional issues further below in this document may address some of the schema errors you may encounter.

Also, you may benefit by searching the knowledgebase for "NFS" and the particular attribute or class names mentioned in errors in the SYS:SYSTEM\DSMISC.LOG file.

If an Error 608 Illegal Attribute is encountered, see https://support.microfocus.com/kb/doc.php?id=10066338 and contact Novell eDirectory/Directory Services Support for assistance.

-------------------------------------

Issue #3

3.0 Symptoms

When NFSGY.NLM loads, an error occurs indicating version mismatch w/NSS.

Error: "NSS -2.93x-403: nssRegistration.c The module "Gateway" has an invalid version number of 2.95. It should be 2.93. Load the version displayed on the screen. Version mismatch between NFS Gateway and NSS, ensure you have the right version."

Error: "NSS -2.96x-403: nssRegistration.c The module "Gateway" has an invalid version number of 2.95. It should be 2.96. Load the version displayed on the screen. Version mismatch between NFS Gateway and NSS, ensure you have the right version."

Note: The version numbers mentioned in the above errors can vary depending on the NLM versions. See below regardless of the versions listed.

3.1 Cause

NFS Gateway is compiled with NSS headers, and the NSS headers must match the version of NSS running on the server. NFS 3.0 "red-box" product is compiled to expect NSS version 2.95.

3.2 Solution

For NetWare 5.0 with Support Pack 4 or below, or NetWare 5.1 without a Support Pack, apply NetWare 5 Support Pack 5 or NetWare 5.1 Support Pack 1, respectively. These Support Packs are the minimum required for the NFS 3.0 product.

For NetWare 5.0 SP6 or NetWare 5.1 SP2, download and apply NFS 3.0 Support Pack 1, which will (among other things) supply a NFSGY.NLM compiled to run with NSS version 2.96.

For all newer NW 5.1 Support Packs, the NFSGY compiled to run with the updated NSS will be present in the NFS Support Pack released simultaneously. For example, NW 5.1 SP3 and NFS 3 SP2 should be used together; NW 5.1 SP4 and NFS 3 SP3 should be used together; etc.

-------------------------------------

Issue #4:

4.0 Symptom

After install, and after issuing the NFSSTART command, an error occurs:

"Error: Could not get local host name."

4.1 Cause

The installation of NFS 3.0 neither creates nor edits the SYS:ETC\HOSTS file. If there is not already HOSTS file or DNS information for the server, the server will not be able to obtain the local host name.

4.2 Solution

Ensure that there is a valid entry in the server's SYS:ETC\HOSTS file, containing it's own IP address and host name. Adding information to the designated DNS server would help as well, but it is recommended to have this self-referencing information in the HOSTS file, in case DNS goes down.

-------------------------------------

Issue #5

5.0 Symptom

During the install, after entering the admin name and password, and setting the NIS Administrator password, the following errors occur:

Error: "Unable to create DClient context. Error code -663."

Error: "Getting the default context. Error Code -319."

5.1 Cause

[no information supplied]

5.2 Solution

Verify the bindery context of the server. Edit the AUTOEXEC.NCF file. If it contains a command "set bindery context," check how it is set. If any of the contexts in the list include the Tree name, remove the tree name and the dot which separates it from the O level. For example, if the context is listed as .O=novell.novtree, change it to .O=novell (a helpful rule of thumb is that if there are any dots AFTER the "O=", then data after that dot is a treename). If the tree name is removed from the setting in AUTOEXEC.NCF, down the server and bring it back up. If the AUTOEXEC.NCF had a bindery context set, and it was not necessary to change it, then go to the server console and give the command CONFIG. (Not LOAD CONFIG). The last information displayed should be the bindery context. If it is not displayed, set it with the command "set bindery context=.container" where .container is replaced by the full context (with leading dot) that is used as the bindery context. If unsure of which container to use, use the one where the server object itself resides.

-------------------------------------

Issue #6

6.0 Symptom

During install, the schema extension fails.

Error: "Failed to add schema attribute UNIX:UID. An error occurred modifying the NDS schema for file sys:system\schema\nds4s.sch. Error Description unknown error -708 (fffffd3c hex). (DSI-5.00-185)."

6.1 Cause

Possible problem in the existing NetWare schema.

Possibly, old versions of DS are in the tree. One occurrence of this issue was specifically seen in a tree where NetWare 4.10 servers running DS 5.18 were present.

6.2 Solution

Check / update the DS versions throughout the tree, then load SCHINST.NLM to repeat the Schema setup portion of the NFS install. If problems still occur, run DSREPAIR --> ADVANCED OPTIONS --> GLOBAL SCHEMA OPERATIONS --> POST NETWARE 5 SCHEMA UPDATE. Also run OPTIONAL SCHEMA UPDATES from the same menu location. Then try SCHINST again.

-------------------------------------

Issue #7

7.0 Symptom

Shortly after the install begins, an error occurs saying that the SP.DB file is not found.

7.1 Cause

The NFS 3.0 files are from a pre-shipment download from Novell which was not built correctly.

7.2 Solution

Obtain official product through normal purchase channels.

-------------------------------------

Issue #8

8.0 Symptom

During install, the schema extension fails, saying that the same extensions already exist with different attributes.

8.1 Cause

The Tree contains slightly different schema extensions from an NFS 3.0 beta product or out-of-date version of NDS for Solaris.

8.2 Solution

Use Schema Manager to remove prior extensions, or seek assistance from Novell Technical Services.

See also KB 10057851.