VDDK error: 13 - Troubleshooting

Backup/Replication jobs fail with:

VDDK error: 13.You do not have access rights to this file

Below is a list of possible solutions to this issue sorted by what transport mode was being used when this error occurred.
Note: There are many causes for VDDK 13; this list is not intended to be all-encompassing.

Using Transport Mode: Network Mode

• Solution 1:
  Sometimes, you may receive this error when permissions are not correctly set. To confirm, please follow the steps outlined in the following KB article to test ports, permissions, and DNS resolution
  Veeam KB1198: NFC connectivity troubleshooting steps

Using Transport Mode: Hotadd Mode

• Solution 1:
  Veeam KB1054: Appliance Mode (Hotadd) Requirements and Troubleshooting
  VMware Tools must be installed and up-to-date on the Veeam server and any Veeam proxies
• Solution 2:
  Veeam KB1775: Removing Stuck VMDK From the Veeam Proxy
  Stuck Hotadded Disks – Review all virtual proxies for disks attached that do not belong to the VM in question, and remove the disks not owned by this VM without deleting them from the datastore. Once deleted, consolidate snapshots on the affected VMs.
• Solution 3:
  VMware KB1002310: Consolidating/Committing snapshots in VMware ESXi
  Orphaned Snapshots – Consolidate snapshots on affected VMs
• Solution 4:
  Veeam Backup & Replication - Permissions for VMware vSphere Guide
  Permissions - Please configure the account leveraged to access the vCenter as an Administrator within vCenter
• Solution 5:
  Automount – In some cases, it may be necessary to perform an automount scrub to clear any existing mount points that are no longer in the system.
  
  Run the following via CMD Prompt on the proxy server:

  diskpart
  automount disable
  automount scrub
  exit
  

• Solution 6:
  Veeam Latest Product Updates
  Patching – Please ensure that all VMware and Veeam components are fully up to date.
• Solution 7:
  In some rare instances, performing a storage vMotion has been known to resolve the issue due to a locked VM file on the datastore where the VM files reside.
• Solution 8:
  In some rare instances, restarting the vCenter appliance or alternatively restarting the ESXi management agents (VMware KB1003490: Restarting the Management agents in ESXi) may yield positive results if all above testing does not resolve the issue.
• Solution 9:
  Veeam Proxy has a Veeam replica with the same bios UUID within the vCenter Server. The following can be observed in 
  
  Job.Job_name.log:

  [time stamp] < threadID> Info VM VeeamProxy _replica(vm-100001) has the same bios uuid as proxy VeeamProxy.local in the DB
  

  Agent.Job_name.VM_name.Hotadd.Attacher.log:

  [time stamp] < threadID> vdl| [vddk] time stamp error -[07132] [Originator@6876 sub=transport] Cannot use mode hotadd to access [datastore_name] VM_name/VM_name.vmdk: Cannot mount using this method. (Mounting VM vm-101 using transport hotadd failed : Cannot access datastore for one of the disks of Virtual Machine VM_name..)
  

  The behavior is observed when a Veeam Proxy is replicated with Veeam B&R. The replication process preserves the original VM bios UUID for restore purposes. To work around the issue, set up a dedicated VM as a Veeam Proxy. Replicating Veeam Proxies is not usually necessary due to ease of deployment.
  
  More information: Veeam KB2159: Appliance Mode (Hotadd) isn't available if proxy VM and its replica are running under the same vCenter

• Solution 10:
  Veeam KB2305: HotAdd Error: Failed to allocate SCSI target ID
  In some rare cases, you may encounter a limitation for the number of disks attached to the virtual SCSI controller (max. 15 disks). In this case, you may try to add another SCSI controller to the proxying server in use by the job. Please keep in mind that there's a limitation for the amount of SCSI controllers - 4 per VM.
  
• Solution 11:
  VMware KB2151091: HotAdd mode throws error while using SATA controller with proxy virtual machine
  Known issue with vSphere 6 or later when a proxy has a SATA Controller present.
  
  
• Solution 12:
  
  In some rare instances, while using Hot-add Mode, the disk is successfully added to the proxy VM. However, the disk is not visible under Disk Management. No errors appear in Event Logs regarding the disk being added, and no errors show on vSphere. In this situation, Hot-Add mode cannot be used due to an issue with the virtual SCSI controller.
  
  In order to identify this specific scenario:
  
  1. Perform a manual hot-add. Veeam KB1184: How to manually test hotadd functionality
  2. Task will be successful on the vSphere side. The disk is visible within the proxy VM settings in vSphere. However, the added disk does not appear in disk management of the proxy VM.
  3. The issue is related to a VMware infrastructure issue; review the list of VMware articles below. If this issue persists, it is advisable to contact VMware Support for further investigation.
     • VMware KB2135969: Modifying the SCSI controller on a virtual machine changes the order of the hard disks in VMware vSphere ESXi
     • VMware KB2048497: SCSI disk enumeration order for virtual machines in the vSphere Client
     • VMware Documentation: Troubleshoot Problems Detecting Generic SCSI Devices

Using Transport Mode: Direct SAN

• Solution 1:
  When receiving VDDK Error 13 when leveraging DirectSAN access mode, please confirm that the LUNs are presented to the proxy correctly and have the proper permissions. For assistance deploying & troubleshooting DirectSAN, please follow the below KB articles:
  Veeam KB1895: Direct-SAN Transport mode – Requirements and Troubleshooting

Additional Troubleshooting

• Deploy an additional standalone proxy to isolate failures to a single specified proxy
• To isolate a specific transport mode as the point of failure, you may also test the other transport modes to ensure that connectivity is correctly established and backup jobs work as intended via the other transport mode.