Revolving around the core of technology
Hello,
I get the following error either with or without "Backup locked files" checked: (yes I saved)
Error - Unable to encrypt local file E:\Outlook\Outlook.pst. Error - The process cannot access the file because another process has locked a portion of the file
So it's as if either VSS doesn't work with encryption enabled or VSS isn't working.
Outlook is open which makes sense except VSS should allow backup even if "in use".
E: drive is a local hard drive formated with NTFS.
Event logs show no VSS errors just occasional "The VSS service is shutting down due to idle timeout."
Other VSS aware programs work fine with no in-use/locked type errors.
Btw it's Windows 10 Pro so could there be VSS comaptibility issue with Win10? I'd need to test with other OS's.
Thanks
Bill
OK I can confirm this is a bug or something based on the following tests to replicate on different Windows versions:
Create a text file or use any existing file. (I'd avoid using a file with important data just in case. I just used notepad to save file & exit)
Then open Powershell & at the Powershell prompt do:
> $file = [System.io.File]::Open("C:\Test.txt", 'Open', 'Read', 'None')
LEAVE Powershell open & alone while you go to Syncrify client.
Assuming that file exists it is now locked exclusive for reading. Now on to testing 3 different version of Windows with Syncrify client:
Backing up on Windows Server 2008 R2 with "Backup locked files" UNCHECKED results in this error as expected "Read error 20015 - C:\Test.txt"
Backing up on Server 2008 R2 with it CHECKED it works just fine as expected. (You can see VSS initializing & the special \\?\GLOBALROOT\Device..
Backing up on Server 2012 R2 with it CHECKED or UNCHECKED it always results in "Read error 20015 - C:\Test.txt"
Backing up on Windows 10 with it CHECKED or UNCHECKED it always results in "Read error 20015 - C:\Test.txt"
Now back in Powershell if you do:
> $file.Close()
That closes file & removes the lock.
With that file lock removed all 3 versions of Windows backup the file just fine with or without "Backup locked files" checked.
So while this test doesn't result in the exact same error as Outlook being open (different type of lock I'm assuming), IMO unless presented with additional info, the only conclusion I see is that VSS is not working in Syncrify client on Server 2012 R2 or Windows 10. :(
Bill
Dear Bill,
There are two possible reasons for this error:
In either case, check SyncrifyClient.log, if running through scheduler, or SyncrifyClientGUI.log, if running manually for errors related to VSS. Check http://web.synametrics.com/SyncrifyLogFiles.htm for details about the log files.
Thanks for the response but now I feel like an idiot lol I knew the service ran as Local System Account so it'd have elevated privileges but also assumed the GUI was just a front-end for the background service. In other words I made the incorrect assumption that the service still did backups when initiated from the GUI. <redface> Funny thing is Windows 7 and Windows 2008 didn't have a problem when running GUI without Admin which threw me off in figuring it out on my own.
I tested running client as Admin & sure enough that solves the problem. I haven't checked the logs yet to see if it suggests running the GUI as Admin but perhaps the GUI itself should suggest that if manual backup is run & there are locked or in-use errors to help avoid confusion. Or maybe create 2 GUI icons, one with run as admin flag set & Admin in name..
In any case at least this post is there for others searching for this issue. :)
Thanks!
Bill
Yes, same happened to me...
Thanks for clarifiying.
Tamer
error globalroot device hard disk volume shadow Copy163
Hany,
I am sorry, I do not understand what is your question? The path "Globalroot" appears in the log file when you use VSS.
Could you please rephrase your question so I can better serve you.