Fix ERROR_NETNAME_DELETED (0X00000040) in Windows
This error means Windows lost the network connection to a mapped drive or printer. It's almost always a stale credential or flaky SMB session.
Quick answer: Run net use * /delete in an admin command prompt, then remap the drive. If that doesn't work, kill the SMB session with net session /delete and try again.
So you're working on a file, or trying to print, and Windows throws "ERROR_NETNAME_DELETED" (0X00000040). It translates to "the specified network name is no longer available." And honestly, it's almost never about the network name actually being deleted. It's a stale connection issue—Windows lost its session with the server but didn't clean up. I've seen this a ton on Windows 10 and Server 2016/2019, especially after a power outage or when someone reboots the file server without warning. One client had it happen every time their NAS went to sleep to save power. Drove them nuts.
Why This Happens
The SMB protocol keeps a session alive with credentials. If the server drops the session—because of a reboot, timeout, or network blip—the client still thinks it's connected. When you try to access the mapped drive or printer again, Windows tries the stale session, fails, and gives you this error. The fix is to force Windows to let go and start fresh.
Step-by-Step Fix
- Open Command Prompt as admin. Right-click Start, select "Command Prompt (Admin)" or "Terminal (Admin)".
- Kill all mapped drives. Run this:
Typenet use * /deleteYwhen asked to confirm. This rips out every mapped drive, even hidden ones. - Clear the SMB session cache. Run:
This tells Windows to dump all cached network sessions. Don't worry—it'll reconnect when you need it.net session /delete - Reconnect the drive. Open File Explorer, right-click "This PC", select "Map network drive". Re-enter the path and check "Reconnect at sign-in". Use the same credentials as before.
- Test it. Try opening a file or saving to the drive. Should work now.
If That Doesn't Fix It
Sometimes the SMB service itself gets stuck. Do this:
- Open Services (type
services.mscin Run). - Find "Server" service. Right-click and select "Restart".
- Also restart "Workstation" service.
- Retry step 1-5 from above.
If you're on a domain and using Group Policy mapped drives, you might need to wait for a refresh or run gpupdate /force from the command prompt.
Alternative Fix: Clear Credential Manager
Stale credentials can hide in Windows Credential Manager. Here's how to nuke them:
- Open Control Panel > Credential Manager > Windows Credentials.
- Look for entries related to the server name or IP address (like
\server\share). - Remove each one. Yes, all of them. It's safe.
- Remap the drive again.
Had a client last week where this was the only thing that worked—the session was in Credential Manager but not listed anywhere else.
Prevention Tips
- Set SMB keepalive. On the server, you can increase the keepalive interval so sessions don't drop as easily. In PowerShell on the server:
Set-SmbServerConfiguration -KeepAliveInterval 60(default is 30 seconds). - Use IP addresses instead of hostnames. DNS changes can cause stale entries. Not a magic bullet, but helps in some cases.
- Wake-on-LAN for NAS devices. If your NAS sleeps, configure it to stay awake during business hours.
- Reboot rarely. Yeah, I know, sometimes you have to. But if you reboot the server, expect users on Windows 7 or 10 to get this error. Tell them to run the
net usecommand.
In short: this error is ugly but easy to fix. Kill the session, map fresh, move on. Don't waste time chasing ghosts—it's almost always a credential or session problem.
Was this solution helpful?