Fixing ERROR_INVALID_OWNER (0x0000051B) on Windows

Quick answer: This error means the security identifier (SID) you're trying to assign as an owner either doesn't exist on the system, or your account lacks the SeTakeOwnershipPrivilege required to change ownership to that SID. Run secedit /configure /db secedit.sdb /cfg \windows\inf\defltbase.inf /areas SECURITYPOLICY as Administrator to reset the privilege, or directly grant yourself the right via gpedit.msc.

What's Actually Happening

Windows tracks object ownership through SIDs—those long strings like S-1-5-21-... that represent user or group accounts. The ERROR_INVALID_OWNER (0x0000051B) fires when the system's security subsystem rejects your attempt to set an owner. Two root causes dominate:

• The SID is valid, but your account doesn't hold the SeTakeOwnershipPrivilege. Even an Administrator account can be stripped of this right if a domain policy or local security policy changed it. The OS uses this privilege as a gate—without it, you can't reassign ownership to any SID except yourself.
• The SID you're passing is bogus or belongs to a deleted user. This happens most often when you copy an ACL from one machine or try to restore a backup from a system where the user existed. The SID no longer resolves to an active account on your machine.

I've seen this error pop up in three real-world scenarios: taking ownership of a corrupted registry key left behind after a failed uninstall, trying to assign ownership of a file share to a group that was removed from AD, and during an in-place upgrade where the old administrator SID got orphaned.

Step-by-Step Fix

1. Check your current owner privilege. Open an elevated Command Prompt (Win+X, A) and run whoami /priv. Look for SeTakeOwnershipPrivilege—if it shows Disabled, we need to fix that. If it's missing entirely, the policy removed it.
2. Reset the privilege using security policy. Still in the elevated prompt, run:
   secedit /configure /db secedit.sdb /cfg C:\Windows\inf\defltbase.inf /areas SECURITYPOLICY
   This resets the entire local security policy to defaults, which re-enables SeTakeOwnershipPrivilege for Administrators. Reboot after.
3. Verify the privilege is now present. After reboot, run whoami /priv again. You should see SeTakeOwnershipPrivilege listed as Enabled.
4. Retry the ownership change. Use takeown /f "C:\path\to\file" for files or Set-Acl in PowerShell for registry keys. If the error persists, move to the alternative below.

Alternative Fix: Grant the Privilege Directly via GPO

If resetting the whole policy feels too blunt (it is), target just the privilege:

1. Press Win+R, type gpedit.msc, hit Enter.
2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
3. Find Take ownership of files or other objects in the right pane.
4. Double-click it, add Administrators (or your specific user account).
5. Close the editor, run gpupdate /force in an elevated prompt, then reboot.

This method preserves other policy tweaks you've made. The downside is that if a domain policy overrides this setting, you'll still hit the error—domain policies win.

When the SID Itself Is the Problem

If the privilege is fine but the error still appears, the SID you're assigning doesn't exist on this machine. To check:

wmic useraccount where name="Administrator" get sid

Compare that SID to the one you're trying to use. If you need to assign ownership to a specific user, first confirm the user exists on the system. For a deleted user, the SID is orphaned—you can't assign ownership to it. The only fix is to create a new user and use that SID, or take ownership as SYSTEM (via psexec -s -i cmd) and then reassign.

Prevention Tip

Before backing up files or registry keys with their ACLs, always export the current owner SID along with the data. When restoring, ensure the target system has a matching account or you'll recreate the same error. For registry keys specifically, avoid copying ACLs from one machine to another—rebuild them manually or use a tool like SetACL.exe that handles SID translation.

Also, don't grant SeTakeOwnershipPrivilege to regular users. It's a powerful right—once assigned, they can seize any object on the system. Keep it restricted to Administrators and only grant it temporarily when needed.