0X00000107

Fix STATUS_SOME_NOT_MAPPED (0X00000107) in Windows

This error means Windows couldn't map all security info when accessing a network share. It usually happens with permissions or credentials.

Quick answer: Run net use * /delete in an admin command prompt, then remap the drive with the right domain user credentials. If that fails, check share permissions and local group policy.

I've seen this error a lot on Windows 10 and Windows 11 machines when users try to access a network share or a mapped drive. The error text says "Some of the information to be translated has not been translated." What's happening is Windows is trying to map security identifiers (SIDs) from the server to the local machine, and it can't finish the job. This usually means a permission mismatch — either the user doesn't have the right access, or the credentials stored in Windows are stale or wrong.

The error pops up most often after a password change or when you move a computer between domains. I've also seen it when someone connects to a share using an old saved credential that no longer works. The fix isn't complicated, but you need to be methodical.

Step-by-step fix

  1. Disconnect all mapped drives. Open a command prompt as administrator. Type net use * /delete and press Enter. When asked to confirm, type Y. This clears all existing connections. After this, you might see a message like "There are no entries in the list." That's fine.
  2. Open Credential Manager. Press Windows key, type "Credential Manager," open it. Click "Windows Credentials." Look for any entries related to the server or share you're trying to access (they'll be under "Generic Credentials"). Remove them by clicking the arrow, then "Remove." Confirm the removal.
  3. Remap the drive with explicit credentials. Open File Explorer, right-click "This PC," select "Map network drive." Choose a drive letter. In the folder box, type the full UNC path, like \\server\share. Check the box "Connect using different credentials." Click Finish. When prompted, enter the username as DOMAIN\username and the correct password. Don't use an email-style login — use the old domain format.
  4. Test the connection. After mapping, try to open the drive. If it works, you're done. If not, move to the next step.

If the error still shows up

  1. Check share permissions on the server. Ask the server admin to verify the share gives you "Read" or "Change" access. Also check the NTFS permissions on the folder. I've seen cases where the share allowed full access but NTFS denied it. You need both.
  2. Disable unnecessary security settings. On your local machine, open gpedit.msc (Group Policy Editor). Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Find "Network security: LAN Manager authentication level." Set it to "Send NTLMv2 response only." Also check "Microsoft network server: Digitally sign communications (always)" — set it to Disabled temporarily. Reboot after changing these.
  3. Use the command line to map. Sometimes GUI mapping leaves junk behind. Run this in command prompt: net use Z: \\server\share /user:DOMAIN\username * /persistent:yes. It'll ask for the password. Type it and press Enter. If it says "The command completed successfully," you're good.
  4. Check for duplicate SIDs. If you cloned a hard drive or used a system image, the computer might have a duplicate SID. This is rare but happens. Run Sysprep or use the tool NewSID (though it's old). Better yet, rebuild the machine if this is the case.

Alternative fixes that sometimes work

  • Restart the Workstation service. Open Services (services.msc), find "Workstation" service, right-click, Restart. Then try mapping again.
  • Flush DNS and ARP cache. In admin command prompt: ipconfig /flushdns then arp -d *. This clears network caches.
  • Temporarily disable firewall. If you're on a trusted network, turn off the Windows Firewall for a minute to see if it's blocking the connection. Don't leave it off.

How to prevent this from coming back

First, always use the correct domain credentials when mapping drives. Don't use local accounts unless the share is on a workgroup. Second, if your company policy forces regular password changes, tell users to disconnect and remap their drives after each change. Third, for servers, avoid using user-specific SIDs in share permissions — use groups instead. And finally, if you're managing multiple machines, push a group policy that sets LAN Manager authentication level to "Send NTLMv2 response only" and disables anonymous access. That alone stops a lot of these errors.

One last thing: if you're still stuck after all this, check the server's event log under Applications and Services Logs > Microsoft > Windows > SMBClient. Look for Event ID 4410 or 4411. Those logs tell you exactly which SID failed to map. That will point you straight to a permission problem on the server side.

Related Errors in Windows Errors
File Associations Reset After Windows Update? Fix It Here 0XC019004F STATUS_RESOURCEMANAGER_NOT_FOUND (0XC019004F) — KTM fix 0X80310016 FVE_E_BAD_DATA (0X80310016) Fix: Malformed BitLocker Data 0X00000552 Fix 0X00000552: Logon Process Restriction Error

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.