I have a Windows service running in local system that simply keeps trying to access a file with a UNC path of the form \\machine\folder\file.txt until it succeeds. It succeeds immediately when I start the service manually, but on reboot it gets System Error 53 (Network Path not found) until I do something such as logoff or “fiddle” with Windows Explorer such as double-clicking an unrelated text file (weird, I know). But there is no reliable trick; I am not sure what triggers it to suddenly be able to see the shared folder.
However, I chanced upon an apparently reliable “solution,” which is to attempt a CreateProcess on “net use I: \\machine\folder” from within the service to map the shared folder before attempting to access it (I continue using the UNC path, not I:). The net use call appears to immediately trigger my ability to access the shared folder from the service despite the fact that the net use call itself probably fails (I haven’t checked because you’re not even supposed to be able to map drives from a service).
This sounds similar to database connection doesn’t work when service starts at boot but works when it’s manually started but in my case it is a network shared folder, plus I know it can also suddenly just start working under the circumstances described above.
I don’t think this is a permissions issue because it demonstrates full access capabilities on the shared folder when it succeeds in gaining access. But I would like to know the reason so I can handle it properly.
The LocalSystem account does not have an actual login or password and so will attempt to connect to the share with computer credentials if on a domain, else anonymously. For this to work, the share will need to allow access to the computer account (usually the hostname with
$appended) or allow guest access with no password.A better practice would probably be to create a new domain account for the service to run in, and set permissions appropriately for the new account.