This happens because the ProVide service is running as the Local System account, and Windows does not allow a service running as Local System to access network (UNC) paths. It’s a Microsoft design rule that applies to every vendor’s service, not just ProVide. The fix is to run the ProVide service as a domain (or matching local) account that has permission to the network share you want to use.
How to fix it #
- Choose or create a user account that has access to the network path you want to add, as well as to the ProVide program and data folders. In a domain, use a domain account; for a standalone server, create matching accounts (same username and password) on both the ProVide machine and the machine hosting the share.
- Open the Windows Services console (
services.msc). - Find the ProVide service, open its Properties, and go to the Log On tab.
- Select This account, enter the account name and password, and click OK. Windows normally grants that account the “Log on as a service” right automatically.
- Restart the ProVide service so the change takes effect.
- In the ProVide admin interface, add the network location using its UNC path (
\\server\share\...) rather than a mapped drive letter. Mapped drives are per-user and aren’t available to a service, so always use the full UNC path.
After the restart, ProVide can add and serve resources from any network path the service account is permitted to access.
If you need per-user network access instead #
Running the service as one account gives the whole server that account’s access. If you instead want each connection to use the individual Windows user’s own permissions on network paths, that’s Active Directory integration with Windows account impersonation, which is a separate setup. See ProVide’s Active Directory documentation.