takeown — Take File Ownership

What it is

takeown is a built-in Windows command that transfers ownership of a file or directory to the currently logged-on user or the Administrators group. NTFS ownership controls who can change the permissions (ACL) on an object — you cannot modify the ACL of a file you don't own or administrate. takeown is the command-line equivalent of Explorer → Properties → Security → Advanced → Change Owner. After taking ownership, use icacls to grant the permissions needed to read, write, or delete the object. Requires Administrator privileges.

Availability

takeown ships as C:\Windows\System32\takeown.exe on Windows Vista and later.

takeown /?

Output:

TAKEOWN [/S system [/U username [/P [password]]]]
        /F filename [/A] [/R [/D prompt]]

Description:
    This tool allows an administrator to recover access to a file that
    was previously denied, by making the administrator the owner of the
    file.

Syntax

takeown /F <file> [/A] [/R] [/D Y|N]
takeown /F <file> /S <host> [/U domain\user] [/P password]

Output: (success or error message per file)

Essential options

Taking ownership of a single file

/F specifies the target. Without /A, ownership transfers to the currently logged-on user account.

takeown /F C:\Windows\System32\drivers\etc\hosts

Output:

SUCCESS: The file (or folder): "C:\Windows\System32\drivers\etc\hosts" now owned by user "MYHOST\alicedev".

Assigning ownership to Administrators (/A)

/A assigns ownership to the built-in Administrators group rather than the current user. Prefer this in deployment scripts — any administrator can then manage the permissions without needing the specific account used during deployment.

takeown /F C:\SecureApp /A

Output:

SUCCESS: The file (or folder): "C:\SecureApp" now owned by the administrators group.

Recursive ownership change

/R descends into all subdirectories. /D Y automatically answers Yes to any per-item confirmation prompts, making the operation non-interactive — essential for scripts.

takeown /F C:\OldData /R /D Y

Output:

SUCCESS: The file (or folder): "C:\OldData" now owned by user "MYHOST\alicedev".
SUCCESS: The file (or folder): "C:\OldData\archive" now owned by user "MYHOST\alicedev".
SUCCESS: The file (or folder): "C:\OldData\archive\log.txt" now owned by user "MYHOST\alicedev".
...

Wildcards

/F accepts * to match multiple files in the same directory.

takeown /F "C:\Temp\*.log" /A

Output:

SUCCESS: The file (or folder): "C:\Temp\app.log" now owned by the administrators group.
SUCCESS: The file (or folder): "C:\Temp\error.log" now owned by the administrators group.

Recovering a locked system file

The typical recovery workflow for a locked or access-denied system file is: take ownership, then grant yourself Full Control with icacls, then perform the edit or deletion.

rem Step 1 — take ownership
takeown /F C:\Windows\System32\problematic.dll /A

rem Step 2 — grant full control so you can operate on the file
icacls C:\Windows\System32\problematic.dll /grant Administrators:F

rem Step 3 — now delete, copy over, or edit as needed
del C:\Windows\System32\problematic.dll

Output:

SUCCESS: The file (or folder): "C:\Windows\System32\problematic.dll" now owned by the administrators group.
processed file: C:\Windows\System32\problematic.dll
Successfully processed 1 files; Failed processing 0 files

Remote ownership change (/S)

/S targets a remote machine. Requires network access and appropriate credentials.

takeown /F \\myhost\C$\Quarantine\suspect.exe /A /S myhost /U CORP\alicedev

Output:

SUCCESS: The file (or folder): "\\myhost\C$\Quarantine\suspect.exe" now owned by the administrators group.

Common pitfalls

1. Ownership ≠ access — taking ownership does not grant read or write permission; it only allows you to change the ACL; always follow with icacls /grant to actually access the file.
2. /R without /D Y prompts per item — on a large tree the interactive prompts make the operation impractical; always include /D Y in scripts.
3. Windows Resource Protection (WRP) files resist changes — some system files under C:\Windows\System32 are SFC-protected; even after takeown + icacls, Windows may replace them at next boot.
4. Ownership changes are logged by security auditing — on audited systems, takeown on sensitive paths generates audit events; expected, but be aware when working in audited environments.
5. Does not recurse into mounted volumes — if a directory contains a mount point, /R does not cross volume boundaries.

