views:

652

answers:

4

I tried running the service in the "Local System" : didn't work.

I tried running the service in an account having rights on the network shared folder : didn't work.

Do I have to create a standalone application for this and launch this application as a user with rights on the network shared folder?

Thanks,

Nic

A: 

You can probably use impersonation to get the credentials you need: http://msdn.microsoft.com/en-us/library/aa376391(VS.85).aspx

Scott Langham
A: 

Running the service in an account having rights on the network shared folder does work. I have a service that does just that.

It won't necessarily work on Novell Netware shares or other "Non-standard" shares (we had trouble with this in the past, but nowadays Netware is pretty much irrelevant.)

oefe
A: 

Both your scenarios should work. The "local system" is the computer account in the active directory that you can give share permissions to. I have no idea why it doesn't work for you. But here is what you can do.

  • Use an regualar account (its just easier).
  • Test your application as console application.
  • Tweak the auditing on the client to log everything to the security log. It is done from the local security policy application. And do the same on the server (If you can).

This should be enough to locate the problem.

Update 1: In response to the comment which I think is wrong (but maybe I am...). The service which the comment refers to ( The one without network access) is called local service account( NT AUTHORITY\LocalService ). It is usually used in the identity of application pools, but can be used in services. It is not the same as local system account.

from msdn:

When a service runs under the LocalSystem account on a computer that is a domain member, the service has whatever network access is granted to the computer account, or to any groups of which the computer account is a member.

Igal Serban
It won't work with LocalSystem typically, actually. Windows strips network privileges from the LocalSystem token to prevent network access as a security measure. LocalSystem is not a real account in AD either.
Nick
You may be right; this may have changed with Windows versions. In NT4, LocalSystem had no network access, but that was before the split of accounts. I'm not sure what the default access is, but it does look possible in 2000+.
Nick
+2  A: 

You should use UNC paths (as Scott suggested), and run the system under an explicit account which has access to the network resource; that should work.

It probably will not work under LocalSystem because that's a special user account in Windows with local system access only. LocalSystem had no network access in NT4, and in 2000+ it's treated as the computer accounts for network access purposes, and subject to access restrictions in the local security policy. See this page for more info.

Short answer: use an explicit account to run the service which has access to the UNC path. :)

Nick
I think that you are wrong about the local system account network access. Look at my update in my answer.
Igal Serban