Services should run under the LocalSystem account which is all powerful on
the local machine but powerless on the network. That _may_ be the reason for
the problem.

Regards,
Will

Shared resources like fileshares, are bound to a user session, that means
that the share wich is acessible by logon user A is not accessible by
another logon user.
Now, a service can run as LocalSystem , LocalService or NetworkService or as
a "domain user".
LocalSystem has no network credentials so cannot be used (well not exactly
true but...), while LocalService and NetworkService do have network access,
but they don't have a session with the remote share.
Basically, have two options to solve this issue:
1. You run your service with domain account credentials, or
2. You create a new logon session (calling LogonUser) and you establish a
network connection from within your service for that logon session (shelling
out a net use command, or by calling NetUseAdd.
Both methods have their own problems, the first requires the domain accout
to have access to the local filesystem.
The second needs a lot of PInvoke calls.

Another solution requires you to be a member of an AD domain realm (W2K or
higher Domain), in such environment all service accounts (LocalSystem,
LocalService and NetworkService) are using the "machine" acount credentials
when accessing remote resources, so all you need to do is grant the "machine
account access rights to the remote share.
Say you have a machine named "Billy" and a resource server named "Bob" in a
W2K domain "BobsDomain", and a service running as NetworkService on "Billy"
want's to copy files to "Bob". What you should do is gran BobsDomain\billy$
access to the share exported by "Bob".

Willy.