Unavailable network drives in CGI scripts

[Sprad]

I'm having problems accessing Windows network drives by drive letter in my CGI scripts. Here's a short script that illustrates the problem:

use CGI qw/:standard/;
print header();
print `net use`;
print `dir w:`; # where W is mapped to \\computername\sharename
print `dir \\\\computername\\sharename`;

The 'net use' gives me the expected list of attached shares, with the correct drive letters, but each one is marked "Unavailable".

The 'dir w:' command gives me "The system cannot find the path specified."

The 'dir \\\\computername\\sharename' gives me the correct directory listing for that share.

If I run the same code from the command line, the drive letters behave as I want, and I get the correct directory listing for both of the 'dir' commands.

Why is it behaving differently when I run it as a CGI script, and is there any way I can get it to access those drives by letter?

Edit: This is running under IIS 5.1.

[tye]

Windows has more security contexts than just which user the script is run under. The CGI script likely doesn't have access to the desktop (can't open windows on the desktop) and I'm not surprised that it doesn't have access to mappings to network drives that were created from the desktop. It appears you can access the network drive (which isn't always possible from CGI scripts), so you could also just map the network drive.

It may also be the case that a drive mapped by one CGI script will be visible to other runs of CGI scripts, so you'd only have to map it once. Try it and see. Just map the drive if you find it isn't mapped.

[Sprad]

Yes, this seems to have fixed it. I ran a net use with the same drive letter, same network path, and now I can see the drive both from CGI scripts and from the command line.

Thanks!

[JediWizard]

Without knowing what web server you are using, or how it is being run, I can't say for sure what the problem is. That being said, my first guess would be that you are having a permissions issue. CGI scripts are generally run as a different user for security reasons, and only given access to a sub set of available resources. The user under which the script is being run when used as a CGI simply may not have read permission on the mount in question.

[Sprad]

This is running under IIS 5.1. I added two more lines:

print `whoami`;
print $ENV{USERNAME};

'whoami' returned my username (not a web account), but the USERNAME environment variable was empty.

[JediWizard]

Try adding something like this:

if(-d 'w:\'){
 print "w:\\ is a directory\n";
 if(-R 'w:\'){
   print "w:\\ is readable\n";
 }else{
   print "w:\\ is not readbable\n";
 }
}else{
 print "w:\\ is not a directory\n";
}

[NetWallah]

Your CGI script is probably running under the localsystem or another account local to the Web server.

This account has priviledges on the local system, but NOT on the network. It does not allow you to use mapped drives or other networked resources.

Since you did not specify IIS, Apache, or other web server, I cannot advise on how to configure the CGI context. There are Win32 system calls that your CGI script can make, to impersonate different user identity. You can also make Win32 calls to get the network information, without running a separate command process, as you are trying to do.

[ikegami]

It does not allow you to use mapped drives or other networked resources.

Then how do you explain the OP's ability to execute dir \\\\computername\\sharename successfully?

[ikegami]

I've noticed the same thing in an interactive sessions (i.e. not under a web server).

I think it happens after the network mappings get disconnected after a period of time to conserve resources (but the mappings are not deleted). After that (or something else?) happens, accessing the drive letter from the console (e.g. dir w:) does not restore the connection and fails.

The connection can be re-established by accessing the drive letter through the GUI. After doing that, dir w: works again. I don't know of any programmatic alternative.