2BrightSparks Help and Support

When SyncBackPro/SE it is run elevated it cannot see networked drives, but SyncBackFree can (so can SyncBackPro/SE if it is not run elevated). This issue is due to security restrictions in Windows. Microsoft made a change in Windows Vista such that drives that were mapped without elevated privileges cannot be seen by processes run with elevated privileges.

Cause

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 Windows 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, 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, 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 - SyncBackPro/SE V11

If you are using SyncBackPro/SE V11 then you can avoid this restriction by going to the Expert tab in Global Settings. Enable the option Allow access to mapped network drives, save the settings and reboot (you must reboot for the setting to take effect).

Workaround #2 - Not Elevated

Run the profile using unelevated SyncBackPro/SE.

Workaround #3 (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:

\\servername\Shared_Folder_Name

or

\\ip_address\Shared_Folder_Name

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:

    net use

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):

Network

    Servername

        Shared_Folder_Name

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:

\\servername\Shared_Folder_Name

which is what you should enter in SyncBack's Source or Destination box (plus any optional subfolder path within the share, if used).

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/11 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).