When ERROR_BAD_NET_NAME (0x00000043) Pops Up
You're double-clicking a mapped drive or typing \\server\share in File Explorer, and boom: "The network name cannot be found." This usually happens on a fresh Windows 10 or 11 machine joined to a domain, or after a VPN drops mid-session. I've seen it most when someone tries to map a drive to a NAS like a Synology DS220+ using its hostname instead of its IP, or when a laptop switches from Wi-Fi to Ethernet and the DNS cache goes stale. The error code 0x00000043 is Windows' way of saying "I looked for that name and got nothing back."
What's Really Going On
In plain English: your PC asked the network "who is server?" and nobody answered. That could mean DNS can't resolve the name, the share doesn't exist anymore, SMB is blocked, or the server is offline. It's not a permissions issue—if it were, you'd get "Access is denied" (0x00000005). This is purely a name-resolution or reachability problem. The full error from net use looks like:
System error 67 has occurred.
The network name cannot be found.Same code, different face. The real fix depends on whether the name is wrong, the network path is broken, or the service isn't running on the target.
Step-by-Step Fix
- Check the share name and path. Typos are the #1 cause. Open Command Prompt and run
net view \\server(replaceserverwith the actual name). If you get "System error 53," the server isn't reachable. If you see a list of shares, double-check the exact share name—case matters sometimes, and hidden shares end with$. - Ping the server by name and IP. In Command Prompt, type
ping serverand thenping 192.168.1.100(use the real IP). If the name fails but the IP works, it's a DNS problem. Go to step 3. If both fail, the server is down or your network cable/Wi-Fi is disconnected. - Flush DNS and re-register. Run these commands in an elevated Command Prompt:
ipconfig /flushdns
ipconfig /registerdns
nbtstat -R
nbtstat -RRAfter running ipconfig /flushdns, you should see "Successfully flushed the DNS Resolver Cache." The nbtstat -R clears NetBIOS names. If you're on a domain, also run gpupdate /force to refresh policies.
- Try the IP address directly. Instead of
\\server\share, use\\192.168.1.100\share. If that works, the problem is name resolution. You can map the drive with the IP as a temporary workaround, but fix DNS long-term. - Check SMB version and client settings. Windows 10/11 disables SMB1 by default. If your NAS or old server only speaks SMB1, you'll get this error. On the server, enable SMB2 or SMB3. Don't re-enable SMB1 on the client—it's a security risk. For a quick test, run
Get-SmbServerConfiguration | Select EnableSMB1Protocolin PowerShell on the server. If it's true, upgrade the server OS or firmware. - Verify the share exists and is shared. On the server, open an elevated Command Prompt and run
net share. You should see the share name listed. If it's missing, recreate it withnet share ShareName=C:\Folder /grant:Everyone,READ(adjust permissions). - Check Windows Credentials. Sometimes saved credentials for the old server name cause confusion. Go to Control Panel > Credential Manager > Windows Credentials. Remove any entries for the server. Then try mapping again—you'll be prompted for credentials, which is fine.
- Restart the Workstation service. On your PC, press Win+R, type
services.msc, find "Workstation" and "Computer Browser" (if present). Right-click and restart both. The Workstation service handles SMB client connections; if it's stopped, you can't reach any shares.
If It Still Fails
If you've done all that and still see 0x00000043, check these:
- Firewall on the server. Port 445 (SMB) must be open. On Windows Server, run
Test-NetConnection -ComputerName server -Port 445in PowerShell. If it fails, the firewall is blocking. - DNS suffix search list. If you're on a domain but your PC's DNS suffix doesn't match, names won't resolve. Run
ipconfig /alland look at "Connection-specific DNS Suffix." It should match your domain (e.g.,corp.example.com). If not, set it manually in adapter settings. - LMHOSTS file. As a last resort, add an entry to
C:\Windows\System32\drivers\etc\lmhostswith the server's IP and name. This bypasses DNS for NetBIOS. Format:192.168.1.100 server #PRE. Then runnbtstat -Ragain. - Router or switch issue. If the server is on a different subnet, make sure routing is set up. A quick test:
tracert servershows where packets die.
One more thing: if you're connecting through a VPN, some clients block SMB traffic by default. Check your VPN client's settings for "Allow local network access" or similar. I've seen this with Cisco AnyConnect and FortiClient—they'll happily let you RDP but block port 445.
Finally, if the share is on a NAS, log into its web interface and confirm the share is still enabled. Synology and QNAP sometimes disable shares after a firmware update. Re-enable it, and you're back in business.