File restore of Linux OS: FLR appliance fails to come with access denied error

[selva]

Case #04161154

Looks like a permissions issue, and I have a support case pending but in case any of you have seen this, any pointers would be highly appreciated.

Host: Hyper-V server 2019
4 VMs: 1 Windows Server, 3 Linux servers
VM in question: Linux (ubuntu 18.04) -- no guest processing during backup

Veaam Setup: community edition B&R protecting 4VMs
Hyper-V added to B&R with an admin account and no error during backup

Everything seems to work (including Windows guest FLR) except file lever restore of any Linux VM errors before the file browser comes up. A message box shows:

'VeeamFLR_foo_122ef879-fb7b-4c73-8dc3-168b4453113a': Hyper-V Virtual Machine Management service Account does not have sufficient privilege to open attachment 'C:\VeeamFLR\i35pksf3.0ba\ProxyAppliance\config.vfd'. Error: 'General access denied error' (0x80070005). (Virtual machine ID 8A0157F5-AE87-40B1-821A-1F2FFDF284A3)'). Error code: '32769'.

Thanks

Selva

[Egor Yakovlev]

Hi Selva,
while waiting for support answer, it is worth giving a shot to this Microsoft article.
/Cheers!

[selva]

Thanks Egor for the pointer to the MS link. Suspecting something like this I had tried editing ACLs without success. Its not clear to me whether ACLs with the particular VM's SID added to C:\VeeamFLR folder with container inherit would work or something else is needed. Or does FLR create a new VM with a different SID on the fly... In either case, that would point to a bug. Unless I'm doing something wrong.

[Egor Yakovlev]

It is Virtual Machine Management service account permissions for said path that fail. Typically that service is run under Local System account - you can easily check it with PowerShell:

Code: Select all

get-wmiobject win32_service | where-object {$_.Name -eq "vmms"}| format-table Name, Startname

so try giving that account full access to the path first.
/Thanks!

[selva]

vmms is started as Local System and the root of the path (C:\VeeamFLR) already has permission with inheritance. The sub directories inside that are created (and removed) on the fly by Veeam during FLR so not sure what exact permissions the failed path gets.

Thanks,

Selva

[Egor Yakovlev]

You can use Process Monitor to see exact account name that was requesting access to C:\VeeamFLR\, hit Ctrl+L and set [Path, is, C:\VeeamFLR, include] and run recovery wizard once more. It is definitely a permissions issue.
/Cheers!

[selva]

I worked around by instant restore and then getting the files from there. The case got closed because of high support team load, but I'll try to get to the bottom of this and report back.

[selva]

I ran into the same problem again with the Virtual Lab proxy appliance for SureBackup. The appliance failed to came up with the same access denied error seen with Linux FLR appliance. I fixed it by moving the appliance to D:\ drive where other all other VM data is kept. But there seems to be no option to move the location from where FLR appliance is started.

That prompted me to look at the permissions again and fixed the FLR issue by granting (OI)(CI)(F) permissions to "NT VIRTUAL MACHINE\Virtual Machines" for the C:\VeeamFLR folder where Veeam copies the FLR appliance into. Happy camper now, but wonder why Veeam is not creating this folder with that permission in the first place.

As it seems to be only me, may be an odd set of circumstances. Like the root of my C: drive doesn't have permissions to that SID but D:\ has --- not by any design, that's how Windows hyper-V server installed it.