Fix ERROR_NONE_MAPPED (0X00000534) – No mapping between account names and SIDs

I saw this error three times last month alone. Once on a client's file server after they migrated to a new domain – nothing would open on the shared drive. Another time on a workstation where someone had moved an external drive between PCs and the old permissions just vomited SID errors all over the place.

The error text says it all: No mapping between account names and SIDs was done. Behind the scenes, Windows stores permissions as SIDs (long strings like S-1-5-21-123456789-...), not as friendly names. When it can't resolve a SID back to a name, you get 0X00000534. Common triggers: you changed the computer name, joined a new domain, or plugged in a drive that had NTFS permissions from another machine.

Here's the fix breakdown – start with the most common cause.

1. Broken permissions from a moved drive or shared folder

This is the number one cause I run into. Someone takes an external USB drive from one PC, plugs it into another, and suddenly can't open files. Or you move a whole folder from one server to another over the network. The SIDs from the original machine are still embedded in the NTFS permissions, and the new machine can't map them.

The fix: Use icacls to find and remove orphaned SID entries, then reapply proper permissions.

1. Open Command Prompt as Administrator.
2. Run:

   icacls D:\FolderName /findsid *

   (replace the drive and folder with your target). This lists every SID that can't be resolved. You'll see long hex strings instead of user names.
3. To remove the broken SID from the folder and all subcontents:

   icacls D:\FolderName /remove /t /c *

   • /t = apply to subfolders and files
   • /c = continue on errors
   • * = wildcard for all orphaned SIDs
4. Then reset ownership to the current user or group:

   takeown /f D:\FolderName /r

5. Finally, reapply proper permissions via Security tab or use icacls again.

Had a client last month whose entire print queue died because of this – the printer driver folder had a SID from an old server. Removing the orphaned SID fixed it instantly.

2. Computer name changed but share permissions still point to old name

Windows uses the computer's SID, not the name, in many places. But if you renamed the PC or joined a new domain, shares you created earlier might reference the old machine account. For example, you had \\OldPC\Share with permissions for OldPC\User. After renaming, that SID is orphaned.

The fix: Use net share to see all shares and check their permissions.

1. Open PowerShell as Admin.
2. List all shares:

   net share

3. For each share, check permissions:

   icacls C:\PathToShare

4. If you see SIDs like S-1-5-21-... where the old computer name should be, run the icacls /remove command from fix #1 on that folder.
5. Then add your current user/group:

   icacls C:\PathToShare /grant "Everyone:(R)"

   (or specific users).

One trick: if you still have the old computer name as a hostname (like in a workgroup), temporarily join the old workgroup, fix permissions, then rejoin the new one. I've done that twice – it's faster than wrestling with manual SID removal.

3. Orphaned user profiles after domain migration

When you move a PC from one domain to another (or from workgroup to domain), user profiles from the old domain still exist but their SIDs are dead. Trying to access those profile folders gives 0X00000534. This is especially nasty because Windows Explorer hangs while trying to resolve the SID.

The fix: Use wmic or the GUI to delete old profiles, or strip permissions from the profile folder.

1. Press Win + R, type sysdm.cpl, go to Advanced tab, under User Profiles, click Settings.
2. If you see profiles with a name like Unknown account or a SID string, delete them. But sometimes they won't delete without an error.
3. Fallback: Open Regedit, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Look for keys with a ProfileImagePath pointing to a folder – if the Sid value doesn't resolve, delete the key. Backup the registry first.
4. Then in File Explorer, right-click the profile folder, go to Security, Advanced, Change owner to Administrators, and replace owner on subcontainers. Delete the old SID entry.

I've seen this one after a client moved 30 PCs from an old domain to Office 365 Azure AD. Half the desktops threw 0X00000534 on every login. Bulk-deleting the old profiles via PowerShell fixed it:

Get-WmiObject Win32_UserProfile | Where-Object { $_.LocalPath -like '*olddomain*' } | Remove-WmiObject

Quick-reference summary table