Take Ownership Windows File: Fixing a Stubborn Delete Error

Windows sometimes refuses to let you delete or move a file even when you’re logged in as an administrator — usually because the file’s ownership belongs to a different account (System, TrustedInstaller, or another user entirely) and admin group membership alone doesn’t override that.

Steps

1. Click Start, type cmd, then right-click Command Prompt and choose Run as Administrator.
2. Take ownership of the file:

takeown /F "C:\PathToFile.ext"

3. Grant your administrators group full control:

icacls "C:\PathToFile.ext" /grant administrators:F

After both commands complete successfully, you’ll have full ownership and permissions over the file and can delete, move, or edit it as needed. For a whole folder rather than a single file, add /R to both commands to apply the change recursively to every file and subfolder underneath it.

Why This Happens in the First Place

Ownership and permissions are two separate things in Windows — being a member of the Administrators group grants you broad rights, but it doesn’t automatically make you the owner of every file on the system. Files created by the System account (Windows Update components, some driver files), by TrustedInstaller (core OS files under Windows Resource Protection), or by another user profile entirely all keep their original owner until something explicitly changes it — which is exactly what takeown does.

The PowerShell Equivalent

If you’d rather do this from PowerShell than Command Prompt, the same two-step process looks like this:

$acl = Get-Acl "C:\PathToFile.ext"
$acl.SetOwner([System.Security.Principal.NTAccount]"$env:USERDOMAIN$env:USERNAME")
Set-Acl "C:\PathToFile.ext" $acl
icacls "C:\PathToFile.ext" /grant administrators:F

In practice takeown/icacls remains the quicker route for a one-off fix, but the PowerShell version is worth knowing if you’re already scripting a wider permissions-remediation task.

If It Still Won’t Delete

Taking ownership fixes the vast majority of “administrator denied” delete errors, but if the file is still locked afterwards, check whether another process has it open (Resource Monitor’s CPU tab has a “Search Handles” box for exactly this), or whether it’s a system-protected file guarded separately by Windows Resource Protection — in which case ownership alone won’t be enough and modifying it isn’t recommended unless you know exactly why you need to.