TL;DR — Quick Summary

Fix Hyper-V 'General access denied error' (0x80070005) when loading a Virtual Hard Drive. Reset VHD/VHDX permissions via Hyper-V Manager or PowerShell.

Note: This article was originally published in 2014. Some steps, commands, or software versions may have changed. Check the current Hyper V documentation for the latest information.

Error: General access denied when loading a Virtual Hard Drive

If you have recently moved, restored, or copied Virtual Machine storage files (VHD or VHDX) from one physical location to another, you might find that the VM refuses to start.

When you attempt to boot the virtual machine from Hyper-V Manager, you are greeted with a variation of the following error:

Hyper-V Manager An error occurred while attempting to start the selected virtual machine(s). ‘VMName’ failed to start. ‘VMName’ Microsoft Emulated IDE Controller: Failed to Power on with Error ‘General access denied error’ (0x80070005). ‘VMName’: Account does not have sufficient privilege to open attachment ‘C:\Users\Public\Documents\Hyper-V\Virtual hard disks\DiskName.vhdx’. Error: ‘General access denied error’ (0x80070005).

Why does this happen? (The Problem)

The exact root cause stems from NTFS security permissions. Every Virtual Machine in Hyper-V operates under a unique security principal (a hidden Virtual Machine ID account).

When a VHD or VHDX file is properly attached to a VM, Hyper-V automatically grants this unique VM ID account explicit Read and Write permissions to the physical file on your hard drive.

However, if you manually copy, paste, or move the .vhdx file using Windows Explorer instead of using Hyper-V’s built-in “Move” wizard, those specific file permissions are stripped and lost. Without them, the Hyper-V service is literally denied access to read its own hard drive.

The Solutions

To fix this, we need to re-grant the VM account the rights it needs to open the hard drive.

We do not recommend attempting to right-click the file and manually add standard Windows user permissions, as the VM IDs are hidden and complex to map correctly.

Instead, use one of the two official methods below to force Hyper-V to repair the ACLs (Access Control Lists) automatically:

The easiest and safest way to fix the permissions is to simply remove the disk from the VM configuration and re-add it. Every time you attach a disk, Hyper-V automatically executes the required kernel commands to give the VM account full permissions to the file.

  1. Open Hyper-V Manager.
  2. Right-click the broken Virtual Machine and select Settings.
  3. Under Hardware, click on the Hard Drive that is throwing the error.
  4. Click the Remove button, then click Apply (Don’t worry, this does not delete the file, it only detaches it).
  5. Now, click on the IDE Controller or SCSI Controller on the left menu.
  6. Select Hard Drive and click Add.
  7. Browse to your .vhdx file, select it, and click OK.
  8. Start the VM. It should now boot perfectly.

Method 2: Fix via PowerShell

If you manage a large Hyper-V cluster or need to fix this across multiple VMs, you don’t want to use the GUI. You can use PowerShell to detach and re-attach the disk, which achieves the exact same permission reset.

Open PowerShell as Administrator and run the following commands (replace the VM name and path):

# 1. First, remove the inaccessible disk from the VM
Remove-VMHardDiskDrive -VMName "Your_VM_Name" -ControllerType IDE -ControllerNumber 0 -ControllerLocation 0

# 2. Re-add the exact same disk to force Hyper-V to restore the ACL permissions
Add-VMHardDiskDrive -VMName "Your_VM_Name" -ControllerType IDE -ControllerNumber 0 -ControllerLocation 0 -Path "C:\Path\To\Your\DiskName.vhdx"

Note: Change -ControllerType IDE to SCSI if this is a Generation 2 VM.

After running the commands, the 0x80070005 error will be resolved.