Administrator rights do not grant access to a file. They grant the ability to take ownership of it, and ownership is what lets you rewrite the permissions. That distinction is the whole reason takeown exists, and it is why “I am an admin, why is this access denied” is such a common question.
The usual encounters are a folder left behind by a deleted user account, a profile directory from a decommissioned server, or a data volume moved from a machine whose SIDs no longer resolve. Explorer offers a dialog for this. On a share with fifty thousand files, that dialog is not an option.
takeown changes the owner and nothing else. Handing access back to the people who should have it is a separate step, done with icacls. Treating those as one action is where most of the damage in this area comes from.
Applies to: Windows 10 / 11 and Windows Server 2016 / 2019 / 2022 / 2025
Quick answer
Back up the existing permissions first, take ownership, then grant access explicitly. Three commands, in that order, every time.
rem 1. Save the current ACLs so the change can be undone
icacls C:\Data\Orphaned /save C:\bat\orphaned-acl.txt /t
rem 2. Take ownership for the Administrators group, recursively
takeown /f C:\Data\Orphaned /r /d Y /a
rem 3. Grant access to the group that should actually have it
icacls C:\Data\Orphaned /grant "CORP\FileAdmins:(OI)(CI)F" /tAll three need an elevated prompt. Step 1 costs a few seconds and is the only thing standing between a mistake and a restore from backup.
What takeown does
Every NTFS object has an owner recorded in its security descriptor. The owner can always rewrite the object’s permissions, even when the ACL denies them everything. Administrators hold the Take Ownership privilege, which is the right to make themselves that owner. takeown exercises it.
| Parameter | What it does |
|---|---|
/f <path> | The file, folder or wildcard pattern to act on. Required. |
/a | Gives ownership to the Administrators group instead of the current user. |
/r | Recurses into subdirectories. |
/d {Y|N} | Answers the prompt for directories the current owner cannot list. Only valid with /r. |
/s <computer> | Targets a remote machine. |
/u, /p | Credentials for the remote machine. |
/a. Without it, ownership goes to whichever account is running the command. Six months later the owner of a production data folder is a person who has left the company. The Administrators group does not leave.
Practical examples
1. Access denied on a folder you own on paper
The problem: C:\Data\Orphaned refuses to open even from an elevated prompt. The Security tab shows an unresolved SID instead of a name, which means the account that owned it no longer exists.
The solution: Confirm the owner, then take it. dir /q shows ownership without opening any dialog.
rem /q adds the owner column to the listing
dir /q C:\Data
rem Take ownership of the single folder, for the Administrators group
takeown /f C:\Data\Orphaned /aSUCCESS: The file (or folder): "C:\Data\Orphaned" now owned by the administrators group.Note what has and has not changed. You are now the owner. You still have no permissions, and the folder still will not open until you grant some.
2. A whole tree, without answering a prompt per folder
The problem: The same situation across a departmental share with thousands of subfolders. Run recursively without /d and the command stops at every directory it cannot read, waiting for input.
The solution: /r recurses and /d Y answers the prompt in advance. Save the ACLs first, because this is the point of no return.
rem /t saves ACLs for the whole tree, not just the top folder
icacls D:\Shares\Finance /save C:\bat\finance-acl.txt /t
rem Ownership for the whole tree; /d Y answers the directory prompt automatically
takeown /f D:\Shares\Finance /r /d Y /a > C:\bat\takeown.log 2>&1
rem How many objects it actually touched
find /c "SUCCESS" C:\bat\takeown.log/d Y takes ownership of the directory and replaces its permissions with full control for the user. Whether or not that fires in a given tree, the safe assumption is that a recursive takeown can change more than the owner. The saved ACL file is what makes it reversible: icacls D:\Shares /restore C:\bat\finance-acl.txt.
3. Give the access back
The problem: Ownership is fixed and the folder is still unusable for the department that needs it.
The solution: Grant explicitly, with inheritance flags, then verify. Ownership without an ACL entry is not access.
rem (OI) object inherit, (CI) container inherit, F full control
rem Together they mean: this folder, its subfolders and its files
icacls D:\Shares\Finance /grant "CORP\Finance-RW:(OI)(CI)M" /t
rem Read back what is now in place
icacls D:\Shares\FinanceM grants modify rather than full control, which stops the group from rewriting permissions later. Reserve F for administrators.
4. Undo it
The problem: The change was applied to the wrong tree, or the grant was too broad and needs to go back to how it was.
The solution: Restore the saved ACL file. The restore is applied to the parent directory of the tree that was saved, not to the tree itself.
rem Note the path: the parent of the folder whose ACLs were saved
icacls D:\Shares /restore C:\bat\finance-acl.txt
rem Ownership is not part of the ACL file; set it back explicitly if needed
icacls D:\Shares\Finance /setowner "CORP\Domain Admins" /ticacls /setowner can change ownership too, and it does not need takeown first when you already have the right to write the security descriptor. takeown is what you use when you do not.
Hidden gems
Ownership is not access. This is the single most misunderstood point. Taking ownership gives you the right to change the ACL. Until you actually change it, the folder still refuses to open. Half of the “takeown did not work” reports are this.
dir /q is the fastest owner report there is. No dialog, no PowerShell, no properties tab. It prints the owner next to every entry, which makes spotting orphaned SIDs across a folder a two second job.
Redirect the output or lose it. A recursive run prints one SUCCESS line per object. On a large tree that scrolls past in seconds and takes the errors with it. Send it to a file and count the failures afterwards.
Long paths still bite. Paths beyond 260 characters are skipped with an error rather than handled. Map a drive letter closer to the deep folder with subst, or work from a UNC path, and run it again for the remainder.
It does not work on system-protected objects. Files owned by TrustedInstaller under C:\Windows will hand over ownership and then break servicing, because Windows Update expects TrustedInstaller to own them. If a system file needs replacing, DISM and SFC are the supported route, not takeown. The sfc guide covers that path.
PowerShell equivalent
PowerShell can set an owner, but only when the account already has the right to write the security descriptor. When it does not, the privilege has to be enabled first, which is why takeown remains the practical answer for the locked-out case.
# Read the current owner without changing anything
Get-Acl C:\Data\Orphaned | Select-Object Path, Owner
# Set the owner to the Administrators group
$acl = Get-Acl C:\Data\Orphaned
$group = New-Object System.Security.Principal.NTAccount("BUILTIN\Administrators")
$acl.SetOwner($group)
Set-Acl -Path C:\Data\Orphaned -AclObject $acl
# Find every folder in a tree whose owner no longer resolves to a name
Get-ChildItem D:\Shares -Directory -Recurse |
ForEach-Object { $o = (Get-Acl $_.FullName).Owner; if ($o -match '^S-1-5-21') { $_.FullName } }S-1-5-21-... SID is an account that no longer exists in the directory. That is the reliable way to find orphaned data across a file server.
Where this matters
- Leavers. A home directory or project folder owned by a deleted account, which nobody can open and nobody wants to delete without reading first.
- Disks moved between servers. The SIDs came from another domain, so every ACL entry is unresolved and every folder is inaccessible.
- Restores from old backups. Archive data restored with its original security descriptors intact, referencing accounts that were removed years ago.
- Migration cleanup. After a file server migration, an audit of unresolved owners tells you which trees still carry the old domain’s identities.
- Ransomware and incident recovery. Regaining control of a tree whose ACLs were rewritten, where the saved ACL file from before the incident is the difference between a restore and a rebuild.
Tips and limitations
- Always run from an elevated prompt. Without elevation the Take Ownership privilege is not in the token and the command fails with access denied.
/dis only valid together with/r. On a single folder it is ignored.- Taking ownership is logged only if object access auditing is enabled. On a file server holding regulated data, enable it before you need the evidence.
- The command works on NTFS and ReFS. It has nothing to say about share permissions, which are evaluated separately and are the other half of a network access problem.
- Never point it at
C:\,C:\WindowsorC:\Program Fileswith/r. Servicing depends on TrustedInstaller ownership, and the damage is not repaired by handing ownership back.
Official documentation
Related tools
- ROBOCOPY Command Builder: builds the copy that comes after the ownership fix, including the switches that carry security descriptors across.
- Windows Event Log Analyzer: for reading the object access events that record who took ownership of what.
Related guides
- net use in Windows: mapped drives, credentials and error 1219: reaching the share with the right identity before touching ownership.
- ICACLS command in Windows: the other half of every ownership fix.
- attrib command in Windows: view and change file attributes: for the read-only, hidden and system flags that sit alongside permissions.
- ROBOCOPY command in Windows Command: moving the data once you can read it again.