I've just done an in-place upgrade of a Hyper-V guest from Windows Server 2008 to Server 2012 R2 (via Server 2012, as direct upgrade from 2008 to 2012 R2 is not supported). Usually one would create a new machine and seize roles, which is Microsoft's officially "preferred" option, but for organisational reasons this isn't possible. This is a test run, on a copy of the original VM disconnected from network.

All appears okay except one of the 3 data drives (separate VHDX files) shows "Access Denied" when double-clicking to open the drive in Windows Explorer. However, I can list directories and view files from the command line!

Steps taken to resolve:

  • Double checked Hyper-V guest settings exactly the same as the production server
  • run chkdsk within the VM, no errors found
  • disk management shows healthy active primary partition (interestingly this is the only disk with unallocated space the beginning, perhaps this is relevant?)
  • also relevant: the disk cannot be marked as offline, and it was previously host to the pagefile
  • moved pagefile to C:\ (now the disk can be brought offline in disk management)
  • took disk offline then online again
  • removed drive letter assignment and re-added
  • backed up shares from registry, shutdown VM, disconnected the VHDX in question, rebooted, shutdown, re-connected the VHDX
  • created a new volume in the unallocated space before the volume in question on that disk, then deleted it
  • re-copied the VHDX file for this drive from the production server, in case the VHDX became corrupt during the original copy
  • last ditch, I took ownership and re-permissioned the drive (this folder, all subfolders and files), and applied to child objects. Still getting "Access denied", indicating it's not an ACL (file permissions) related issue

This doesn't affect any other drives, including the system drive.

I haven't yet robocopied data to a new drive as I want to understand the root cause.

What should I try next?


Since you are using a data drive on a server, I'm going to go ahead and assume that you are using it as a shared device?

If so, there are the NTFS permissions, but also share permissions. Best practice is to give everyone all permissions on share level, and write your permission policy to the NTFS permissions.

Perhaps the share permissions are restrictive?

  • I'm aware of the difference between NTFS and share permissions and always set share permissions to Everyone. But this isn't relevant as the question is about my inability to access the files and directories on the server disk itself. Apologies if I didn't make that clear in my question. – hazymat Jun 25 '17 at 20:54

I had the same problem. The quick fix for me was to add the Everyone group back in for "This folder only" to the drive root with: Read & Execute, List folder contents and Read permissions (Drive properties / security / advanced).

In my case this issue was caused by bad practice on my part by pointing the SQL 2016 installer log file location at the root of a drive rather than creating a subfolder. The installer then strips our unnecessary permissions and Windows Explorer access is blocked.

  • You should provide more specifics, like what folder did you change the permissions on, because your answer does not make that clear. – Ramhound Jun 13 '17 at 15:14
  • My answer does actually make that clear - "...to the drive root" – sutra Jun 13 '17 at 15:17
  • I have never refered to the root directory of a drive as the "drive root" in my 25 years using a computer. I am trying to give you feedback on how to improve your answer. – Ramhound Jun 13 '17 at 15:54
  • @Ramhound I'd say "drive root" and "root of drive" are synonymous. I understood Sutra's point. That said, it doesn't address the question, because, as stated, I've already completely re-permissioned the drive and state "...indicating it's not an ACL (file permissions) related issue" – hazymat Jun 15 '17 at 9:56

UAC is the culprit in that scenario.

When you log on with a user that belongs to the machine local Administrators group, UAC give that user two different tokens, "a full administrator access token and a "filtered" standard user access token" ... "The standard user access token is then used to launch the desktop (Explorer.exe)".

UAC is Modifying Your Administrative Permissions

You have at least two options to tackle that setback:

  1. Getting to the resource across the network as UAC doesn't take effect in that scenario.
  2. Creating new security groups and giving access them NTFS permissions.

In the case that you don't have NTFS permissions for that resource, you could run a Windows File Explorer elevated,

How to Run File Explorer Elevated

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.