Highlighted
Regular Contributor.
Regular Contributor.
162 views

ERROR mapping NSS Volume, LOGIN-LGNWNT32-400

Jump to solution

Hello,

My headache with the NCP/NSS continue. We have an off-site server running SLES 11 SP4. The purpose of this machine is to be used as a local file server for the people working in the office.

Installed on it is eDirectory, NSS and all packages that follow those. The server i registered to the main directory tree. Everything was running nice and smoothly. Recently, due to changes of the office, it became necessary  to encrypt the NSS Volume. I deleted the volume, re-created with encryption and copied back the files from backup. This is when the problems started. 

In the eDirectory there is an object "Directory Map" pointing to the above NSS Volume. This object was used for the logging scripts of the users. Recently it became impossible to map that drive. The error in OES Client is: LOGIN-LGNWNT32-400: A network drive cannot be mapped to a drive that is designated as a local drive.

The strangest thing is that if I try to browse to that directory, through Windows Explorer, I have no problem opening it and accessing the files. Even if I copy the path, which I try to map, and paste in in Win + R ( Windows Run) It navigates to the directory without a problem.

I tried deleting and recreating the "Directory Map" object, recreated the volume objects from "nssmu", tried all the thing that different TIDs suggested. No results. Logging scripts are fine, haven't touch them and they used to work. NDSrepair -U did not return any address errors or anything except some unused objects that it cleaned. Manuel mapping results in an error that says that the network path could not be found.

As a workaround I have changed the Logging Scripts to point directly to the volume object and this works. My fear is that this problem may cause other issues, however. Or that there is something worse hiding down the road.

Any and all suggestions on how to proceed with troubleshooting this will be helpful. NDSD,NCP2NSS,NAMCD all work fine, I even rebooted the machine. I only find the occasional odd error in /var/log/messages but haven't found anything concrete.

Thanks in advance, 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Knowledge Partner
Knowledge Partner

No. This is NOT related to filesystem rights but rather to NDS rights.

Start by granting one of the affected users "browse" entry rights and "read, compare" rights to "all attributes" of the directory map object.

 

If you like it: like it.

View solution in original post

4 Replies
Highlighted
Knowledge Partner
Knowledge Partner

Well, upon deletion of the original volume the map object became invalid, of course. This is expected as the volume object's EID did change. Assuming that it's valid now the easiest way to find out what's actually going on would be to grab a trace from an affected WS. It could e.g. be a rights issue (i.e. missing rights to resolve the attributes of the referenced objects). Which client OS and client versions are involved? Does it behave differently if you login as a tree admin?

If you like it: like it.
0 Likes
Highlighted
Regular Contributor.
Regular Contributor.

The map object was deleted and created again after the deletion of the volume, new rights were given out to the users. As far as I can tell the rights work as intended because people are able to work normally as long as I use the nss volume object to map it in a login script. 

I even created a fresh directory map object in a different "OU", the rights were transferred but users can not access it either.

Client for Open Enterprise Server 2 SP4 (IR11) is what is being used.

This morning I found out that the tree administrator has NO  issues whatsoever. This is interesting, maybe there is something wrong with the trustees database ? Could I simply remove the trustee xml files from the NSS Volume and create it ?

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

No. This is NOT related to filesystem rights but rather to NDS rights.

Start by granting one of the affected users "browse" entry rights and "read, compare" rights to "all attributes" of the directory map object.

 

If you like it: like it.

View solution in original post

Highlighted
Regular Contributor.
Regular Contributor.

Success !

Granting NDS rights to the object did fix the issue, I am able to map the drives properly now.

However, it only worked when I explicitly added an user object. For some reason it did not work with the existing Group, of which the affected users are members. I triple  checked the rights of the Group and they were as you listed:  "browse" entry rights and "read, compare" rights to "all attributes".

Only after recreating the Group did everything start working as before. Shame on me for not troubleshooting the NDS rights earlier.

As always You were of immense help, thank you for the assistance!

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.