0X00000A7B: DFS child/parent share conflict fix

When you run into this

You're on a Windows Server (2016, 2019, or 2022) and you try to share a folder through File Explorer or net share. Maybe it's D:\Data\Projects. You get the error 0X00000A7B with the message A child or parent directory of the share is already in a DFS. This doesn't happen randomly — it only fires when that folder or one of its parent folders is already a DFS namespace root or a DFS link target. Real-world trigger: You set up a DFS namespace at \\domain\data pointing to D:\Data, then try to share D:\Data\Projects as \\Server\Projects. Windows slams the door.

What's actually happening here

DFS (Distributed File System) builds a tree of namespace roots and folder targets. The rule is simple: you can't have an independent Windows share that lives inside a DFS namespace or that contains a DFS root in its path. Think of it like virtual directories in IIS — you can't map a physical subfolder as a separate site if the parent is already a site. Windows checks the entire path when you create or modify a share. If any ancestor or descendant folder is part of a DFS namespace, it rejects the new share with error 0X00000A7B.

The reason step 3 works (see below) is because removing the share from the DFS namespace breaks the linkage. Once the path isn't part of DFS, Windows lets you share it. But that's a nuclear option — you almost never want to do that. A better approach is to move the folder you want to share outside the DFS tree.

The fix

Identify which DFS namespace owns the conflict. Open DFS Management console (dfsmgmt.msc). Look at your namespaces — find the one that includes either the folder you're trying to share or its parent.
Decide: do you need the DFS namespace or the new share more? If you need the namespace (likely), you can't keep the folder where it is. If you need the new share more, you'll remove the DFS linkage, but that breaks the namespace path.
If keeping the DFS namespace, move the folder. Create a new directory outside the DFS root — e.g., E:\Projects instead of D:\Data\Projects. Copy your data there, then share E:\Projects. The old DFS path at D:\Data stays intact.
If you must share that specific folder path and can't move it, remove the DFS target. In DFS Management, right-click the folder target (e.g., D:\Data or D:\Data\Projects) and select Remove Target. This removes the DFS link. Then you can share that folder normally. But now the namespace path is broken for users — they'll get access denied or path not found.
Reboot or restart the Server service (net stop Server && net start Server) to flush any cached share state. Sometimes the error persists even after removal until the service reloads.
Verify with net share or Get-SmbShare in PowerShell. Your new share should appear without the 0X00000A7B error.

Still failing? Check these

Stale DFS metadata. Run dfsutil /purgemupcache on the server to clear local referral cache — it can hold references to old DFS links that aren't visible in the UI.
Hidden or inherited DFS links. A grandparent folder might be part of a DFS namespace you forgot about. Run dfsutil /view /root:\\domain\namespace to list every target in the namespace.
File screening or quota from File Server Resource Manager (FSRM) — not directly related but can produce similar share-creation failures. Check the System and FSRM event logs.
Windows share naming conflict. Error 0X00000A7B is specific to DFS nesting, but it's worth double-checking you're not trying to reuse an existing share name. Use a unique name.

Short version: You can't share a folder that lives under a DFS root or contains a DFS link. Move the folder to a different drive or directory, or remove it from DFS. No workaround preserves both the namespace and the independent share at the same path — that's by design.