From: Dylan Penhale <dylanpenhale@(email surpressed)>
Subject: Mapping drives
   Date: Wed, 08 Feb 2006 18:08:11 -0500

This is really starting to hurt my brain.

Our submit script checks all XP machines have a set of drives mapped. If the
drives are unavailable or not there then it maps them. In the script we also
output the command "net use" so we can see what is mapped.

However, sometimes when the mapped drives are unavailable the script can't
remap them. Because they are being mapped persistently the script is unable
to map them as net use needs user input, [Y/N] I expect. I say expect
because when we log into the user account that is running rush and run net
use there are no mapped drives shown. How can this be? What user are these
drives being mapped as? All WIN users are forced to use the same UID/GID as
the user running rush on the render nodes. We even spit out the %USERNAME%
and it matches.

Where does rush map these drives? I'm thinking of having to delete all
mapped drives and remap them at the start of each frame just to have fail
safe maps. Many users are now using UNC paths but some old scripts still use
mapped drives so we still need to keep them.

Thanks in advance.

 

Dylan Penhale wrote:

Our submit script checks all XP machines have a set of drives mapped. If the
drives are unavailable or not there then it maps them. In the script we also
output the command "net use" so we can see what is mapped.

However, sometimes when the mapped drives are unavailable the script can't
remap them.

	Then go into a 'retry loop', repeating the map operation until it
	succeeds (with a 'sleep(10);' in between..).

	After some number of retries considered 'too long to wait', you
	could either requeue the frame, or fail it.

Where does rush map these drives?

	Rush does NOT map drives, ever.
       [UPDATE 07/18/2014: Actually in Rush 103.x, the new rush/etc/path_convert file ]
       [can be used to have Rush create drive mappings. This was not the case in 2006 ]
       [when this article was written.                                                ]

	Someone likely tweaked the submit scripts to include a 'net use x: \\some\path'
	commands into the script before the renderer is invoked.

	So look in the submit script, in the 'if ( $ARGV[0] eq "-render" )' section
	of the code.

	The best way to include net use commands into a submit script is to bracket
	the 'net use' command with an if() or while() statement to test if the drive
	is already mapped, eg:

# DRIVE MAP CHECK
if ( ! -d "x:/" )
{
   {
       my $cmd = 'net use x: /delete < nul';
       print "X: NOT MAPPED.. FORCING UNMAP FIRST '".$cmd."'\n";
       system($cmd);
   }
   {
       my $cmd = "net use x: \\\\mayaserver\\jobs /persistent:yes < nul";
       print "REMAPPING USING '".$cmd."'\n";
       system($cmd);
   }
   # system("dir x:");			# debugging
}

	The '< nul' will at least get you past the 'Y/N' prompt,
	which one apparently can't disable, according to 'net use /?'.

This is really starting to hurt my brain.

	Don't say I didn't warn you ;)
	http://www.seriss.com/rush-current/rush/rush-td-faq.html#TDFAQ-UNC

       [UPDATE 07/18/14: While the issues cited in the above link are    ]
       [still relevant, many customers seem to reliably run OK with      ]
       [drive maps enabled with code like the above in the render script ]
       [to force them to be enabled.                                     ]

I'm thinking of having to delete all
mapped drives and remap them at the start of each frame just to have fail
safe maps.

	Do you have some of the errors you're getting back from the OS
	regarding the failed drive map commands?

	That would help, as often one can search for the OS error on
	support.microsoft.com's knowledgebase, and find solutions or
       at very least causes.

	Look at the event log on your server too for errors; possibly the server
	has run out of SMB licenses; some file servers, such as Windows based file
	servers, license each drive map connection, and will deny connections if
	there are 'more than you're licensed to use'.

Many users are now using UNC paths but some old scripts still use
mapped drives so we still need to keep them.

	See if you can identify why the old scripts 'need' drive maps,
	and try to rework them to use UNC.

	One of the very few reasons I've found I 'need' drive maps is when
	I'm in a DOS shell, and want to 'cd' to a network drive;
	one can't 'cd' to UNC paths; DOS is old and crappy, and has legacy ties
	to the concept of drive letters internally, to support old 16bit apps.

	Regular shells (like tcsh, sh, perl, python) have no problems with this,
	only DOS.

	So unless you're somehow dependent on DOS batch scripts that need to 'chdir'
	to drive maps, you should be able to get away from drive letters. I'd be
	curious to hear if there are other reasons that might be stuck with drive
	letters (besides the fact that drive letters 'might' be in the scene files)

[UPDATE 08/16/07: the drive map example was modified 08/16/07 to include ]
[the /delete flag which ensures a 'disabled connection' is deleted and   ]
[then recreated.]

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

|
|> Where does rush map these drives?
|
|	Rush does NOT map drives, ever.
|

Sorry, I should have been more clear. Our rush submit scripts have been
modified to map drives but my question is which user are they be mapped as?
I assumed they would be mapped as either the domain user that is running
rushd or as the user that is submitting the job (in our case both are the
same). However when we log in as that domain user net use shows no drives
are mapped while net use run from the submit script shows there are many. 