Real-world recipes

Regain control of a user profile left by a deleted account

@echo off
set PROFILE=C:\Users\oldaccount
takeown /F "%PROFILE%" /R /A /D Y >NUL
icacls "%PROFILE%" /grant Administrators:F /T /C /Q
echo Ready to migrate or delete %PROFILE%

Output:

Ready to migrate or delete C:\Users\oldaccount

Batch-take ownership of all files in a folder

takeown /F C:\Recovered\* /A
icacls C:\Recovered /grant Administrators:(OI)(CI)F /T /C /Q

Output:

SUCCESS: The file (or folder): "C:\Recovered\data1.db" now owned by the administrators group.
...
Successfully processed 15 files; Failed processing 0 files

How ownership actually works

NTFS stores the owner SID in the file's security descriptor — specifically, the Owner field separate from the DACL. Every Windows file has exactly one owner. The owner always has the implicit WRITE_DAC and READ_CONTROL privileges, meaning the owner can change the DACL even if no ACE explicitly grants them that right. This is why "take ownership first, then grant yourself permission" is the canonical recovery workflow — taking ownership gives you WRITE_DAC, which lets you add yourself to the DACL.

The privilege required to take ownership is SeTakeOwnershipPrivilege. By default it's granted only to the Administrators group via the local security policy at Local Security Policy → Local Policies → User Rights Assignment → Take ownership of files or other objects. Even running takeown as an admin, the privilege must be enabled in the current token — UAC-elevated cmd shells have it enabled; standard tokens do not.

# Inspect privileges of the current process
whoami /priv | Select-String -SimpleMatch SeTakeOwnership

Output:

SeTakeOwnershipPrivilege      Take ownership of files or other objects  Enabled

When the privilege is Disabled rather than Enabled, the current shell isn't elevated. Relaunch via Start-Process cmd -Verb RunAs (see runas).

Specifying explicit owners (Windows 10+)

A newer takeown switch — undocumented in /? on some builds — lets you set ownership to a specific principal rather than just the current user or Administrators. Use icacls /setowner for the same effect with more flexibility.

rem icacls is more flexible for non-Administrators targets
icacls C:\Data\reports.dat /setowner "MYHOST\alicedev"

Output:

processed file: C:\Data\reports.dat
Successfully processed 1 files; Failed processing 0 files

rem Recursive icacls owner change (preferred over takeown for any non-Admin target)
icacls C:\OldData /setowner "BUILTIN\Administrators" /T /C /Q

Output:

Successfully processed 312 files; Failed processing 0 files

In practice, takeown is best for the two common cases it's named for (self or Administrators); for arbitrary owners, prefer icacls /setowner. See icacls — ACL Editor.

PowerShell equivalents

The PowerShell equivalent is Get-Acl / Set-Acl operating on the Owner field of a security descriptor. The pattern is: read the ACL, change Owner, write it back. This is more verbose than takeown but composes cleanly with other ACL operations and works on registry keys, AD objects, and other securable objects with the same idioms.

Take ownership with Set-Acl

$path = 'C:\Data\reports.dat'
$acl  = Get-Acl $path
$me   = New-Object System.Security.Principal.NTAccount("$env:USERDOMAIN","$env:USERNAME")
$acl.SetOwner($me)
Set-Acl -Path $path -AclObject $acl

Output: (silent on success; Get-Acl $path | Select-Object Owner confirms)

Get-Acl $path | Select-Object Owner

Output:

Owner
-----
MYHOST\alicedev

Recursive ownership via PowerShell

$root  = 'C:\OldData'
$admin = New-Object System.Security.Principal.NTAccount('BUILTIN\Administrators')

Get-ChildItem -LiteralPath $root -Recurse -Force | ForEach-Object {
    try {
        $acl = Get-Acl -LiteralPath $_.FullName
        $acl.SetOwner($admin)
        Set-Acl -LiteralPath $_.FullName -AclObject $acl
    } catch {
        Write-Warning "Skipped $($_.FullName): $_"
    }
}

Output: (one warning per inaccessible path; success is silent)

PowerShell's advantage is that you can layer ACL changes on top:

$path = 'C:\Data\reports.dat'
$acl  = Get-Acl $path
$acl.SetOwner((New-Object System.Security.Principal.NTAccount('BUILTIN\Administrators')))
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    'BUILTIN\Administrators','FullControl','Allow')
$acl.AddAccessRule($rule)
Set-Acl -Path $path -AclObject $acl

Output: (single atomic ACL update — owner change and DACL grant in one write)

takeown vs icacls /setowner

Both tools change the owner. takeown is purpose-built and slightly faster; icacls /setowner is part of the broader ACL toolkit and accepts arbitrary principals. Use whichever fits the workflow.

The two tools touch the same underlying field, so chaining them is safe. The typical recovery script: takeown /F path /R /A /D Y to seize ownership quickly, then icacls path /grant ... /T /C to fix the DACL.

Comparing with chown on Linux

Linux's chown and Windows' takeown solve the same problem (change a file's owner) but with different security models. The most important divergence: Linux owners can do whatever the mode bits allow, but Windows owners also get the implicit WRITE_DAC privilege regardless of ACL — this is why "take ownership to recover access" works on Windows but chown alice file doesn't automatically grant alice access on Linux.

See permissions — chmod, chown, umask, ACLs for the Linux side in detail.

Remote operations and limitations

takeown /S <host> connects via RPC over SMB to the remote machine. The caller must have SeTakeOwnershipPrivilege on the remote box (typically by being an admin there). RPC endpoints (TCP 135 + dynamic high ports) and File and Printer Sharing must be allowed through the remote firewall.

takeown /F \\fileserver01\D$\Quarantine /R /D Y /A /S fileserver01 /U CORP\alicedev /P P@ssw0rd

Output:

SUCCESS: The file (or folder): "\\fileserver01\D$\Quarantine" now owned by the administrators group.
SUCCESS: The file (or folder): "\\fileserver01\D$\Quarantine\suspect.exe" now owned by the administrators group.
...

For PowerShell-based remote operations, Invoke-Command is the modern alternative — it uses WinRM (HTTP/5985 or HTTPS/5986) and supports CredSSP for double-hop scenarios.

Invoke-Command -ComputerName fileserver01 -ScriptBlock {
    takeown /F C:\Quarantine /R /D Y /A
} -Credential (Get-Credential CORP\alicedev)

Output: (per-file success lines, returned across the WinRM channel)

Audit logging — Event 4670

NTFS ownership changes generate Security event 4670 ("Permissions on an object were changed") when SACL auditing is enabled on the path. Combined with Event 4663 ("An attempt was made to access an object"), an ownership transfer leaves a clear forensic trail. Enable SACL auditing via Explorer → Properties → Security → Advanced → Auditing, or via auditpol.

rem Enable file system object access auditing globally
auditpol /set /subcategory:"File System" /success:enable /failure:enable

Output:

The command was successfully executed.

# Query recent ownership-change events
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4670; StartTime=(Get-Date).AddDays(-7)} |
    Select-Object TimeCreated,
        @{Name='Object';Expression={$_.Properties[6].Value}},
        @{Name='Subject';Expression={$_.Properties[1].Value}}

Output:

TimeCreated         Object                                          Subject
-----------         ------                                          -------
5/24/2026 9:14 AM   C:\Windows\System32\problematic.dll             alicedev
5/24/2026 9:30 AM   C:\OldData                                      alicedev

For compliance audits (PCI-DSS, HIPAA, SOX), forward Event 4670 to a SIEM. Unexpected ownership changes on system directories or shared file-server paths are a strong signal of insider misuse or post-exploit cleanup.

SACL inheritance, junctions, and reparse points

takeown /R follows directories but does not cross volume boundaries (mount points) or NTFS junction points by default — same as dir /S. This is intentional: a junction pointing at C:\ from a subfolder would otherwise cause the recursion to consume the entire volume.

For symlinks, the behaviour depends on the link's flags (file-symlink vs. directory-symlink, mount-point reparse). To inspect, use fsutil reparsepoint query <path>:

fsutil reparsepoint query C:\OldData\link-to-elsewhere

Output:

Reparse Tag Value : 0xa000000c   (IO_REPARSE_TAG_SYMLINK)
Substitute Name offset: 0
...

If you need to seize ownership through the link, dereference it first (run takeown on the target path directly) or temporarily delete the link. PowerShell's Get-ChildItem -Force with explicit reparse handling provides finer control than takeown /R.

Long path support

takeown historically failed on paths longer than 260 characters (the legacy MAX_PATH limit). On Windows 10 1607+ with long-path support enabled (via group policy or registry: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled = 1), takeown honours the \\?\ prefix.

rem Long path with \\?\ prefix
takeown /F "\\?\C:\Users\alicedev\Documents\very-long-deeply-nested-folder-tree\..."

Output:

SUCCESS: The file (or folder): "\\?\C:\Users\alicedev\Documents\very-long-deeply-nested-folder-tree\..." now owned by user "MYHOST\alicedev".

For PowerShell, use -LiteralPath with \\?\ or enable long paths system-wide.

Common pitfalls (extended)

In addition to the basics above, watch for these in production scripts:

6. /R is single-threaded and slow on large trees — taking ownership of C:\ (hundreds of thousands of files) can take 30+ minutes. Parallelize with PowerShell ForEach-Object -Parallel or robocopy /COPY:O /SECFIX for bulk security descriptor work.
7. TrustedInstaller-owned files — many C:\Windows files are owned by NT SERVICE\TrustedInstaller. After takeown /A plus icacls /grant, edit, then restore ownership: icacls file /setowner "NT SERVICE\TrustedInstaller" so Windows Update can still service the file.
8. Symlinks and junctions are silently skipped by /R — if a tree contains junction loops, you'll miss the targeted content. Use dir /AL to find reparse points first.
9. takeown reports SUCCESS even when DACL still denies you access — ownership and access are distinct; always pair with icacls /grant and verify with icacls file afterward.
10. Encrypted files (EFS) cannot be read after ownership change — EFS encrypts file contents with the original user's key; taking ownership grants you ACL access but the kernel still refuses reads without the EFS private key. Recovery requires a designated Data Recovery Agent (DRA).
11. System Restore points include ACLs — restoring a system image rolls back ownership too. If you've fixed permissions on a critical path, document the change so the recovery procedure preserves it.
12. takeown does not work on registry keys — for HKLM keys you need regini or PowerShell's [Microsoft.Win32.RegistryKey]::SetAccessControl(). takeown is strictly filesystem.

Real-world recipes (extended)

Replace a stuck system DLL after Windows Update failure

@echo off
rem Backup
copy C:\Windows\System32\stuck.dll C:\Temp\stuck.dll.bak

rem Seize ownership and grant FC
takeown /F C:\Windows\System32\stuck.dll /A
icacls C:\Windows\System32\stuck.dll /grant Administrators:F

rem Replace
copy /Y C:\Updates\stuck-fixed.dll C:\Windows\System32\stuck.dll

rem Restore TrustedInstaller as owner (so Windows Update can service it later)
icacls C:\Windows\System32\stuck.dll /setowner "NT SERVICE\TrustedInstaller"
icacls C:\Windows\System32\stuck.dll /grant "NT SERVICE\TrustedInstaller":F

Output:

        1 file(s) copied.
SUCCESS: The file (or folder): "C:\Windows\System32\stuck.dll" now owned by the administrators group.
processed file: C:\Windows\System32\stuck.dll
Successfully processed 1 files; Failed processing 0 files
        1 file(s) copied.
