Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm trying to access some remote files from a web application server. Let's call them servers M and R. Both are running Windows Server (2008 and 2003).

The remote files are on server R on a file share that is readable by Everyone (share permissions and security permissions allow Everyone to read). This share is called \\R\EthRelease.

The web application is on server M. I'm running a Python (really Jython) script under Tomcat servlet container (via BSF) in order to try to access the remote files on R.

But no matter what I do, the script cannot see the remote shared folder. E.g. I use Python code such as:

# Note, R: is a mapped network drive pointing to \\R\EthRelease
for file in ['C:', 'C:\\', 'C:\\Users', 'R:', 'R:\\',
        r"\\R\EthRelease", r"\\172.x.x.x\EthRelease"]:
    output.append("  <accessCheck dir='%s' exists='%s' accessF='%s' accessR='%s'/>\n" %
        (file, os.path.exists(file), os.access(file, os.F_OK),
        os.access(file, os.R_OK)))

and the only folders that the script says exist are C:\ and C:\Users:

<accessCheck dir="C:" exists="False" accessF="False" accessR="False"/>
<accessCheck dir="C:\" exists="True" accessF="True" accessR="True"/>
<accessCheck dir="C:\Users" exists="True" accessF="True" accessR="True"/>
<accessCheck dir="R:" exists="False" accessF="False" accessR="False"/>
<accessCheck dir="R:\" exists="False" accessF="False" accessR="False"/>
<accessCheck dir="\\R\EthRelease" exists="False" accessF="True" accessR="True"/>
<accessCheck dir="\\172.x.x.x\EthRelease" exists="False" accessF="False" accessR="False"/>

By contrast, when I do a dir on any of the above paths in the CMD prompt on server M, they exist and are readable:

C:\Users\me>dir r:\
 Volume in drive R is GIS
 Volume Serial Number is ...

 Directory of r:\

12/03/2012  09:18 AM    <DIR>          .
12/03/2012  09:18 AM    <DIR>          ..
07/25/2013  08:51 AM    <DIR>          EGI
12/17/2013  05:46 AM    <DIR>          maps
               0 File(s)              0 bytes
               4 Dir(s)  48,192,491,520 bytes free

C:\Users\me>

I have tried this with both Jython stable 2.5.3, and Jython beta 2.7b1, and got the same results. I know it's not just a Python issue, because I run similar commands on my laptop (using Python 3.3) and am able to access the same network share successfully.

One possible difference is that the servlet container, Tomcat, is running as the local SYSTEM user on server M, while in the CMD shell I'm logged in as another user. But as mentioned before, Everyone has access to the remote file share, so that shouldn't make a difference, right? Is there some way I can log in as the SYSTEM user and test whether I'm able to access the remote file share in that state?

Another possible difference is that the servlet container or BSF might impose some sort of sandboxing restrictions, preventing me from accessing files outside of the servlet container. But that's not happening, because I'm able to check C:\.

Any ideas?? This has been driving me up the wall. I'd tried a couple of different times earlier to access the files directly from within Cocoon, and hit the same sort of wall. Recently I thought 'Eureka! I can outsource the problem to a Python script! Python can handle it!' But so far, no dice.

share|improve this question

2 Answers 2

up vote 2 down vote accepted

As discussed in these Super User questions – Elevated command line prompt can't access shared drives in Windows 7 and How to access network shares from an elevated process in Windows 7? – drive mappings are associated with a login, and so SYSTEM doesn’t have them unless you make special arrangements.  You may need to operate on the remote files by UNC or by doing a NET USE from your code.  Note that your test program reports that it has F and R access to \\R\EthRelease.

share|improve this answer
    
Thanks Scott, this is helpful. Regarding the last point, I assumed that the F and R access data was meaningless, since the test program also reported that the folder doesn't exist. Nevertheless it's worth looking into. But the proof of the pudding is when I do for file in glob.glob(r"\\R\Ethrelease\foo\*.pdf"): does it find the files? Yes it does!! Hey you solved it! –  LarsH Dec 18 '13 at 22:55
    
What's really strange to me is that \\hostname\share works and \\IPaddress.x.x.x\share doesn't. Usually it would be the other way around, wouldn't it? E.g. if DNS wasn't working. –  LarsH Dec 19 '13 at 0:17
    
Yes, I was wondering about that, too. –  Scott Dec 19 '13 at 0:19
1  
Is it possible that you typed the IP address incorrectly? –  Scott Dec 19 '13 at 0:19
    
That would make sense, but I checked, and the IP address was right. –  LarsH Dec 19 '13 at 0:31

I would generally not look at using the local system account for this purpose. I would look at running it under the networkservice account or a managed service account to provide this access.

If you really want to login as the local system account to test this, there are a couple ways to open a shell as the local system account.

You can use PSEXEC found in the PSTools and open an interactive cmd session under the system account: psexec -i -s cmd.exe

Or start a scheduled task running as the system account (at <time> /interactive cmd.exe)

share|improve this answer
    
Thank you - these are helpful suggestions. I don't know whether it's feasible to have the servlet container run under the networkservice account without breaking its other operations, but I will give it a try, and it would be helpful even just to know whether that is the source of the problem. I'll try psexec as you suggested. –  LarsH Dec 18 '13 at 22:27
    
OK, after starting a cmd session as administrator, I was able to run psexec as you described and start a shell. whoami now says nt authority\system. And now dir r:\ gives me "The system cannot find the path specified." But dir \\R\EthRelease works just fine, showing me the files I'm trying to access! So ... apparently the local SYSTEM does have the ability to access the share over the network, if not via the mapped network drive (because a different user mapped that drive?). This answer has helped me eliminate a possibility, but I still don't know why the problem occurs. –  LarsH Dec 18 '13 at 22:39
    
Umm.. the mapped drive letter won't exist in the system account user session. Mapped drives are based on the user session - they are not system wide for every user that logs into the system. Use the UNC path when connecting. You should also be able to specify credentials when making your connection in your code. –  Rex Dec 18 '13 at 22:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.