STATUS_INVALID_OWNER (0XC000005A) Fix – Permissions Won't Stick

1. Corrupt User Profile or Broken SID Mapping

This is the #1 cause I see in the wild. You're on a domain-joined machine, you try to take ownership of a file or registry key, and bam—STATUS_INVALID_OWNER. What's happening is Windows can't resolve the user's SID to a valid account. Maybe the user profile got nuked during a domain migration, or the local SAM database got corrupted.

Had a client last month whose entire file server folder permissions went blank after a domain rename. Every time they tried to set the owner back to Domain Users, they got 0XC000005A. The fix? Force a SID cleanup.

Check with PSGetSID or Whoami

whoami /user
wmic useraccount where name='%username%' get sid

Compare the SID in the error context (like the old owner SID in file properties) with the current user's SID. If they don't match, you're dealing with a stale SID.

Fix: Reset the User Profile or Remove Stale SID

1. Delete the old profile – Go to System Properties > Advanced > User Profiles. Select the broken profile and delete it. Reboot and log in fresh. This rebuilds the SID-to-username mapping.
2. If that fails – Use subinacl or icacls to manually replace the SID: icacls C:\folder /grant *S-1-5-21-...:F /t (use the correct SID from whoami).

This works 80% of the time. If not, move to cause #2.

2. Missing SeTakeOwnershipPrivilege

Even as Administrator, you might not have the right privilege enabled. Vista and later require SeTakeOwnershipPrivilege to be active. If you're running under a non-elevated command prompt or a restricted token (like UAC blocks it), Windows can't assign the owner.

I once spent an hour on a call with a remote user who couldn't change ownership of a printer driver folder. They were running PowerShell as Admin but the token didn't have the privilege. The error? 0XC000005A.

Check and Enable the Privilege

whoami /priv | findstr SeTakeOwnership

If you see Disabled, that's your problem. You can't enable it via command line—you have to use Local Security Policy (secpol.msc) or Group Policy:

1. Open secpol.msc > Local Policies > User Rights Assignment > Take ownership of files or other objects.
2. Add your user or group (e.g., Domain Admins).
3. Run gpupdate /force and log out/in.

If you're on a domain, check that Group Policy isn't stripping that right. Use rsop.msc to confirm.

After enabling, retry the ownership change. If the privilege is present but still failing, go to cause #3.

3. Bit Rot or Broken Security Descriptor in Registry/File

Sometimes the object itself is corrupted. The security descriptor—the ACL and owner info stored in the NTFS stream or registry hive—gets mangled. This usually happens after a sudden power loss, disk write error, or buggy third-party backup software.

Had a case where a registry key under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion would throw 0XC000005A every time we tried to set the owner to SYSTEM. The key looked fine, but the security descriptor was malformed.

Fix: Use PowerShell to Force Reset the Owner

$path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\YourBrokenKey"
$acl = Get-Acl -Path $path
$owner = [System.Security.Principal.NTAccount]"Administrators"
$acl.SetOwner($owner)
Set-Acl -Path $path -AclObject $acl

If that still fails, you might need Process Monitor to see what driver or filter is blocking the write. Run procmon, filter by path, and look for SetOwner calls returning ACCESS_DENIED or INVALID_OWNER. Often a file system filter driver (like antivirus or encryption software) is interfering.

Last resort: boot off a WinPE USB, use takeown /f C:\path /r /d y from outside the OS. That bypasses most driver interference.

Quick-Reference Summary

I've seen 0XC000005A in more places than I care to count—file shares, registry hives, even printer queues. Nine times out of ten, it's a stale SID from a profile that got orphaned. If you're short on time, start with cause #1. If you're still stuck, check your privileges. The corrupted descriptor is rare but nasty—you'll know it when you see it.