|
|> This is really starting to hurt my brain.
|
|	Don't say I didn't warn you ;)
|	
|http://www.seriss.com/rush-current/rush/rush-td-faq.html#TDFAQ-UNC

I know :)

Dylan Penhale wrote:

[posted to rush.general]
|
|> Where does rush map these drives?
|
|	Rush does NOT map drives, ever.
|

Sorry, I should have been more clear. Our rush submit scripts have been
modified to map drives but my question is which user are they be mapped as?

	As the user the render is running as.

	When you look in the log file for the render, see the "RunningAs:"
	prompt to see which username the map is assigned to, ie:

###
### geneva.1: 0003
###
--------------- Rush 102.42a2 --------------
--      Host: geneva
--       Pid: 2140
--     Title: TEST
--     Jobid: geneva.1
--     Frame: 0003
--     Tries: 1
--     Owner: 3d (1004/1004)
-- RunningAs: render             <---
-- [..]

	..in this case, as the user 'render'.


	Note that, under windows, Rush runs renders as the user the rushd
	service is configured to 'Log On As' (in the services panel).
	Rush can't 'become' the submitting user the way it can in unix,
	due to limitations in the WIN32 API. (see below)

I assumed they would be mapped as either the domain user that is running
rushd or as the user that is submitting the job (in our case both are the
same).

	Not in the case of windows.

	This is because Windows has no mechanism similar to Unix's setuid();
	there's no way for rush to 'become a user' without having that user's
	password. In Unix, 'root' can become anyone without needing a password.

	Hope that clears things up.


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

|
|> I assumed they would be mapped as either the domain user that is 
|> running rushd or as the user that is submitting the job (in our case 
|> both are the same).
|
|	Not in the case of windows.
|
|	This is because Windows has no mechanism similar to 
|Unix's setuid();
|	there's no way for rush to 'become a user' without 
|having that user's
|	password. In Unix, 'root' can become anyone without 
|needing a password.
|
|	Hope that clears things up.

Sort of :) I understand that there isn't the handing over of user privileges
to other users on windows, I just wanted to know under which account the
drives are being mapped.  Know rush says they are being mapped as netrender
(in our case) but I have logged in as that user and there are no mapped
drives in that account. Logging in as local administrator and also domain
admin doesn't show them either. It's just got me puzzled, and it's not a big
deal, we have just set the script to delete them and remap them when it
finds a stale/broken map which is working fine.

Dylan

Dylan Penhale wrote:

Sort of :) I understand that there isn't the handing over of user privileges
to other users on windows, I just wanted to know under which account the
drives are being mapped.  Know rush says they are being mapped as netrender
(in our case) but I have logged in as that user and there are no mapped
drives in that account.

	Hmm, I'm not sure 'net use' is showing us mapped drives for "all" users.
	I think maybe it only shows the mapped drives for the 'current user'.

	For instance, I'm logged into to my windows machine as 'erco',
	and have the Z: drive mapped.

	Then, if I telnet into the same machine as a different user, say
	"administrator", and map drive X:, then type 'net use', I only see
	the X: map.

	And from the 'erco' windows, 'net use' only shows the Z: map.

	Funny thing is, erco can do a 'dir z:' and 'dir x:' and both work.
	(my samba server is configured to be /very/ open)

	But 'net use x:' only works for 'administrator', and 'net use z:'
	only works for erco..!

	So 'net use' seems locked to only show information for the logged in
	user, and doesn't not give a complete picture (ie. all users).
	Life with Windows, I guess.

Greg Ercolano wrote:

Hmm, I'm not sure 'net use' is showing us mapped drives for "all" users. I think maybe it only shows the mapped drives for the 'current user'.

	I decided this is pretty weird, so I posted a question on
	microsoft.public.win32.programmer.networks , just to see if there's
	an alternative command.

	If anything comes up as being useful, I'll follow up here.
	Or if you folks know the answer, feel free to enlighten us ;)

- - -

