Fix Windows 'Access is denied' Error When Running Commands as Admin

TL;DR

Right-click your terminal → Run as administrator. Still blocked? Take ownership of the target file or folder:

takeown /f "C:\path\to\file" /r /d y
icacls "C:\path\to\file" /grant %USERNAME%:F /t

That covers 90% of cases. Keep reading if it doesn't.

Why This Happens

Windows's Access is denied doesn't mean your password is wrong. It means the permission check failed at the OS level. There are five distinct reasons this can happen, and each needs a different fix:

• Not running elevated — your terminal opened without admin privileges even though your account is an Administrator.
• UAC split-token — Windows runs admin accounts with a restricted token by default. A process needs explicit elevation to get full admin rights.
• You don't own the file — system files, files created by another user, or files owned by TrustedInstaller block writes even for admins.
• ACL explicitly denies you — a Deny ACE overrides any Allow rule, including admin group membership. This one trips up a lot of people.
• File is locked — another process holds an exclusive lock. The permission check passes but the I/O is blocked at the file system layer.

Fix 1: Run CMD or PowerShell as Administrator

Happens constantly, even to experienced sysadmins. Being in the Administrators group doesn't automatically give you elevated privileges — your shell has to specifically request them.

• Press Win, type cmd or powershell, then right-click → Run as administrator.
• Or from an existing terminal: Start-Process powershell -Verb RunAs

Verify elevation worked — the title bar should say Administrator: Command Prompt. Double-check with:

whoami /groups | findstr "S-1-16-12288"

If that line appears, you have a high-integrity (elevated) token. No output means you're still running restricted.

Fix 2: Take Ownership of the File or Folder

System files and Windows Update artifacts are typically owned by SYSTEM or TrustedInstaller. Elevated admins still can't write to them without first taking ownership — that's intentional.

From an elevated CMD:

takeown /f "C:\path\to\target" /r /d y

Then grant yourself full control:

icacls "C:\path\to\target" /grant %USERNAME%:F /t /c

Flags: /t = recursive, /c = continue on errors, F = full control.

For a single system file (e.g., replacing a DLL):

takeown /f "C:\Windows\System32\somefile.dll"
icacls "C:\Windows\System32\somefile.dll" /grant Administrators:F

Verify: Run the original failing command again. Check current permissions with:

icacls "C:\path\to\target"

Fix 3: Remove an Explicit Deny ACE with PowerShell

A Deny entry in the ACL beats everything — including admin rights. You can't just add an Allow rule on top of it. You have to remove the Deny.

First, see what's actually in the ACL:

$acl = Get-Acl "C:\path\to\target"
$acl.Access | Format-Table IdentityReference, FileSystemRights, AccessControlType

Spot a Deny entry for your account or Users? Remove it:

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
  "BUILTIN\Users", "FullControl", "Deny"
)
$acl.RemoveAccessRule($rule)
Set-Acl "C:\path\to\target" $acl

Replace BUILTIN\Users and FullControl with whatever the deny entry actually shows.

Fix 4: Unlock a File Held by Another Process

Permissions check out but you're still getting blocked? A locked file is the usual culprit. Another process has it open with an exclusive lock, and Windows won't let you touch it until that process releases it.

Find the locking process with Sysinternals handle.exe:

# With Sysinternals handle.exe in PATH:
handle.exe "C:\path\to\file"

No Sysinternals? Use Resource Monitor instead: press Win+R → type resmon → CPU tab → Associated Handles → search the filename.

Close or kill the locking process, then retry your command.

Fix 5: Registry Key Access Denied

Registry errors under HKLM are a separate pain point. Elevation alone isn't enough — protected keys like HKLM\SAM or HKLM\SECURITY require you to take ownership first, just like files.

# Check current owner
$key = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey(
  "SOFTWARE\SomeKey", $true
)

# If that throws: take ownership via regedit
# Right-click key → Permissions → Advanced → Owner → change to your account

For quick scripted writes, skip the PowerShell API and use reg add from an elevated prompt:

reg add "HKLM\SOFTWARE\SomeKey" /v ValueName /t REG_SZ /d "data" /f

Fix 6: Scheduled Tasks and Services

Scheduler and service errors are a different beast. The problem usually isn't your permissions — it's the service account running the task. It doesn't have rights to the resource it's trying to access.

Change the service to run as LocalSystem (broad access) or pin it to a specific user:

sc.exe config ServiceName obj= "LocalSystem" password= ""

# Or for a specific account:
sc.exe config ServiceName obj= ".\YourUsername" password= "yourpassword"

Restart to apply:

net stop ServiceName && net start ServiceName

Quick Diagnostic Checklist

• Is the terminal elevated? (whoami /groups | findstr S-1-16-12288)
• Who owns the file? (icacls "path" — look for owner line)
• Any explicit Deny ACEs? (look for (DENY) in icacls output)
• Is the file locked? (Resource Monitor → Associated Handles)
• Is it a system-protected path? (e.g., C:\Windows\System32)

Tips

Working across Windows and Linux at the same time — WSL, cross-platform deployments, that sort of thing? The Unix Permissions Calculator on ToolCraft lets you work out chmod values visually before applying them. Handy when you need Linux file permissions to match what you're configuring on the Windows side.

Prevention

• Keep scripts that need elevation in a dedicated folder with a clear README — saves the "why is this failing again" loop.
• Use runas /user:Administrator cmd for one-off elevated commands without opening a new window manually.
• In CI/CD pipelines on Windows, always specify the agent service account and pre-grant it icacls rights to working directories before the first run.