Failed to save file content. Access is denied RPC function call failed. Function name: [DoRpcWithBinary]. Target machine: x.x.x.x
This backup is backing up 17 VM's so we don't want to redo the entire backup. The backup has been running fine for weeks and then started having this error. We have rebooted the server that has Veeam Backup & Replication installed, but it still errors out.
Please avoid posting log snippets as requested when you click New Topic. If you want to troubleshoot this issue further, please open a support case with our support team and include your support case ID here, instead of logs.
Someone please let us know the support case ID for this issue. Otherwise, we will never know the resolution and will be unable to assist future posters. People are quick to post issues, but very few return to update the topic with the resolution - which is one of the reasons why we require support case ID (allows us to look up the resolution in future). Thanks!
My understanding is that this is a known issue and that development is working on a hotfix to address it. It appears to have something to do with the size of the metadata file (.vbm) that causes it to fail.
Any resolutions? We just started having this problem yesterday afternoon. This forum post appaers to be all there is on the Internet about it. We just opened a support incident, but haven't heard anything back yet.
It typically means that your VBM file is too big to push across RPC. I believe our team is working on addressing this currently. As a workaround, you will want to reduce your number of restore points/split vms up in the job as the limit seems to be around 4 MB in size of the VBM.
Skype: Sethbartlett88 - Make sure to label who you are and why you want to add me
Twitter: @sethbartlett
If my post was helpful, please like it. Sometimes twitter is quicker to hit me up if you need me.
this is happening to me too... havent had one good backup since 1/26
also does anyone ever check the online ticketing system, i get an autoreply message then nobody follows up
"We currently have a known issue that if the VBM file grows over 4 MB in size the job will fail with DoRPCWithBinary RPC Function call. The current work around is to break your jobs up into smaller groupings to prevent the VBM to grow to this size."
i guess the first time i read it in one of the previous posts, i didnt want to believe that that was the _only_ solution... but i guess it is, for now.
similar situation as OP... my job has 135 VMs, just going to be a big pain to have to split it up then put it back as one job once the patch is ready. splitting it up is going to hurt your dedupe and compression and since each job is independent of each other, you're going to need a whole ton of free disk space if you decide to keep the old jobs around to be able to restore from until they get aged away.
any eta for patch? maybe i can just go w/o for a couple days so i dont have to make a bunch of smaller jobs (i doubt i have the disk space to accomodate anyway...)
but it makes no mention of our specific problem. i think i'm going to be forced to recreate my jobs (use the workaround to split them up) if a patch doesnt arrive by the end of this week