Skip to main content

SQL Application-Aware Backup Failed due to Insufficient Permissions on vmbackup.conf

SQL Application-Aware Backup Failure Due to Insufficient Permissions on vmbackup.conf

Problem Description

  • SQL application-aware backups for VMware virtual machines fail even when the configured guest VM backup account possesses Local Administrator privileges.

  • During the backup workflow, the proxy attempts to inject a temporary binary to execute the application-aware process. This framework requires creating or updating a dedicated configuration file at the following path on the guest OS: C:\ProgramData\VMware\VMware Tools\vmbackup.conf

  • If the backup process cannot access, create, or modify this file, the SQL application-aware operation fails or completes with errors.

Cause

This issue occurs due to missing Windows user rights and User Account Control (UAC) token filtering:

  1. Missing Batch Logon Privilege: The account assigned for application-aware backups lacks the "Log on as a batch job" (SeBatchLogonRight) privilege.

  2. UAC Token Filtering: Because the batch logon fails, Windows falls back to an Interactive logon. When UAC is enabled, Windows creates a split security token for administrative accounts, executing the process with a restricted (filtered) token. Consequently, the local Administrators group is treated as deny-only, causing administrative file creation tasks within C:\ProgramData\ to fail with an Access Denied response.

Traceback

The following errors are logged in the backup proxy/guest logs (Phoenix<YYYYMMDD>_<timestamp>.log):

level=debug message="Error in opening file in write mode for DisableSQLVSSWriterForVMSnapshot"
error="open C:\ProgramData\VMware\VMware Tools\vmbackup.conf: Access is denied."

level=debug message="Error in opening file in read mode for DisableSQLVSSWriterForVMSnapshot"
error="open C:\ProgramData\VMware\VMware Tools\vmbackup.conf: The system cannot find the file specified."

level=error code=2001 message="File or directory does not exist"

Resolution

To resolve this issue, assign the appropriate user rights policy to the backup account:

Step 1: Assign User Rights Assignment

  1. Log in to the target guest Virtual Machine.

  2. Open the Local Security Policy console (secpol.msc).

  3. Navigate to Security Settings > Local Policies > User Rights Assignment.

  4. Locate and double-click the Log on as a batch job policy.

  5. Click Add User or Group... and add the configured Druva backup account. Click Apply and OK.

  6. Locate the Deny log on as a batch job policy. Ensure that the backup account is not listed here. If it is, remove it.

Step 2: Validate Folder Permissions

  1. Navigate to C:\ProgramData\VMware\.

  2. Right-click the VMware Tools folder and select Properties > Security.

  3. Verify that the backup account or the local Administrators group has explicit Full Control or Modify permissions.

Workaround (Manual Configuration)

If immediate policy modifications are restricted by corporate GPO, manually generate the configuration file:

  1. Navigate to C:\ProgramData\VMware\VMware Tools\.

  2. Create a new text file and name it vmbackup.conf (ensure there is no trailing .txt extension).

  3. Open the file in an elevated text editor and input exactly one line:

    SqlServerWriter
  4. Save the file. Ensure no headers, whitespaces, or additional formatting strings exist.

Verification

  1. Ensure C:\ProgramData\VMware\VMware Tools\vmbackup.conf is accessible or has been successfully created manually.

  2. Open a command prompt as the backup user account and verify that you can read the directory path.

  3. Log in to the Druva Management Console, navigate to your virtual machine, and trigger a manual Backup Now operation.

  4. Verify the job completes successfully and that no vmbackup.conf: Access is denied entries appear within the newly generated log files.

See also

Did this answer your question?