Mapped drives do not appear

Posted on 2006-05-06
Last Modified: 2012-08-14

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
Question by:amerretz
    LVL 34

    Accepted Solution

    <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.

    Author Comment

    All my accounts including the admin account are contained within the context. The login scipt has also been applied to the context properties.


    Author Comment

    Sorry not context... Organisation Object
    LVL 19

    Expert Comment

    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.

    LVL 35

    Assisted Solution

    Actually, the correct map format is
    MAP ROOT <letter>:=<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:
    LVL 35

    Expert Comment

    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.

    Featured Post

    Why You Should Analyze Threat Actor TTPs

    After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

    Join & Write a Comment

    I've been asked to discuss some of the UX activities that I'm using with my team. Here I will share some details about how we approach UX projects.
    ADCs have gained traction within the last decade, largely due to increased demand for legacy load balancing appliances to handle more advanced application delivery requirements and improve application performance.
    In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…
    Illustrator's Shape Builder tool will let you combine shapes visually and interactively. This video shows the Mac version, but the tool works the same way in Windows. To follow along with this video, you can draw your own shapes or download the file…

    729 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    15 Experts available now in Live!

    Get 1:1 Help Now