From: Greg Ercolano <erco@(email surpressed)>
Newsgroups: microsoft.public.win32.programmer.networks
Subject: How to list all drive maps? ('net use' only shows *current user's* maps)
Message-ID: <tsdIf.66$OP5.7@fe03.lga>
Date: Mon, 13 Feb 2006 20:59:04 -0800

I noticed that 'net use' doesn't show *all* the drive maps,
it only shows maps created by the current user.

In a multiuser context, this is bad, because one can't 'see' what
drive maps are currently in use by other accounts.

For instance, under Win2K say 'fred' is logged into a workstation,
and he creates a drive map for Z:

Then 'jack' telnet's into the same workstation's Win2K Telnet Server,
and creates a drive map for 'X:'.

If jack types 'net use', he only sees his X: map.
If fred types 'net use', he only sees his Z: map.

Both users can access both drive maps (eg. with 'dir X:'),
but the 'net use' command isn't showing the maps owned by
the other user.

There must surely be a way to see *all* the maps.
Is there a command to show this?

- - -

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

Greg Ercolano wrote:

Greg Ercolano wrote:

Hmm, I'm not sure 'net use' is showing us mapped drives for "all" users. I think maybe it only shows the mapped drives for the 'current user'.

    I decided this is pretty weird, so I posted a question on
    microsoft.public.win32.programmer.networks , just to see if there's
    an alternative command.

	Two replies so far.

	No DOS commands, but..

# 1
------------------------------------------------------------------------
Look at http://support.microsoft.com/default.aspx?scid=kb;en-us;Q180362
for details ( each user has it's own set )
Arkady


# 2
------------------------------------------------------------------------
Most likely GetLogicalDriveStrings + GetDriveType will help you.
-- Vladimir


	#1 tells us what we already seem to know; avoid drive letters
	because they aren't well implemented for multiuser environments.
	Though I'm actually impressed/sickened to see that in writing from Microsoft.

	#2 refers to some C++ WIN32 calls (which also appear to be available
	from ActiveState perl.) I wrote a small test program using these two calls,
	and sure enough it shows the drive letter allocations to both users:

#include <stdio.h>
#include <windows.h>
#include <memory.h>
// Show all drive maps
int main() {
    char s[4096];
    char *ss = s;
    memset(s,0,sizeof(s));
    if ( GetLogicalDriveStrings(sizeof(s)-1, s) == 0 ) {
	fprintf(stderr, "GetLogicalDriveStrings() failed: %d\n", GetLastError());
	return(1);
    }
    while ( *ss )
    {
        char uncpath[4096];
        memset(uncpath, 0, sizeof(uncpath));
        char drivename[10];
        sprintf(drivename, "%.2s", ss);
        if ( QueryDosDevice(drivename, uncpath, sizeof(uncpath)-1) == 0 ) {
	    fprintf(stderr, "QueryDosDevice(%s) failed: %d\n", drivename, GetLastError());
	    continue;
        }
        fprintf(stderr, "%s -- %s\n", drivename, uncpath);
        ss += strlen(s) + 1;
    }
    return(0);
}

	..here's the output of that program when I run it on my system:

C: -- \Device\HarddiskVolume1
D: -- \Device\CdRom0
E: -- \Device\Harddisk1\DP(1)0-0+6
F: -- \Device\Harddisk2\DP(1)0-0+7
G: -- \Device\Harddisk3\DP(1)0-0+8
H: -- \Device\Harddisk4\DP(1)0-0+9
X: -- \Device\LanmanRedirector\;X:0\meade\vartmp
Z: -- \Device\LanmanRedirector\;Z:0\meade\net

	..it does indeed show both the X: and Z: drives,
	X: mapped to \\meade\vartmp (created by a telnet user)
	Z: mapped to \\meade\net (created by the interactive user).

	I'm not sure what the E through H are about -- I only have one
	hard disk on this system.

	Also not sure what the '0' prefix is on all the UNC paths to \meade.
	I guess you're supposed to replace the '0' with a '\', or something.

|#include <stdio.h>
|#include <windows.h>
|#include <memory.h>
|// Show all drive maps
|int main() {
|     char s[4096];
|     char *ss = s;
|     memset(s,0,sizeof(s));
|     if ( GetLogicalDriveStrings(sizeof(s)-1, s) == 0 ) {
|	fprintf(stderr, "GetLogicalDriveStrings() failed: 
|%d\n", GetLastError());
|	return(1);
|     }
|     while ( *ss )
|     {
|         char uncpath[4096];
|         memset(uncpath, 0, sizeof(uncpath));
|         char drivename[10];
|         sprintf(drivename, "%.2s", ss);
|         if ( QueryDosDevice(drivename, uncpath, 
|sizeof(uncpath)-1) == 0 ) {
|	    fprintf(stderr, "QueryDosDevice(%s) failed: %d\n", 
|drivename, GetLastError());
|	    continue;
|         }
|         fprintf(stderr, "%s -- %s\n", drivename, uncpath);
|         ss += strlen(s) + 1;
|     }
|     return(0);
|}
|
|	..here's the output of that program when I run it on my system:
|
|C: -- \Device\HarddiskVolume1
|D: -- \Device\CdRom0
|E: -- \Device\Harddisk1\DP(1)0-0+6
|F: -- \Device\Harddisk2\DP(1)0-0+7
|G: -- \Device\Harddisk3\DP(1)0-0+8
|H: -- \Device\Harddisk4\DP(1)0-0+9
|X: -- \Device\LanmanRedirector\;X:0\meade\vartmp
|Z: -- \Device\LanmanRedirector\;Z:0\meade\net

|

This is certainly useful to know. Shame it can't be run from the command
line, but now I feel slightly better in knowing I wasn't going insane. 

Thanks for your help.

Dylan