The support forum

Network share and mapped drive access

Feb 04, 2015

The problem

If you are backing up to/from a network share or a mapped network drive, you may run into a situation when the app doesn't "see" the location.

Case 1 - Running as Administrator

In 99% of cases this happens because the app 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 make it automatically appear in another.

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 has no idea of which mapped drives a _desktop_ user may have setup.

The solution

A 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 -

The workarounds

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.

Feb 28, 2015

On Windows 10 this may also be of relevance -

hawkster27 :

Jun 03, 2019

[Moved here -]
Topic is locked.

New topic

Made by IO Bureau in Switzerland

Blog / RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms