Fix DFS Error 0X00000A69: Share Not Found

You're staring at an event log entry or a command prompt output that says 0X00000A69 (which translates to NERR_DfsNoSuchShare). This usually pops up when you're trying to add a folder target to a DFS namespace, or when a DFS client tries to access a link that's been mapped to a share that doesn't exist anymore. I've seen it happen after a server migration where someone forgot to recreate the share, or after a botched rename where the share path got updated in the namespace but the actual share on the target server was never created.

What's actually happening here?

The DFS namespace is just a directory of links. Each link points to a UNC path like \Server01\Data. When the DFS service tries to resolve that link, it asks Server01, "Hey, do you have a share called Data?" If Server01 says "No," you get this error. The namespace itself is fine—it's the target that's broken.

Even if the share exists, there's another catch: the share must be a Windows file share (SMB). You can't point a DFS link to a print share or a share that's been disabled. Also, the share has to be accessible from the DFS server using the same credentials the DFS service runs under. If the DFS service account doesn't have permission to read the share list on the target server, you'll get this error even though the share is there.

How to fix it

Let's walk through this step by step. I'm assuming you have administrative rights on both the DFS server and the target server.

Confirm the share actually exists on the target server. Log onto the target server (the one that should host the share) and open a Command Prompt as Administrator. Run:

net share

Look for your share name in the list. If it's missing, you need to create it. If it's there, note the exact name—DFS is case-insensitive, but typos happen.

Check the share path on the DFS link. Go to Server Manager > Tools > DFS Management. Expand Namespaces, then your namespace, and find the folder that's causing the error. Right-click it and select Properties. Click on the Folder Targets tab. You'll see the list of target UNC paths. Compare each one to the share you confirmed in step 1. If the share name is different, that's your problem.
Remove or correct the bad target. If the path is wrong, click Edit and type the correct UNC path. If the target server no longer hosts that share, click Remove to delete the target. You can always add it back later.
Verify permissions on the share. On the target server, right-click the folder that's shared, go to Properties > Sharing, and note the share permissions. The DFS service account (usually NT AUTHORITY\SYSTEM or a domain account) needs at least Read access to the share itself. If the share permissions are too restrictive, the DFS server can't see it.
Test the UNC path manually. On the DFS server, open File Explorer and type the UNC path you used in the namespace. For example, \\Server01\Data. If you get an error, you've found the issue. If it opens fine, the problem might be a stale DFS cache.
Clear the DFS client cache (if the error appears on a client). Sometimes clients cache old namespace data. On the machine that's showing the error, run:

dfsutil cache /clear

Then try accessing the namespace again. You might need to wait a few minutes for the cache to repopulate.

Restart the DFS service if nothing else works. On the DFS server, open an elevated Command Prompt and run:

net stop dfs && net start dfs

This forces the DFS service to rescan all targets. It's a blunt instrument, but sometimes it clears up weird state.

What to check if it still fails

If you've done all the above and the error persists, check the target server's event log. Look under Windows Logs > System for events from source Srv or LanmanServer that might indicate the share is failing to start. Also check if the target server's firewall is blocking SMB traffic (ports 445 and 139). And verify the target server is actually online—sounds basic, but I've chased this error for an hour only to find the server was rebooted and hadn't come back up.

One more thing: if you're using DFS Replication, make sure the replicated folder is on the same volume as the share. DFSR doesn't play well with shares that are on different volumes than the replicated root. And if you're on Server 2012 or older, check if the namespace is domain-based or standalone—domain-based namespaces need the targets to be in the same domain or a trusted domain.

You might also want to check the DFS namespace root's permissions. If the root is in a domain and the target is in a different site, you might be hitting a replication delay. Run dfsutil root info on both the DFS server and the target server to compare the state.

At the end of the day, this error is almost always a mismatch between what the namespace says and what actually exists on the target server. Fix the path, confirm the share, and you're done. If you're still stuck after all that, post the exact wording of the error and your DFS link's UNC path in a comment below—I'll help you sort it out.