Fix STATUS_NONE_MAPPED (0xC0000073) in Windows

What is STATUS_NONE_MAPPED (0xC0000073)?

This error shows up when Windows tries to translate a security identifier (SID) — like a username or group name — into something readable, but can't find the mapping. The error text from Microsoft says: "None of the information to be translated has been translated." That's technical talk for: the SID you're pointing at doesn't match any known account.

I've seen this most often in three situations:

• You're trying to access a shared folder or printer, and the user account on the remote machine doesn't exist anymore.
• A user profile on your local PC is corrupted — the NTUSER.DAT file has bad SID references.
• A domain computer has a broken trust with the domain controller — usually after a migration or rebuild.

Don't panic. The fixes below go from quickest (30 seconds) to more involved (15+ minutes). Stop when the error's gone.

Quick Fix (30 seconds): Reboot and Check Permissions

Sounds stupid, but I've seen a simple restart clear this when the error was caused by a temporary glitch in the Security Accounts Manager (SAM) service. Do this first:

1. Reboot your computer. Not shutdown and power on — use the Restart option.
2. If you're accessing a network share, verify you're using the correct username and password. Try \computer\share and enter credentials manually.
3. If the error appears when opening a local file or folder, check the Security tab in Properties. Look for SIDs starting with S-1-5-21- that don't have a friendly name (like "Unknown account"). Right-click them, remove, then re-add the correct user.

If the error's gone, great. If not, move on.

Moderate Fix (5 minutes): Repair the User Profile

A corrupted user profile is the #1 cause of 0xC0000073 on standalone Windows 10/11 machines. Here's how to fix it without losing your data.

1. Log in as a different user that has admin rights. If you don't have another admin account, boot into Safe Mode with Networking and use the built-in Administrator account (enable it first via net user administrator /active:yes in Command Prompt).
2. Open Registry Editor (regedit). Navigate to:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

3. Look for subkeys that end in .bak — Windows creates these when a profile gets corrupted. You'll see something like S-1-5-21-xxxxx-1001.bak alongside a non-bak version (S-1-5-21-xxxxx-1001).
4. Backup both keys first (right-click → Export). Then rename the non-bak key by adding .old to the end, and rename the .bak key by removing .bak. Like this:
   • Rename S-1-5-21-xxxxx-1001 → S-1-5-21-xxxxx-1001.old
   • Rename S-1-5-21-xxxxx-1001.bak → S-1-5-21-xxxxx-1001
5. Close regedit, reboot, and log back in with the affected account. Windows will create a fresh profile based on the backup data.

If the profile still has issues, you may need to manually copy files from C:\Users\[OldUsername] to the new profile. I've had this work about 70% of the time.

Advanced Fix (15+ minutes): Reset Domain Trust

This fix is for domain-joined machines. The error often pops up when the computer account password in the domain doesn't match the local machine's stored password. You'll see 0xC0000073 in the System event log with source "KDC" or "NETLOGON".

1. Log in with a local admin account (use .\Administrator or another local account you created during setup).
2. Open PowerShell as Administrator. Run:

   Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

   Enter domain admin credentials when prompted. This scans the trust, resets the computer account password, and re-establishes the channel.
3. If the above fails — and it sometimes does — use the old-school method:

   nltest /sc_reset:YourDomainName\YourDomainController

   Replace YourDomainName with your actual domain (like contoso.com) and YourDomainController with the hostname of a domain controller. This forces a trust reset.
4. Reboot and test again. If the error persists, check with your domain admin — the computer account might be disabled or deleted in Active Directory. They'll need to rejoin the domain using Reset-ComputerMachinePassword or by removing and re-adding the computer to the domain (that's a longer process, but it's the nuclear option).

I've dealt with this on Server 2019 after a domain controller upgrade — the trust reset fixed it in 90 seconds. If you're still stuck, post on the Sysadmin subreddit with the output from nltest /dsgetdc:YourDomain — someone will spot the issue fast.

Last Resort: Rebuild the Security Descriptor

If none of the above worked, the issue might be in the file or folder's ACL itself. Run this from an elevated Command Prompt on the affected file or folder (replace D:\Path\To\Folder with yours):

icacls "D:\Path\To\Folder" /reset /t /c /q

This resets all permissions to inherited defaults. It'll nuke any custom permissions you set, so back them up first. I've only needed this once in six years — but when I did, it was the only thing that worked.

That's it. Start with the reboot, try the profile fix, and if you're on a domain, reset the trust. You'll have this licked in under 15 minutes.