Environment
Novell NetWare 6.5 SP7
Novell NFS Gateway for NetWare 6.5
Situation
The NetWare Server has been installed using the SP7 overlay or SP8 overlay install.
When GYMOUNT is used to mount an NFS Gateway volume, the following error is displayed on the logger screen: GYMOUNT: Error 109: Unable to login to eDirectory.
Volume objects for the NFS Gateway volumes are not getting created in eDirectory.
Resolution
The install of NetWare 6.5 from a SP7 of SP8 overlay has two new effects:
(1) eDirectory 8.8.x is installed. In the past, 8.7.x has been installed with NetWare 6.5.
(2) The STARTUP.NCF is created with the setting: env NDSD_TRY_NMASLOGIN_FIRST=true
These 2 factors together mean that when GYMOUNT attempts to login to eDir as the NFAUUser, the login is passing through a different method than it did previously. The new method is having a problem with the way the password for NFAUUser was created.
Short-Term Solution:
Remark out the above env setting in STARTUP.NCF and reboot. That will allow GYMOUNT to login through the previous method, and it will be successful again.
Long-Term Solution:
The way the NFAUUser password is auto-generated has been corrected. The fix is in a new SCHINST.NLM, released in NetWare 6.5 SP8.
Note that the fix will not cause existing NFAUUsers' passwords to be corrected. It will only correct the generation of new passwords. For existing servers / NFAUUsers where this is occurring, the following steps will be needed, after SP8 installed and the system rebooted:
1. Identify the NFAUUser object which the effected server is using. There may be more than one of these user objects in a tree. To determine the object which this server is using, verify two factors:
- Check the sys:etc\nfs.cfg file. Go to the end. "NIS_ADMIN_OBJECT_CONTEXT" should show the container where the NFAUUser for this server resides.
- Check the connection table in MONITOR.NLM. Sort the connections by name, and location the NFAUUser, and check the context listed. Note that the NFAUUser will only be logged in if NDSILIB.NLM is loaded. And if you've located the correct NFAUUser in the connections list, it should come and go when NDSILIB is loaded or unloaded.
If both these items are in agreement, the correct NFAUUser object has been identified. If these items are not in agreement, then it is likely that the nfs.cfg was not properly up to date. Trust the MONITOR information, so long as you've verified it by unloading / loading NDSILIB and seeing it's effect in the MONITOR connection list. Nfs.cfg will be automatically updated as you continue with these steps.
2. Identify other servers in the tree which are using that same NFAUUser object. Typically, other servers are likely to be using the same object if either their first bindery context matches the location identified in step 1, or if the NCP Server object's context matches that context. But when in doubt, use MONITOR and the test of loading / unloading NDSILIB to be certain.
3. Delete the NFAUUser object identified in step #1.
4. On an SP8 server which was using that NFAUUser object, go to the server console and execute SCHINST -N (see step #5 for details)
5. Follow the prompts. Be sure to use the FDN of a true administrator, including a leading dot. I.E.: .admin.novell
6. After the SCHINST.NLM process completes successfully, either reboot the system or use the following steps to get NDSILIB unloaded / reloaded. Note that these steps will stop and start FTP Server, NFS Gateway, and NFS Server. Also note that in a cluster, the needed steps may be different. Due to many possible variations on a cluster, it is best to migrate resources off the nodes and reboot them one at at time.
- unload nwftpd
- gystop
- nfsstop
- unload ndsilib (it is likely already unloaded by this point, but do this to be certain)
- (optional) load ndsilib by itself and check the logger screen for errors. Any errors about context handles, logging in, or running schinst again mean something didn't go right in the previous steps.
- nfsstart (if NFS Server is needed on this system)
- gystart
- ftpstart (if FTP Server is needed on this system)
7. For any other server which was sharing the same NFAUUser, perform steps 4 - 6 on those servers as well. This will be necessary even if none of those other servers were seeing the 109 error. This is because other servers which share an NFAUUser must learn about it again, if it has been re-created. It is not necessary to have a copy of the new SCHINST.NLM on the other servers, as it's only the server which first *creates* a new NFAUUser that must have the fix. But for consistency moving forward, it's best to put that NLM (or SP8) on each server, so any server will be equally up-to-date in it's method of creating an NFAUUser object.