Fix 0X00000906 NERR_NetNameNotFound Share Error

Error 0X00000906 (NERR_NetNameNotFound) means Windows can't find the share you're trying to reach. The name changed, got removed, or the machine's using a different one.

You double-click a mapped drive (or run net use) and Windows slaps you with 0X00000906 — NERR_NetNameNotFound — "This shared resource does not exist." Annoying, but fixable in about two minutes once you know where to look.

Fix it now

Confirm the share actually exists on the host. Open an elevated Command Prompt on the machine hosting the share (not the one throwing the error) and run:
```
net share
```
You'll get a list of every share plus its local path. If your share name isn't there, that's your problem — someone renamed it or deleted it. Add it back with:
```
net share MyShare=C:\Data\MyShare /grant:Everyone,READ
```
Check the client-side mapping. On the machine throwing the error:
```
net use
```
Look for the drive letter pointing at the old name. Delete it and remap:
```
net use Z: /delete
net use Z: \\HOSTNAME\MyShare /persistent:yes
```
Kill stale credentials. This is the one people miss. Cached creds from an old login will make Windows fail to even negotiate the share. Run:
```
cmdkey /list
cmdkey /delete:HOSTNAME
```
Then remap. I've had clients where the share existed fine, permissions were wide open, and this alone was the whole problem.
Verify the host is reachable at all. If ping fails, stop here — you've got a network issue, not a share issue.
```
ping HOSTNAME
net view \\HOSTNAME
```
An empty net view result with no error means the machine is up but nothing is shared.
Check for a hidden or renamed share. Shares ending in $ are hidden from browsing but still accessible by name. If someone renamed Accounting to Accounting$, every shortcut pointing at the old name dies.

Why this error happens

NERR_NetNameNotFound is exactly what it sounds like: the NetBIOS/SMB name you asked for doesn't exist in the target server's share table. Windows resolves the path, talks to the host, asks "do you have a share called MyShare?", and the host says no. The name itself is the missing piece — not the machine, not the credentials, not the folder on disk.

Common triggers:

Someone renamed the share on the host (very common in small offices where one person "organizes" the file server).
A printer was replaced and the new one was shared under a different name.
A script or GPO was pointing at a share that got decommissioned months ago.
DFS namespace still references an old target.
Your mapped drive shortcut was made before someone added or removed a trailing $.

I had a client last quarter whose entire shipping station died on a Monday morning because their old Netgear NAS had been swapped for a Synology over the weekend and the new admin named the share Shipping_Files instead of Shipping. Every mapped drive on six workstations returned 0X00000906. Fifteen-minute fix, but it cost them two hours of shipping.

Less common variations

The share exists but you still get 0X00000906

You're probably hitting a case mismatch or a typo in the middle of the string. SMB share names on Windows are case-insensitive once matched, but the lookup from the client can be picky with trailing spaces or a mismatched backslash count. Try a clean manual mount:

net use * \\192.168.1.50\MyShare

Using the IP strips out DNS/NetBIOS name issues and tells you whether the share name itself is the problem.

DFS namespace returns 0X00000906

If you're going through a DFS path like \\domain.com\files\dept, the folder target is probably disabled or the namespace is stale. Check on the DFS server:

dfsutil target show \\domain.com\files

Re-enable the target, or remove and re-add the folder link.

Printer shares via GPO

Shared printer paths are the usual suspect in school and clinic environments. If a GPO deploys \\PRINT01\HP-LaserJet and somebody at the site renamed the queue to HP-LJ-3rd-Floor, every login throws 0X00000906 in the event log under GroupPolicy. Fix the GPO's printer path under User Configuration > Preferences > Control Panel Settings > Printers.

Old login scripts

Netlogon scripts still mapping \\OLD-SRV\Data after a domain migration will throw this error on every login and scare users into thinking the network is down. Grep your SYSVOL scripts:

findstr /s /i "net use" \\domain\SYSVOL\domain\scripts\*.*

Case: Samba / Linux share names

On Samba servers, share names are case-sensitive in the config, and Windows clients sometimes pass them lowercased. If the share in smb.conf is [SharedDocs] and the client asks for shareddocs, some Samba versions return NERR_NetNameNotFound instead of resolving. Either match case in your client config, or set case sensitive = no in the share stanza.

Prevention

Never rename a share on a live server without auditing who's mapped to it. net session on the host shows active connections, and you can check SMB open files under Computer Management.
Use group policy preferences for drive mappings instead of login scripts. When you change a share name, you change it in one place.
When you decommission a file server, keep the old hostname as a CNAME pointing to the new one for at least six months. Same for old share names — recreate them as alias shares pointing at the new folder.
Document share names in a spreadsheet or CMDB. Sounds boring. It's saved me more hours than any monitoring tool.
If you're on a Synology, QNAP, or TrueNAS and you set up shares via the web UI, double-check the actual name it created — those UIs love to append suffixes or replace spaces with underscores.

The short version: 0X00000906 always means the name doesn't exist on the host. Find the host, run net share, compare the name, fix the mapping, clear stale creds. Nine times out of ten that's it.