Feb 13, 2018
After switching to service mode, I had access problems due to permissions. To resolve them, I changed the user account the service logs in as to be a domain user I have already setup for shadow protect.
I notice I now get a message in the bottom pane:
"The log cannot be displayed, because Bvckup 2 service couldn't open the log file on behalf of the user interface process. Please report this incident to support."
Both the service user account and the logged in user that runs the GUI have full access to %LocalAppData%\Bvckup2\
(I assume this is a permissions issue as a result of changing the user account the service runs as, hence posting here..)
Alex Pankratov :
Feb 13, 2018
This is absolutely a permission issue.
Logs are kept next to the engine, so in the service mode they will be in %ProgramData%\Bvckup2\ (not %LocalAppData%). Please check that your domain user account has full access to that folder and that should do it.
If it doesn't, send me an email at email@example.com and we'll have a closer look.
Alex Pankratov :
Feb 14, 2018
OK, this is getting interesting. Received another support request just now describing exactly the same issue. It's interesting because these are the only two cases _ever_, so them popping up together is likely not a coincidence.
I must correct what I said in my first reply.
This is issue is in fact a permission issue, but it's a _process_ permission issue, not a _file_ permission one. The context of this error is as follows:
In service mode backup logs reside in %ProgramData% and they are normally inaccessible to the UI. So in order to allow the UI to read them, it’s the service process who opens them. It then converts resulting “handles” to be usable by the UI and forwards them to the UI that then proceeds to read the logs as needed.
In practical terms this maps onto a pair of system calls – OpenProcess() that allows the service process to do the handle “conversion” for the UI, and – DuplicateHandle() that does the actual “conversion”. If either of these requests fail, the above error is produced.
Now... this is really strange.
Both function calls are trivial, they have no reason to fail. Moreover, the DuplicateHandle() exist to serve this exact scenario to begin with, i.e. when a privileged process obtains access to a resource and passes this it to a non-privileged process that can’t access that resource on its own.
Even if the system is "hardened", processes are isolated, etc. All that's happening here is that one process creates something for another process. It doesn't alter the state of the latter, it doesn't force to use the resulting handle, etc. So I can't really see how this can be exploited in any way to justify failing either request.
This makes no sense. And when things stop making sense, the usual culprit is the antivirus or "system protection" software.
1. Please search %ProgramData%\Bvckup2\bvckup2.log for "OpenProcess" and "DuplicateHandle" and let me see the details
2. What's the OS on the machine?
3. Are you running any 3rd party security software on the machine?
4. If you do, can you try temporarily disabling it and see if this perhaps resolves the issue?
5. If you don't, is there anything unusual about the machine setup, especially in terms of tightened up security and some such?