ESXi Configuration Task - Access to the File is Denied
I have an ESXi Configuration Backup task that fails with the error "Access to the file is denied." when attempting to copy the backup to the secondary location after the first run.
Using the latest builds of Acronis, ESXi 5.5, and vCenter.
Create new ESXi Configuration Backup task.
Store backup in \\network\location1\backups\ .
Store copy in \\network\location2\backups\ .
Run task.
Backup completes successfully. (Acronis has access to read and write \\network\location1\backups\ )
Copy completes successfully. (Acronis has access to read and write \\network\location2\backups\ )
Run task again.
Backup completes successfully. (Acronis has access to read and write \\network\location1\backups\ )
Copy fails with the error "Access to the file is denied.".
A 1 KB file (with some data) is created in the copy location. (Acronis has access to write \\network\location2\backups\ )
I've already tried unsharing and resharing the network location, removing and readding permissions for the account Acronis is using to access the network locations, and deleting and recreating the backup job. The first backup and copy always work fine. Backups after that always work fine, but copies (after the first copy) do not. They always fail.
I have several identical backup tasks for older ESXi machines and they work perfectly. These tasks are using the same account and same network location.
I deleted one of the working tasks and recreated it (same ESXi host as before, same network location and account), and it is now failing.
I've verified the backup defaults are NOT setting a password on the new tasks. (There is no UI option to set a password for the ESXi Configuration Backup tasks, but setting one via the default backup settings seems to take effect, so I disabled the default password in my troubleshooting.)
Any ideas?

- Log in to post comments

Hi,
I was finally able to reproduce the problem with both 10007 and 10535 builds of Acronis Backup for VMware. It occurs on the 2nd run of the ESXi configuration backup when there are password protection settings defined in default backup settings _before_ creation of the ESXi configuration backup task. In fact the encryption of the ESXi configuration backup is not officially supported. That's why there is no such option when you configure backup settings during ESXi configuration backup task initial creation. So the bug is that the archive protection settings from default backup settings are still applied to ESXi configuration backup task, while they should not. The problem with copying of backup to 2nd destination is related to the fact that there is no password defined for the archive in 2nd location in the copying script (by design), so it fails to open the archive on the 2nd run (it doesn't need to open archive in 2nd location on 1st run since it doesn't exist at that moment).
If you remove the default password protection settings and re-create the ESXi configuration backup task - it will work properly.
Thank you.
--
Best regards,
Vasily
Acronis Virtualization Program Manager
- Log in to post comments

Thanks for the reply. I had already tried disabling password protection in the backup defaults and recreating the job, but that didn't help.
Here's the default settings section (set BEFORE I created the job):
The archive was still listed as password protected and encrypted in the secondary location. (The first location was fine.)
I tried again now with the following settings (set BEFORE creating another test job):
This worked.
I had to blank out the password, set no encryption, and uncheck the "Set password for the archive" check box.
Just unchecking the "Set password for the archive" isn't enough, apparently.
So if you have ESXi configuration backup tasks with copying to a secondary location, you cannot use the default archive protection settings, and you have to recreate any ESXi configuration backup tasks that have this issue after completely blanking out the default archive protection settings.
Thanks for confirming it was related to the default archive protection settings and reproducing the issue and confirming a workaround.
- Log in to post comments