SyncBackPro/SE cannot see networked drives but SyncBackFree can.
This issue is due to security changes introduced with Windows Vista. Microsoft made a change in Vista or newer operating system such that drives that were mapped without elevated privileges cannot be seen by processes run with elevated privileges.
This problem occurs because User Account Control treats members of the Administrators group as standard users.
When a member of the Administrators group logs on to a Windows Vista-based and newer computer that has User Account Control enabled, the user runs as a standard user. Standard users are members of the Users group. If you are a member of the Administrators group and if you want to perform a task that requires a full administrator access token, User Account Control prompts you for approval. For example, you are prompted if you try to edit security policies on the computer. If you click Allow in the User Account Control dialog box, you can then complete the administrative task by using the full administrator access token.
When an administrator logs on to Windows Vista or newer, the Local Security Authority (LSA) creates two access tokens. If LSA is notified that the user is a member of the Administrators group, LSA creates the second logon that has the administrator rights removed (filtered). This filtered access token is used to start the user’s desktop. Applications can use the full administrator access token if the administrator user clicks Allow in a User Account Control dialog box.
If a user is logged on to Windows Vista or newer, and if User Account Control is enabled, a program that uses the user’s filtered access token and a program that uses the user’s full administrator access token can run at the same time. Because LSA created the access tokens during two separate logon sessions, the access tokens contain separate logon IDs.
When network shares are mapped, they are linked to the current logon session for the current process access token. This means that, if a user uses the command prompt (Cmd.exe) together with the filtered access token to map a network share, the network share is not mapped for processes that run with the full administrator access token.
Workaround #1 (Registry)
There is a policy change that can be made in Windows to allow elevated processes to see mapped drives.
- Open the registry editor: regedit.exe
- Go to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
- Create a new DWORD value called EnableLinkedConnections and set the value to 1
Workaround #2 (from Microsoft)
To work around this issue, use the net use command together with a UNC name to access the network location. For example, at a command prompt, type the following command, and then press Enter:
net use \\< computername >\< sharename > /user:< username >
With SyncBackPro/SE, you can use UNC path (instead of mapped drives) to point to your network share. A typical UNC format will look like this:
Network credentials to allow SyncBack access to your shared folder
If your network drive requires username/password credentials for access, you may need to save them under:
Modify > Expert > Network
so that SyncBack can provide the correct credentials during Unattended backups (Scheduled runs).
How do I find my UNC path?
A simple way is to start the Command Prompt and then type:
It will then list all your mapped drives and their UNC paths. If you run the Command Prompt again, but as an administrator (so it is run elevated) then you'll see that the net use command has a different output, which demonstrates the issue, i.e. elevated processes do not have access to drives that are mapped by unelevated processes (and vice versa).
Another way to locate the UNC path of your network share is to look at the mapped drive in Windows Explorer. A network share may look like this:
Shared_Folder_Name (\\servername) (X:)
or it could look like this (if you browse the Network to locate your shared folder):
In the first example, the share-name is shown first, followed by the machine-name, then the drive letter. The first two parts, when reversed & formatted appropriately equate to the UNC path:
which is what you should enter in SyncBack's Source or Destination box (plus any optional subfolder path within the share, if used).
SyncBackPro/SE runs with elevated privileges (by default) because it requires the use of certain Windows functions (e.g. open/locked file copying) that are only available (in those versions of Windows) when using elevated privileges. You can configure SyncBackPro/SE to run without elevated privileges:
Other ways to locate your UNC Path
You can likely also browse (click 'folder ' button on left of Source or Destination box) directly to the UNC path if you navigate via the Network section displayed in the browse dialog. Simply navigate ('drill into') to the machine-name, then select the share-name, and if required, any subfolder path within the latter.
Note that you cannot simply enter the machine-name and have it 'back up all shares' (Windows does not permit that: network connections must be to a specific/individual share). If you browse the Network section and try to select just the machine name, SyncBack will warn you that is not allowed.
Possible Other Causes
The remote server (or NAS drive, SAMBA share, etc.) may be using SMB 1.0 and your Windows 10 installation probably has SMB 1.0 support disabled. Check with your relevant documentation on how to enable SMB 2.0 or Microsoft's documentation on enabling SMB 1.0 support (not advisable).