views:

82

answers:

1

(There are other questions along these lines but none of them have any real answers, let alone answers dealing with python...)

I have a Windows Service (XP SP3) written in Python that needs to be able to mount a network drive for ALL users. I tried using net use with subprocess (even with the full path to net.exe), but given that your service runs as the SYSTEM user, net is pretty unhappy with you (it complains about the lack of a user context). There's probably a way to do this via WMI, but I haven't been able to figure it out.

EDIT: Actually, maybe you can't do this with WMI. This article seems to indicate that this functionality is available in WSH but not WMI. Maybe some way to use net or map to do this after all?

+1  A: 

Er... sadly, the short answer is no. If the Python program is running as a Windows service, there are multiple complications here... so let me explain.

First, in order to even allow the service program itself to access the network, it'll have to be running under a user account that is allowed network access. The SYSTEM account is out (all network access is forbidden), but you could use the "NETWORK SERVICE" account (which, in a domain environment, is really the machine's domain account), or another actual user account.

But you're not going to be able to map a drive in the service account, because it is not loading the user profile stuff that includes the ability to "map" to a drive letter. (Well, technically, if the service is running a CMD batch file, that script can map a drive letter and use it, but then it will not be persistent for the next logon... but nevermind that.) Instead, anything the program wants to get on the network should be accessed via the UNC paths (like \SERVERNAME\SHARENAME).

Lastly, it is not possible to make a drive mapping work "for all users"--a mapped drive is unique to each user profile (even if it uses the same letter to point to the same server share). If you have multiple users logged into a machine (for example, on a Terminal Server, or with a user and a service running under another user account), they cannot share the mapped drive--each must get his own.

However, you can do something like this: Make a login script (or Group Policy, etc.) that maps the drive with the expected letter (let's say "M:" for example) to the server share (\server\share). If this script runs for every user upon login, they'll all have the same mapping. Then when your program-running-as-a-service needs to access that share, it'll have to use UNC paths (and a user account with appropriate privileges, of course).

Hope that helps!

ewall
Clearly SYSTEM isn't totally disallowed network access - I've been able to use WNetAddConnection2 to make a connection to a remote server and use that connection to copy files - I just can't manipulate the user environment to map a drive.
Nick Bastin
Also, using a login script is a pretty good idea...that may work for me. :-)
Nick Bastin
It's surprising that the SYSTEM account was allowing some outbound connections... It's not *supposed* to, at least. So much for Micro$oft's security sandboxes!
ewall
Yeah, looks like SYSTEM really wasn't allowing connections - I'd already flipped to running it as Administrator to test if I could mount the drives that way.
Nick Bastin