"Couldn't open the log file on behalf of the user interface process"
blair003 :
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..)
1
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 support@pipemetrics.com and we'll have a closer look.
2
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?
3
blair003 :
Mar 15, 2018
Hello,
Sorry for delayed reply.
1. There are no DuplicateHandle in the logs .
For OpenProcess I often get: 2018.mmdd 10:58:13.706 (UTC+12) 0 B0:0C en | OpenProcess() for process 5700 failed with 5
2. Server 2008 R2 6.1 Build 7601 SP1
3. No we are not
4. It's an older server build but nothing unusual comes to mind.
The problem is resolved if I add the domain user to the local administrators group. I guess that is required/expected?
4
Alex Pankratov :
Mar 16, 2018
The problem is resolved if I add the domain user to the local administrators group. I guess that is required/expected?
Indeed it is.
By default the user account that Bvckup2 creates for the service _is_ added to the Administrators group, but I guess that you've set it to run under another account, correct?
5
Hugo :
Oct 29, 2019
Hi,
I'm just wondering if it's possible to fix this without having the user be a local administrator? Everything else works fine it's just accessing the log from within Bvckup2.
6
Alex Pankratov :
Oct 29, 2019
Looking into this right now.
Can you check the service-side log (%ProgramData%\Bvckup2\bvckup2.log) for OpenProcess() and DuplicateHandle() errors and show me the details? I'm guessing it's "access denied" (5), just want to confirm.
7
Alex Pankratov :
Oct 29, 2019
OK, so this is something that _is_ possible to fix, but it will take a day or so to accomplish. It basically involves making the UI process tweak its own DACL to grant the engine process "handle duplication" rights. I'll post an update once we got this working.
8
Hugo :
Oct 29, 2019
Hi Alex,
Thanks for your swift reply here
I found the following error for OpenProcess()
2019.10.14 15:44:15.876 (UTC+0) 0 AC:10 en | OpenProcess() for process 10924 failed with 5
https://i.imgur.com/Ron3tCt.png
However, it also looks like Administrator privileges are required for Shadow Copy, in which case I'm not too bothered about granting it Administrator access:
https://i.imgur.com/I4tvRIO.png9
Hugo :
Oct 29, 2019
Just to clarify, I didn't find any errors for DuplicateHandle()
10
Alex Pankratov :
Oct 29, 2019
Aye, OK. I will still have this reworked properly, because it's a reasonable thing to do. No need to create rigid dependency if it can be avoided.
11
Alex Pankratov :
Oct 30, 2019
This has been patched up as a part of 80.6. The UI process now grants the "dup-handle" right to the engine's user account, so the latter can open logs on UI's behalf even if it's running under a non-admin user.