VDDK error: 13 - Troubleshooting

Challenge

Solution

Below is a list of possible solutions to this issue sorted by what transport mode was being using 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:
  In some instances, 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
  http://www.veeam.com/kb1198

• Solution 1:
  https://www.veeam.com/kb1054
  VMware Tools must be installed and up-to-date on the Veeam server and any Veeam proxies
   
• Solution 2:
  https://www.veeam.com/kb1775
  Stuck Hotadded Disks – Review all virtual proxies for disks attached that do not belong to the VM in question, remove the disks not owned by this VM without deleting from the datastore. Once deleted, consolidate snapshots on the affected VMs.
   
• Solution 3:
  kb.vmware.com/kb/2003638
  Orphaned Snapshots – Consolidate snapshots on affected VMs
   
• Solution 4:
  http://www.veeam.com/kb1875
  Permissions - Please configure the account leveraged to access the vCenter as an Administrator within vCenter
   
• Solution 5:
  http://www.veeam.com/kb1882
  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:
  http://www.veeam.com/patches.html
  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 (https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003490) 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 setup a dedicated VM as a Veeam Proxy, replicating Veeam Proxies is not usually necessary due to ease of deployment.

• Solution 10:

More Information