First of all thanks Zenju for this application, which is simply great! But then I need to ask a question.
I have a folder located under Program Files that I want to be the mirror of a folder on a Network PC. The network is a LAN, file sharing is turned on and both machines mount Win7.
So,
Source = \\NetworkPC\...\MyFolder
Target = C:\Program Files\MyApp\MyFolder
If I do not elevate FreeFileSync (FFS) running it as Admin, it accesses the network location but it cannot do the backup.
If I elevate FFS, it does not access the network location, asking me to enter Network and then Account credentials. I have tried passwords active on the accounts but I cannot perform the FFS comparison.
Do I miss something?
Any help is appreciated.
Thanks
Alberto
How to let FreeFileSync write in UAC protected area
- Posts: 1
- Joined: 29 Jan 2013
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
You definitively need admin rights to write to "C:\Program Files", but the question is why accessing "\\NetworkPC" fails. What does the FFS error message say?
- Posts: 20
- Joined: 6 Jul 2005
I've found that elevated processes can't access network resources, at least on my home machine. Try accessing the network from an elevated command prompt.
- Posts: 20
- Joined: 6 Jul 2005
See this workaround:
http://support.microsoft.com/kb/937624
http://support.microsoft.com/kb/937624
- Posts: 20
- Joined: 6 Jul 2005
Some additional interesting info here:
http://channel9.msdn.com/Shows/Going+Deep/UAC-What-How-Why#c633305694960000000
1) Mapped drives get interesting in combination with the "split-token" account, because of a weird dichotomy in the system (in large part historical) -- the drive letters are per-user, but the underlying drive mappings are per-LUID (i.e., distinct for each individual logon, even for the same user). This is why the mappings disappear when you elevate, and the setting you found tells the OS that you want the mappings you make non-elevated to be mirrored into your elevated context as well -- under the covers, the NTLanman network provider maps the drive and then asks the LSA to find the associated elevated token and use it to mirror the mapping. Technically, it opens a small loophole since non-elevated malware can now "pre-seed" a drive letter + mapping into the elevated context -- that should be low-risk unless you end up with something that's specifically tailored to your environment.
http://channel9.msdn.com/Shows/Going+Deep/UAC-What-How-Why#c633305694960000000
1) Mapped drives get interesting in combination with the "split-token" account, because of a weird dichotomy in the system (in large part historical) -- the drive letters are per-user, but the underlying drive mappings are per-LUID (i.e., distinct for each individual logon, even for the same user). This is why the mappings disappear when you elevate, and the setting you found tells the OS that you want the mappings you make non-elevated to be mirrored into your elevated context as well -- under the covers, the NTLanman network provider maps the drive and then asks the LSA to find the associated elevated token and use it to mirror the mapping. Technically, it opens a small loophole since non-elevated malware can now "pre-seed" a drive letter + mapping into the elevated context -- that should be low-risk unless you end up with something that's specifically tailored to your environment.
