• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 10680
  • Last Modified:

Mapped drives do not appear


I have a Novell server which I have created a script on the top level tree. Here is the script:

Map Display Off
Map Errors On

Map F:=SYS:\
Map Root G:=SYS:\Programs
Map Root H:=SYS:\Data
Map Root U:=SYS:\Users\%CN

This applies to anyone who logs into the novell server. I am having a problem on client workstations which have XP with the novell client. When I click the red N in the task bar and click "Novell Login..." to change to the admin account. My mapped drives from the script do not appear in explorer. When I change back to a normal user the drives appear again. This problem comes and goes and is really annoying. Here is the eror which is received.

LOGIN-LGNWNT32.DLL-430: The following drive mapping operation could not be completed.
The error code was 8804.
LOGIN-LGNWNT32.DLL-440: The operation was attempted on an invalid drive.
LOGIN-LGNWNT32.DLL-430: The following drive mapping operation could not be completed.
The error code was 8901.
LOGIN-LGNWNT32.DLL-430: The following drive mapping operation could not be completed.
The error code was 8901.
Drives A,C,D,G,I map to a local disk.

Can anyone help me with solving this issue.

Thank you
2 Solutions
<pet peeve>

No such thing as a "Novell server". There is a company named "Novell", and it makes a number of products, including "NetWare". There is such as thing as a "NetWare server".

</pet peeve>

I suspect your "admin" user account is in a different eDirectory context than your "normal" user account. Container Login scripts are applied to all accounts in the OU (context) - they do not apply to accounts elsewhere in the eDirectory Tree. Understand, unlike AD, eDirectory is an actual 3-D, hierarchical database. AD is just a 3-D view of same flat namespace of NT Domains.

Creating a Container Login Script for the top-level O does not apply it to all OUs beneath it. Unless it is specifically referenced in an OU's Container Login Script, a "higher" Container Login Script is not used for logins under accounts in a given container.
amerretzAuthor Commented:
All my accounts including the admin account are contained within the context. The login scipt has also been applied to the context properties.

amerretzAuthor Commented:
Sorry not context... Organisation Object
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Err, what's your server name? Even if you only have the 1 server in your tree it won't automatically know which server a login script refers to. Appears as if you're trying to map several subdirectories of the SYS volume without specifying which server...

Correct map format is:
MAP ROOT LETTER:=ServerName/Volume:Directory

So for example,
Map Root U:=YourServer/SYS:Users/%CN

Incidentily, it's better practice to leave the sys volume alone and store your data on a different volume.

Actually, the correct map format is
MAP ROOT <letter>:= .volume_object.ou.org:<path>


The server/volume: notation is not recommended for eDirectory-based versions.  It's a holdover from bindery-based that still works...

However, not specifying the server and only specifying the volume >will< work, consistently - as long as that volume & path is on your primary directory server (the one with an asterisk when you display NetWare Connections), which is the one that gets mapped if you don't specify a server.  Useful in roaming situations but can confuse things, which is why using the volume object map syntax is the one recommended by Novell.

Are you using a Container login script or are you using a Profile login script?  It's easier in a simple setup to use a Profile login script and specify it in the Login Script tab of the user object, IMHO.

I must say this: you have a big problem.  You have user data on SYS:  As PsiCop said, don't do that.

You should plan to add a user-data NSS pool and volume, separate from SYS: pool and volume, and move all of your user data off SYS:
Note that this kind of thing can also happen if (and like user data on SYS: this is NOT "best practices") you have your tree name the same as your ORG name or your server is the same name as the tree name.

In other words, never have tree 'mycompany' with ORG named 'mycompany' and a server in that tree named 'mycompany.'

Nothing will stop you from doing that, but if you do, it causes  all sorts of freaky issues.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now