service doesn't behave the same as command line

I am running on a Windows Server 2003. This is my problem: I wrote a Perl script to automate the copy of some files from my Server machine to some network drives. I am using xcopy to copy the files. 开发者_StackOverflow My problem is the permissions.

If I run the script from the command line, it works, all the copies are successful. If I try to run the script using a service all the copies fail. This service is a program that I wrote that takes the script and runs it. In the background all it is doing is to call the C function 'system' and it runs the same program that I can run from the command line.

I have tried many variations of this to figure out what is wrong with it but I can't see why the service would not run the same way I run it from the command line.

I set up the service to run as the same user I am using from the command line.

I also tried to map the network drives as the user that has writing permission but the result is the same. Manually the script works, from the service, it doesn't.

Any suggestion is appreciated. Thanks Tony

The service may be running as the system and not have access to the network drives. In the Service settings, change the service to run under your account (or an account with the relevant permissions/mappings).

When the service runs, it uses whatever credentials you specify in the Services manager of Windows. The default, LOCAL SERVICE, probably does not have permission to access the resources to be copied.

Create a new user account with the minimum set of permissions needed to perform the copy and configure your service to run under that account.

I did figure out the issue (I think), and that matches what I later found in another post:

https://serverfault.com/questions/4623/windows-can-i-map-a-network-drive-for-a-service-account <...Persistent drive mappings are only restored during an interactive login, which the service does not use. I believe the only way to get a service to use a network drive is for that service to map the drive itself or alternatively for it to us a UNC path instead of a mapped drive.>

What I did was mapping the drive using the service and that seems to work. It turns out, if I map the drive and save credentials, then I can access later the drive without having to map it again. I don't know why this approach seems to work though.

-Thanks everybody for your help.

Tony