network drives not seen

[megamicron]

I previously used syncback free without problems but (shamefully) have not backed up a network drive for over one year. Now the network drive is not seen (but ok with explorer) and after failing on original Vista machine tried my newer Windows 7 Pro laptop with latest syncbackfree software and same problem. The drive is a Western Digital MyBookLive NAS which backs up the old Vista PC to a schedule, but I use Syncbackfree to back up the NAS.Any clues? Thanks

[cliffhanger]

HI

Are you by any chance starting SyncBackFree using Run As Administrator? (Either 'manually' via right-click, or because you have a shortcut to SBFree set to do so, or because you have set the Properties of the EXE that way, which would make any instance of SBFree 'run as admin', regardless of how it is started)? You can tell this is happening if you see a UAC prompt when starting SBFree, which ordinarily you wouldn't see.

Reason I ask is that this issue (which is to do with 'elevated privileges', which normally SBFree doesn't ask for, because its available functionality doesn't need them) doesn't normally* arise with the freeware version, but it will arise if SBFree is 'run as admin' (I just checked).

This KB article has more details (note: it is written on the expectation anyone with the problem / reading the article will be running the SE or Pro version. The reference to trying to use the Alternatives buttons for the appropriate paths/devices is not relevant/available to a freeware user, and - as stated in the article - won't work anyway, for the exact same 'visibility' reasons.

Whatever the background, the solution (if you prefer to use a mapped network drive letter) is probably to create the registry entry mentioned (set to [1] as stated) and reboot. This should make the mapped drive letter visible to elevated processes.

The alternative solution is to sidestep mapping a drive letter to the resource altogether, and use the UNC path instead, as recommended in the KB article about the 'visibiity' issue. This additional KB article has some background as to why it is recommended / why you might want to steer clear of using mapped drive letters, especially if you plan to Schedule your backups.

HTH


* thus, the usual frustrated question is along the lines of "Why can't the paid-for version see my mapped drive when the freeware can?"

[YTMI]

I loaded the Syncback Lite software as an Admin. Then I ran the program as an admin. Still did not see drives that I saw using the free software version. Surely I don't need to keep a copy of free software just so I can see phone & mapped network connections.

[cliffhanger]

Hi, you have things back-to-front. Running SB Lite as Admin won't affect things because Lite asks for elevated privileges already (by virtue of its manifest file: note the UAC prompt you get however you start Lite). Your problem is that Windows maps network drive letters with lower privileges and by default Windows then restricts processes with elevated privileges from seeing/using the low-privilege mappings. Running Lite as Admin will make no difference to that state of affairs, as there will still be a mismatch between the high-privilege elevation and the low-privilege mapping.

The easiest way to get around it is to change the setting in Windows that blocks mapped drive letters from being visible to elevated-privilege processes (i.e. SB Lite) - IOW, apply the registry fix in the KB article. Or, stop using mapped drive letters in SB Lite and use the equivalent UNC paths instead. (This will help the problem that you cannot use mapped drive letters in profiles that run on a Schedule). Be aware that the simple existence of drive mappings (regardless of whether the profile refers to them) can conflict with using UNC paths (spurious issues with passwords being common).

Note that the registry fix will not address the issue of mapped drive letters not working in a scheduled session (as per the 2nd KB article in the original reply), That is a different issue, not related to elevated privileges (or not), and for which there is no solution except not to use (refer to) mapped drives in your profiles.