Quick fix: Open Terminal (Admin), run takeown /F "C:\path\to\folder" /R /A /D Y followed by icacls "C:\path\to\folder" /grant administrators:F /T — administrators now have full rights to read, modify, and delete the folder’s contents.

You need to modify or delete files inside a system folder — but even as administrator you get “Access Denied” or “You need permission from TrustedInstaller.” The fix is to transfer ownership of the folder from TrustedInstaller (Windows’ install-time account) to your administrator group, then grant the group full control. Done carefully, this is safe; done wrong, you can break Windows’ ability to update itself.

Symptom: Need to modify or delete files inside a protected system folder; administrator rights aren’t sufficient.
Affects: Windows 11 (and Windows 10) protected system folders like Program Files subfolders, Windows.old, certain registry-backed paths.
Fix time: ~5 minutes per folder.

What causes this

NTFS files and folders have an owner (one specific account) and an ACL (list of accounts and their rights). Many system folders are owned by NT SERVICE\TrustedInstaller — the account Windows Setup uses to install system files. The administrator group can read but not modify these folders. takeown transfers ownership; icacls grants modification rights.

Important caveat: changing ownership of a system folder can prevent Windows Update from servicing it correctly. The right protocol is to take ownership, do your work, then optionally restore ownership to TrustedInstaller.

Method 1: Take ownership and grant administrator rights (recommended)

The standard two-step process.

Open Terminal (Admin) from the Start right-click menu.
For a single file:
```
takeown /F "C:\path\to\file.ext" /A
icacls "C:\path\to\file.ext" /grant administrators:F
```
The /A flag assigns to the Administrators group rather than just your account; :F means Full control.
For an entire folder and all its contents:
```
takeown /F "C:\path\to\folder" /R /A /D Y
icacls "C:\path\to\folder" /grant administrators:F /T
```
/R recurses; /A assigns to Administrators; /D Y auto-confirms recursion; /T recurses for icacls.
Verify the change:
```
icacls "C:\path\to\folder"
```
The output should show BUILTIN\Administrators:(F) in the access list.
Now perform your modification, deletion, or copy operation.

The folder remains accessible as administrator until you restore ownership (Method 3).

Method 2: Use GUI for one-off operations

Slower but doesn’t require memorizing command syntax.

Right-click the file or folder → Properties → Security tab.
Click Advanced at the bottom of the dialog.
Next to Owner, click Change.
In the “Enter the object name” field, type Administrators. Click Check Names. The name resolves to YourPCName\Administrators. Click OK.
For folders, tick Replace owner on subcontainers and objects.
Click OK. A progress dialog may appear briefly.
Reopen the Security tab if needed. Click Edit.
Select Administrators, tick Full control, click OK.
Now perform your operation.

This is the right approach for users uncomfortable with command line. Same end result as Method 1.

Method 3: Restore TrustedInstaller ownership after the work is done

Important hygiene step. Without restoring ownership, Windows Update may fail to apply patches to files in the modified folder.

Open Terminal (Admin).

Restore ownership:

icacls "C:\path\to\folder" /setowner "NT SERVICE\TrustedInstaller" /T

For some folders, you also need to reset the ACL to defaults to restore the original protection:
```
icacls "C:\path\to\folder" /reset /T
```
Verify:
```
icacls "C:\path\to\folder"
```
The output should show NT SERVICE\TrustedInstaller as the owner again.
After this, you again won’t be able to modify the folder without first taking ownership again — that’s the intended behavior.

Always restore ownership unless the folder is going to be deleted entirely. Long-running modified ownership on system folders accumulates and can interfere with future Windows servicing.

How to verify the fix worked

Run icacls "C:\path\to\folder" in Terminal. The expected ACL is set.
The file or folder operation you needed (modify, delete, copy) succeeds without “Access Denied”.
If you restored ownership in Method 3, attempting to delete the folder now produces a permission prompt again — confirming TrustedInstaller is back in charge.

If none of these work

If takeown reports “Access denied” even from an elevated prompt, three causes apply. The folder is mounted from an offline image: ownership commands need the image to be online — restart Windows and retry from a normal admin session. The folder is on a different drive with read-only attributes: check with attrib "C:\path" and remove read-only with attrib -R "C:\path" /S /D. The folder has special protection from group policy or EFS: a domain admin may have applied a policy that blocks ownership changes; you can’t override this from a regular admin account. For folders inside C:\System Volume Information (System Restore data), ownership changes are blocked by design — use vssadmin delete shadows /for=C: /all /quiet to remove shadow copies instead of trying to delete individual files. For encrypted files, you need to either decrypt them first (right-click → Properties → Advanced → uncheck Encrypt contents) or have the encryption key — even taking ownership won’t let you read encrypted content.

Bottom line: Taking ownership of a system folder is a two-line operation — takeown + icacls. Always restore TrustedInstaller ownership when you’re done so future Windows Updates can service the folder normally.