I have recently installed a handful of OES2SP1 servers that will function primarily as file servers. The file system will be NSS and end user access will be via mapped drives delivered by the latest Novell Client on Windows XP workstations.

During the OES install, I simply accept the defaults for the LUM portion of the configuration and everything installs normally.

What I'm noticing now is that everytime a user accesses the NSS filesystem, I show the following in /var/log/messages:

Aug 27 10:19:09 RHS-LS01 kernel: Couldn't get FDN from LUM for uid=3318, rc=2

The users are able to access their data normally. The uid's displayed are legitimate users. I have been told and read that LUM/namcd are totally unnecessary for the access I described above.

One detail that may be relevant to the error above is that the uid's referenced are from LUM-enabled users. However, the group that provides their lum-enabling is not enabled for THAT SERVER. IE, the unix workstation object is not in that group's list of unix workstation objects. Long story there.

But that is really neither here or there. What I would really like to do is "un-lum-enable" every end user in our tree and stop any form of namcd caching or FDN lookup during NSS filesystem access.

-Is this practical/advisable?
-Is there any performance/system resource benefit to doing this?
-How do you "un-lum-enable" lum-enabled groups?
-Would this have any effect on NSS files system access via the Novell Client, or ability to use the local eDir replica for auth?
-Any recommendations for nam.conf settings pertinent to these ideas?
-Is AFP access dependent on LUM should I choose to implement AFP?