0

Problem

Another administrator was attempting to give a user access to a subfolder on then secondary drive (D:) of a Windows Server 2019 Core VM. Instead he somehow locked everyone out, including other Administrators. Trying to navigate or perform most actions on the D: directory results in an "Access is Denied" error.

Solutions and Commands We've Tried

Any variation of the following commands:

  • Takeown (ex. takeown /F d: /r /d y)
  • ICACLS (ex. idacls D:, icacls "D:" /Reset /T /C /L /Q)
  • Get-ACL
  • Additionally, I've tried installing pstools, elevating myself to system via psexec /ids cmd or psexec -i -s cmd.exe and running the same barrage of commands.

All return: "Access is denied".

Finally I tried installing the PowerShell Module called NTFSSecurity Using this module, I executed the following cmdlet:

Get-ChildItem -Path D:-Recurse -Force | Set-NTFSOwner -Account '<my AD administrator account>'

From here I was able to access the D:\ drive, but after attempting to run a second cmdlet to try to reset the entire directory:

Get-ChildItem -Path C:\Temp -Recurse -Force | Clear-NTFSAccess

I seem to have lost access again. Running the first NTFSOwner cmdlet does not fix the access issue.

Further NTFSSecurity Information

  • Running Get-NTFSOwner D: returns BUILTIN\Administrators as the owner.
  • Running Get-NTFSAccess D: returns a fair amount of information, including that D:\ has inheritance enabled, and that both NT AUTHORITY\SYSTEM and BUILTIN\Administrators have FullControl Access Rights to D:\, but none of it's subfolders.
  • I successfully gave my AD account access via the Add-NTFSAccess command, with Full Control over D: and all subfolders, but I'm still unable to access the drive.

All AD Administrative accounts should have full reign over the system, but we all seem to be locked out. I'm personally at a loss here, but there has to be something I'm missing. I was able to get access to D: after initially running the NTFSOwner cmdlet but, regrettably, it seems I may have ruined that after clearing NTFS-Access.

Any help would be greatly appreciated.

Improve this question
6
  • This is really not a PowerShell code issue, but and environment issue caused by user actions. So, not really sure what the Powershell tag/post. This sounds like you are not using snapshots of your VM's/Datastores on a scheduled basis. If you are, you can always snap back to the previous date before these changes occurred. I've not encountered where you are (as it sounds like you all were just trying everything you could), but, at this time, if you can't snap back, and all else has failed, you are then into a full data drive restore effort.
    – postanote
    Commented May 6, 2020 at 20:19
  • So, are you saying, when you go to Windows Explorer, right-click the drive and try and set permissions via the GUI, it fails as well? well, you'd have to enable temporarily the GUI on that Server Core host first.
    – postanote
    Commented May 6, 2020 at 20:21
  • I tagged PowerShell because I can really only use Command Prompt or PowerShell to try to fix this issue. Running explorer.exe seems to be pretty barebones. Right-click, properties on the C: Drive exposes the normal properties window we're all used to, but with no Security tab or anything. Doing the same thing on the D: Drive displays the same window, but displays no information. We can't even read the used and free space on the disk. @postanote
    – Alcolawl
    Commented May 6, 2020 at 20:57
  • This server is under the control by another part of the company, but as a last resort it was escalated to engineering for help. So, I agree there should have been backups or a snapshot of this VM prior to the technician working on this VM, but they didn't think to do that... Trust me, a snapshot would've been standard operating procedure on this side of the house. I'm leaning towards a rebuild as well, but I found this problem to be interesting and wanted to see if there were any other commands or tools I was missing to try to rectify the issue before doing that.
    – Alcolawl
    Commented May 6, 2020 at 20:58
  • Ouch!!!... this hopefully will engender that need for more concise change management, and DR efforts to ease this pain level in the future.
    – postanote
    Commented May 6, 2020 at 21:03

0

Reset to default

You must log in to answer this question.