Fix ERROR_SOME_NOT_MAPPED 0X00000515 SID mapping failed

Quick answer

Run icacls path /remove /t to find and kill orphaned SIDs, then re-apply correct permissions from a fresh account.

What actually triggers this error

You're getting ERROR_SOME_NOT_MAPPED (code 0x00000515) because a permission entry on a file, folder, share, registry key, or group policy object references a user or group that no longer exists. Windows can't turn that SID into a readable account name — so it throws this error. I've seen it most often after demoting a domain controller, deleting a domain user, or moving a computer between domains without cleaning up old permissions. The real pain point: you can't access a shared folder or you get access denied even though you're an admin. The fix is to find the bad SID and remove it.

Step-by-step fix

These steps assume you're on Windows 10/11 or Server 2016+. Run everything as administrator.

Step 1: Identify where the bad SID lives

Open an elevated command prompt (right-click Start > Windows Terminal Admin). If the error happens when you try to open a specific folder or drive, run:

icacls D:\Share /findsid *

Replace D:\Share with the real path. This scans every subfolder and file. You'll see something like:

D:\Share\OldProject: S-1-5-21-123456789-1234567890-123456789-500:(OI)(CI)F

That long string after the colon is the orphaned SID. Write it down.

If the error comes from a mapped drive or net use command, check the registry instead. Run:

reg query HKCU\Network /s

Look for RemotePath values that point to a server that's gone.

Step 2: Remove the orphaned SID from files and folders

Now you'll nuke that SID. Still in the command prompt:

icacls D:\Share /remove S-1-5-21-123456789-1234567890-123456789-500 /t /q

The /t flag hits all subfolders and files. /q keeps output quiet. After it finishes, run the same icacls /findsid again to confirm it's gone. You should see no results.

Step 3: Fix the mapped drive or net use entry

If you used net use and got this error, delete and recreate the mapping. Open an admin command prompt:

net use * /delete

This removes all network drives. Re-add them:

net use Z: \\Server\Share /persistent:yes

If the server is gone too, you'll get a different error — but at least the 0x00000515 will clear.

Step 4: Clear orphaned SIDs in registry (if needed)

Some apps store permission SIDs directly in the registry. If the error pops up when opening a specific program, check:

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

Look for keys that end in .bak — those often point to deleted users. Delete the entire key if you're sure the user is gone. Backup first: right-click the key and export it.

Alternative fixes if the main one fails

Sometimes the bad SID is buried in a system folder you can't touch. Here's plan B.

Use the GUI to find the bad entry

Right-click the problem folder > Properties > Security > Advanced. Look at the Permission entries list. Any entry showing a SID like S-1-5-21-... instead of a username? Click it and hit Remove. Apply. This works for small folders but is slow as hell for large directory trees.

Reset NTFS permissions to default

If you're desperate and the folder contains no critical data, reset permissions:

icacls D:\Share /reset /t /q

This removes all explicit permissions and forces inheritance from the parent. You'll lose your custom ACLs, so do this only on folders you can rebuild.

Run a system file check

Rarely, corruption in the SAM or security hive causes SID issues. Run:

sfc /scannow

Then reboot. This won't fix orphaned SIDs, but it might if the error is system-wide and not file-specific.

Prevention tip

Before you delete a user or leave a domain, run icacls “C:\Path” /save acl.txt on all shared folders. That gives you a backup of current permissions. After the account is gone, restore the backup and manually replace the old SIDs with new ones. Also, never use local accounts for file shares if you can help it — use domain groups. They're easier to clean up when someone leaves.