You copied a profile off an old disk, or inherited a share from someone who left, and every folder answers with Access is denied — even as an administrator. The fix is to take folder ownership of the whole tree, and then, in a second step that most guides forget, to actually grant yourself permissions on it.
Back up the ACLs first
Thirty seconds, and it is the only way back if something goes wrong:
icacls "C:\folder\subfolder" /save %TEMP%\acl-backup.txt /t /c
Restore with icacls "C:\folder\subfolder" /restore %TEMP%\acl-backup.txt /t /c. The next section explains why this is not paranoia.
takeown syntax and parameters
takeown [/s <Computer> [/u [<Domain>\]<User name> [/p [<Password>]]]] /f <File name> [/a] [/r [/d {Y|N}]]
Run it from an elevated prompt. It needs SeTakeOwnershipPrivilege, which is granted to Administrators but only present in an elevated token — whoami /priv will show you whether you actually have it right now.
| Parameter | Description | |
|---|---|---|
/s <Computer> |
Name or IP address of a remote computer (no backslashes). Defaults to the local computer, and applies to every file and folder in the command. | |
/u [<Domain>\]<User name> |
Run with the permissions of that account. Defaults to system permissions. | |
/p [<Password>] |
Password for the account given in /u. |
|
/f <File name> |
File or directory name pattern. * works, and so does ShareName\FileName. |
|
/a |
Gives ownership to the Administrators group instead of the current user. Without it, ownership goes to the account you are logged on as. | |
/r |
Recursive: every file in the directory and its subdirectories. | |
| `/d {Y\ | N}` | Answers the confirmation prompt shown when you lack List Folder and Read on a directory. N skips the directory. Y takes ownership — and, in Microsoft's own words, "the directory permissions are replaced with permission granting the user full control only". Only meaningful together with /r. |
/? |
Help. |
Full reference: takeown and icacls on Microsoft Learn. Note one documented limitation while you are there: patterns mixing ? and * are not supported by takeown.
Taking folder ownership does not grant permissions
This is the part that sends people back to the search box. takeown changes who owns the object. On a directory you could already read, it adds nothing to the ACL — so a folder you now own can still refuse to open. Microsoft says as much in its own remarks: after taking ownership you may still have to give yourself full permissions before you can use the files.
Folder ownership only means you have the right to rewrite the ACL. You still have to do it:
takeown /f "C:\folder\subfolder" /a /r /d Y
icacls "C:\folder\subfolder" /grant *S-1-5-32-544:(OI)(CI)F /t /c
The one exception is /d Y. On a directory you could not list, takeown does rewrite the ACL — replacing it with a single entry granting full control to you. That is precisely the directory you are running this on, and precisely why the ACL backup above is worth the thirty seconds.
A few things about that second line:
*S-1-5-32-544is the SID of the built-in Administrators group. Use the SID, not the name: on a German, French or Romanian Windows the group is called something else and/grant Administrators:Ffails with No mapping between account names and security IDs was done.(OI)(CI)makes the entry inheritable by files and subfolders, so children inherit it instead of each getting its own explicit copy./grantadds an entry;/grant:rreplaces the existing one for that account. Run the un-suffixed form twice and you get two identical ACEs./twalks the tree and/ccontinues past files that error./tis still needed where children have inheritance disabled or already carry explicit entries.- Prefer
/aplus a grant to Administrators over granting to yourself. The next person to inherit the folder will be an administrator too, and ownership that belongs to a group survives the account being deleted. If you do want it on your own account, write"%USERDOMAIN%\%USERNAME%":F— a bare username can resolve to the wrong, local principal on a domain-joined machine.
Verify it worked
dir /q "C:\folder\subfolder"
icacls "C:\folder\subfolder"
dir /q prints the owner next to each entry — that is your proof the folder ownership change took effect. icacls with no switches prints the ACL, which is your proof the icacls /grant did.
Three things that go wrong
Never take ownership of C:\Windows or C:\Program Files
Those trees are owned by TrustedInstaller by design. Taking folder ownership across them breaks Windows servicing: updates that expect to replace a file they own start failing, and the damage is tedious to undo. Scope the command to the directory you actually need.
If you already ran it somewhere you should not have, takeown cannot put the owner back — it can only assign to you or to Administrators. Use icacls "C:\path" /setowner "NT SERVICE\TrustedInstaller" /t /c for the owner, and icacls "C:\path" /reset /t /c to drop the explicit entries and re-inherit.
"Access is denied" during a recursive run
Usually a file is open, or a directory denied you List Folder and the prompt was skipped. /d Y answers that prompt for the whole run; files still in use need the process closed, or a reboot.
Paths longer than 260 characters fail
Both tools fail per item with The system cannot find the path specified or The filename or extension is too long — not silently, but easy to miss in a long scroll, which is why the processed count comes out short. The dependable fix is to shorten the path before you start: subst X: "D:\deep\tree" or a junction, run both commands against the short path, then remove it.
/s against a remote machine
takeown /s fails with Access is denied when you authenticate with a local account rather than a domain one: UAC remote restrictions strip the administrative token before takeown ever runs. The registry value that fixes it is the same one described in creating a user on a remote workstation with PsExec — set LocalAccountTokenFilterPolicy to 1 on the target. Domain accounts are not affected.
