Fix 0X000008ED: NERR_NotLocalName on Windows network shares

You're trying to map a network drive and Windows hits you with error 0X000008ED (NERR_NotLocalName). Annoying, but there's a straightforward fix.

The fix: use the IP address, not the computer name

What's actually happening here is that Windows can't resolve the computer name to an IP address on your local network. It's trying to tell you that the name you gave it — \ServerName\Share — isn't found locally. The workaround is to bypass name resolution entirely.

1. Find the IP address of the remote computer. On that machine, open Command Prompt and type ipconfig. Look for the IPv4 Address, something like 192.168.1.50.
2. On your computer, open File Explorer, right-click This PC, and select Map network drive.
3. In the Folder field, type \192.168.1.50\ShareName (replace the IP and share name).
4. Check Reconnect at sign-in if you want it persistent.
5. Click Finish.

If that works, you're done. The reason step 3 works is that IP addresses don't rely on NetBIOS or DNS name resolution — the SMB protocol talks directly to the remote machine's IP. No name lookup, no error.

Why this error happens

The error code 0X000008ED maps to NERR_NotLocalName. Windows expects the network name to be either a local computer name or a name it can resolve through NetBIOS broadcasts, the LMHOSTS file, or DNS. When none of those resolve the name, you get this error.

Common scenarios where this pops up:

• You're on a workgroup, not a domain, and NetBIOS over TCP/IP is disabled on either machine.
• Firewall rules block NetBIOS (ports 137-139, 445).
• The remote computer's name is more than 15 characters — NetBIOS can only handle 15.
• You're using NET USE in a batch script and the name doesn't match exactly.

Less common variations of the same issue

1. The LMHOSTS file trick

If you really need to use a name (for a script or legacy app), edit the LMHOSTS file on the local machine. It's in C:\Windows\System32\drivers\etc\lmhosts. Add a line like:

192.168.1.50  ServerName

Save, then flush the NetBIOS cache with nbtstat -R (run as admin). This forces Windows to look at that file first. It's a hack but works when you can't change the remote machine.

2. NetBIOS over TCP/IP disabled

Go to Control Panel > Network and Sharing Center > Change adapter settings. Right-click your network adapter, select Properties, then double-click Internet Protocol Version 4 (TCP/IPv4). Click Advanced, go to the WINS tab, and select Enable NetBIOS over TCP/IP. Reboot both machines. This is the second-most common cause after bad name resolution.

3. The name is on a different subnet

If the remote machine is on a different subnet, NetBIOS broadcasts won't cross routers. Your options: use the IP address, set up a WINS server, or add the entry to LMHOSTS as above. No way around this one — it's a network design limitation.

4. Registry hack for long names

If the computer name is 16+ characters, NetBIOS truncates it. You can work around this by enabling DirectHostedSMB (SMB over TCP/IP directly on port 445). Add this registry key on both machines:

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value: SmbDeviceEnabled
Type: DWORD
Data: 1

Reboot. This forces SMB to use DNS instead of NetBIOS, so longer names work. Only do this if you understand the security implications — it changes how the server advertises itself.

Prevention

The real fix is to stop relying on NetBIOS for name resolution in modern networks. Starting with Windows 10 version 1703, Microsoft disables SMB1 by default, which also kills NetBIOS name resolution in many scenarios. If you control both machines:

• Set up a consistent DNS server on your local network (your router's built-in DHCP usually does this).
• Always use IP addresses in scripts and mapped drives unless you have a proper domain.
• Keep NetBIOS over TCP/IP enabled on both machines — it's not a security risk in a trusted LAN.
• Check the remote machine's firewall allows File and Printer Sharing (inbound rule for ports 139 and 445).

One last thing: if you're using a VPN and get this error, it's almost always because the VPN's DNS isn't resolving the remote machine's name. Use the IP address of the remote machine on the VPN subnet, not its local LAN IP. That'll save you an hour of frustration.