processed file: C:\Windows\System32\stuck.dll
Successfully processed 1 files; Failed processing 0 files
processed file: C:\Windows\System32\stuck.dll
Successfully processed 1 files; Failed processing 0 files

Migrate a deleted user's profile to a new account

$old = 'C:\Users\bobdev.old'
$new = 'CORP\bobdev-new'

# Seize ownership
takeown /F $old /R /A /D Y | Out-Null

# Replace ACL: grant new owner full control, strip orphaned SIDs
icacls $old /reset /T /C /Q
icacls $old /grant "${new}:(OI)(CI)F" /T /C /Q
icacls $old /setowner $new /T /C /Q

Output:

(progress flickers through hundreds of files; final state: new user is the owner with FullControl)

Robocopy security descriptor fixup

When takeown /R is too slow on millions of files, robocopy with /COPYALL or /SECFIX is faster — it copies/fixes security descriptors in parallel.

rem Apply the security descriptor of a template directory to all matching files
robocopy C:\Templates\Folder C:\Target\Folder /E /COPY:DATSO /SECFIX /MT:16

Output:

   New Dir          0    C:\Target\Folder\
Total files: 12345 / Copied: 12345 / Failed: 0 ...

/COPY:DATSO copies Data, Attributes, Timestamps, Security, Owner; /SECFIX updates security on files even when not copying them; /MT:16 runs 16 parallel threads.

Quick PowerShell function: take-and-grant

function Take-AndGrant {
    param(
        [Parameter(Mandatory)][string]$Path,
        [string]$Principal = 'BUILTIN\Administrators',
        [string]$Rights    = 'FullControl'
    )
    takeown /F $Path /A /R /D Y | Out-Null
    icacls $Path /grant "${Principal}:($Rights)" /T /C /Q | Out-Null
    Write-Host "Ownership and access granted to $Principal on $Path"
}

Take-AndGrant -Path C:\OldData -Principal MYHOST\alicedev

Output:

Ownership and access granted to MYHOST\alicedev on C:\OldData

Audit: who owns the contents of a directory?

Get-ChildItem -LiteralPath C:\Data -Recurse -File |
    Select-Object FullName, @{Name='Owner'; Expression={(Get-Acl $_.FullName).Owner}} |
    Group-Object Owner |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Output:

Count Name
----- ----
  423 MYHOST\alicedev
   87 NT SERVICE\TrustedInstaller
   12 BUILTIN\Administrators
    3 NT AUTHORITY\SYSTEM

Anomalies (e.g. a service account owning files in a user's profile) are worth investigating.

Restore default ownership of C:\Windows\System32

If a misguided takeown /R /A on C:\Windows\System32 left the system unstable, restore TrustedInstaller as the owner across the tree.

icacls "C:\Windows\System32" /setowner "NT SERVICE\TrustedInstaller" /T /C /Q

Output:

Successfully processed 25431 files; Failed processing 0 files

Then run sfc /scannow to repair any DACLs that may have shifted, followed by DISM /Online /Cleanup-Image /RestoreHealth for componentstore consistency.

See also

• icacls — ACL Editor — the partner command for fixing DACLs after takeown
• runas — Run as Different User — elevate to a privileged shell before running takeown
• net user — Local User Account Manager — create the accounts you may need to assign as owner
• net localgroup — Local Group Manager — manage the Administrators group takeown /A writes to
• gpresult & gpupdate — verify which GPO controls SeTakeOwnershipPrivilege assignment
• permissions — chmod, chown, umask, ACLs — Linux ownership model side-by-side

Sources

• icacls — Microsoft Learn — companion ACL editor, including /setowner and /save//restore.
• Takeown command — SS64 — switch reference for /F, /A, /R, /D, /S, /U, /P.
• Take Ownership of a File or Folder Using Command-Line — Winhelponline — practical takeown+icacls recovery recipes.
• Windows Privilege Escalation — Abusing User Privileges — context on SeTakeOwnershipPrivilege semantics and token requirements.