Fix DFS Cyclical Name Error 0X00000A72

You're setting up a DFS namespace, everything looks right on paper, then boom — you get the 0X00000A72 error. The full message is NERR_DfsCyclicalName — a cycle in the DFS name was detected. This usually happens when you try to add a DFS link that points back to the same namespace root or creates a loop between two DFS servers.

I ran into this on a client's Windows Server 2019 box last year. They had a namespace called \domain\files and tried to add a link \domain\files\projects that pointed to \server1\projects, but \server1\projects was already a DFS target that included a link back to \domain\files. It's an easy mistake if you're juggling multiple shares.

Root Cause: The Loop

The DFS service on Windows (works the same on Server 2012 R2, 2016, 2019, 2022) checks for cycles when you add or modify a link. If it finds that the target folder path you're linking to already contains a link that leads back to the same namespace — or one of its parent folders — it throws 0X00000A72. It's a safety catch to prevent infinite recursion. Without it, users could get stuck in an endless loop, and the DFS service would choke.

There are two common triggers:

• Link points back to the root: You added a link like \domain\sales and its target is \server2\sales, but \server2\sales itself has a subfolder that is a DFS link back to \domain\sales or the root.
• Cross-link cycle: Two DFS namespaces reference each other. For example, \domain\marketing points to \domain\public, and \domain\public points back to \domain\marketing.

Fix: Break the Cycle

Here's the step-by-step fix. You'll need admin rights on the DFS namespace servers.

1. Open DFS Management: Go to Server Manager > Tools > DFS Management. Expand Namespaces and find your namespace.
2. List all links: Click on the namespace root, then look at the Namespace Servers tab. Note all the servers hosting the root. Also check the Links tab and write down every link name and target path.
3. Trace the targets: For each link, right-click and choose Properties > Targets. The target is the UNC path (like \server1\share). If the target is another DFS link (it'll show as a DFS folder target), that's a red flag.
4. Find the loop: The fastest way is using PowerShell. Run this on any domain controller or server with the DFS module:

Get-DfsnFolder -Path \\domain\namespace | ForEach-Object { $_.Path; Get-DfsnFolderTarget -Path $_.Path | Select TargetPath }

Replace \domain\namespace with your actual namespace. This prints all links and their targets. Look for any target that matches another link in the same namespace or points back to the root.

5. Remove the bad link: Once you find the offending link, delete it. In DFS Management, right-click the link and choose Delete. Confirm. Or use PowerShell:

Remove-DfsnFolder -Path \\domain\namespace\badlink -Force

Replace badlink with the actual link name.

6. Recreate the link correctly: Add the link again, but this time make sure the target folder doesn't contain any DFS links back to the same namespace. If you must point to a folder that's already part of the DFS, use a direct UNC path to the shared folder (not another DFS link).
7. Test: Run dfsutil /pfr /server:ServerName from an admin command prompt to force a refresh. Then check the namespace with dfsutil /root:\domain\namespace /view. The error should be gone.

Still Failing? Check These

If the error comes back, you've got a deeper nesting problem. Some DFS implementations use a folder structure that wraps into itself through multiple jumps. For example:

• Link A -> Folder X
• Folder X -> Link B -> Folder Y
• Folder Y -> Link C -> Folder X (loop!)

To check for these, use the PowerShell command above on every link recursively. If you see the same target path appearing twice, you've got a cycle.

Another thing: If you're using domain-based namespaces, make sure the DFS root targets are all different servers. Two root targets pointing to the same server with different folder structures can create a cycle if improperly linked.

I've also seen this error when someone accidentally created a link with the same name as the namespace root. For example, namespace \domain\share and a link named share pointing to a folder on the same server. That's an instant cycle. Rename or remove that link.

If you still can't fix it, nuke the problem link from command line with dfsutil /UnmapFtRoot /Root:\domain\namespace /Link:badlink — this bypasses the GUI check and forces removal. Then rebuild the link from scratch.