Feb 04, 2015
If you are backing up using a network share or a mapped network drive, you may run into a situation when the program doesn't "see" the location.
Case 1 - Running as Administrator
In 99% of cases this happens because the program is switched to run as Administrator. More specifically, it is caused by the fact that Windows maintains two user *sessions* for each logged in user. One session is for running apps with regular user rights and another – for the “run as admin”, elevated execution.
These sessions share the desktop, but each of them gets its own list of mapped drives and share connections. So mapping a drive in one doesn't automatically make it appear in another.
Case 1* - January 2021
There's a peculiar case when _restarting_ the program while running in the admin mode will make it suddenly see the share.
This is a recent development specific to Windows 10. It appears to be caused by some other elevated process making a share connection, _but_ this connection not being made available to _already running_ elevated processes.
Case 2 - Running in Service mode
Similarly, if the program is switched to run in service mode, its engine runs as a system service under a different user account and therefore it has no idea which mapped drives a _desktop_ user may have set up.
Proper solution is to use explicit network paths instead of mapped drives, which have always been a second-grade citizen of Windows networking and file systems.
That is, use \\server\share\... for the path and, if needed, configure the username and password for accessing this share in backup settings -
For the Admin mode case there are also two workarounds:
1. Apply a registry fix to keep network lists in sync between two sessions -
( but in a typical Microsoft fashion it doesn't appear to always work )
2. Issue “net use /persistent” from an elevated (admin) prompt to make a sticky drive mapping for the admin session.