Fix 0X00000A6E: Server Not DFS-Aware

This error pops up when a client tries to access a DFS path but the target server doesn't announce DFS support. Usually a registry tweak or SMB signing issue. Here's the fix.

When this error shows up

You're on a Windows 10 or Server 2016+ workstation, trying to map a drive to \\domain\dfsroot\share or just browsing to that UNC path. Instead of the share contents, you get an error dialog with 0X00000A6E and text saying The server is not DFS-aware. This typically happens after a failover, a new file server added to the DFS namespace, or when a third-party SMB appliance (like a NetApp or Synology) is part of the namespace.

The trigger is almost always the client making a DFS referral request to the namespace server, getting a list of targets, then trying to connect to one of those targets. If that target doesn't respond correctly to the DFS referral protocol, your client throws this exact code.

What's actually happening here is

DFS (Distributed File System) works in two layers: the namespace server (often a Domain Controller or dedicated file server) holds the namespace and responds to DFS_GET_REFERRAL requests. When you access \\domain\dfsroot\share, your client first queries the namespace server, gets back a list of actual server/share targets, then makes a direct SMB connection to one of those targets.

The problem: your client sends a FSCTL_DFS_GET_REFERRALS control code to the target server to confirm it's part of the same DFS. If the target is a regular SMB share that doesn't have DFS enabled, or if the target has SMB signing disabled while the client expects it, the referral request fails. Windows then treats that target as non-DFS-aware and gives you 0X00000A6E.

The root cause is almost always one of these three:

The target server is not actually a DFS root target — it's a plain SMB share added by mistake to the namespace.
The target has SMB signing disabled, and your client requires it (or vice versa).
The target is running an old SMB dialect that doesn't handle referral requests properly.

I've seen this most often on Windows Server 2012 R2 targets after a security update, and on Linux Samba servers that don't have dfs root = yes set.

The fix that works in most cases

First, verify the target server is actually supposed to be a DFS target. If it's just a regular file server, remove it from the namespace — that's the real fix. But if it should be a DFS target, here's what to check and adjust.

Enable DFS on the target server. On Windows Server, open Server Manager → File and Storage Services → File Services → DFS Namespaces → right-click the namespace root → Add Folder Target. Make sure the target path points to a share that exists and is accessible. If you're using a non-Windows target, check its docs for DFS support. For Samba, edit /etc/samba/smb.conf and set dfs root = yes under the share definition, then restart smbd.
Check SMB signing settings. On the target server, run this in an elevated PowerShell or CMD:
```
Get-SmbServerConfiguration | Select EnableSecuritySignature, RequireSecuritySignature
```
If RequireSecuritySignature is $true and the client isn't set to sign, the referral exchange fails. Set both to $true on the target:
```
Set-SmbServerConfiguration -EnableSecuritySignature $true -RequireSecuritySignature $true -Force
```
Then reboot the target or restart the LanmanServer service. On the client side, make sure RequireSecuritySignature is also $true (default on modern Windows).
Force SMB 3.0 or higher. Older SMB dialects (like SMB 1.0) don't support DFS referrals properly. On the target, disable SMB 1.0: go to Control Panel → Programs and Features → Turn Windows features on or off and uncheck SMB 1.0/CIFS File Sharing Support. Then reboot. You can verify the active SMB version on the client with Get-SmbConnection after mapping.
Check the namespace referral order. Sometimes a target is listed but has a dead link. In DFS Management, right-click the folder → Properties → Referrals tab. Set a reasonable Referral caching time (300 seconds is fine) and ensure Target priority isn't set to First among all targets for a broken server.
Clear the DFS client cache. Your client may be caching a bad referral. Run this to flush it:
```
dfsutil.exe cache flush
```
Then re-access the DFS path.

Still failing? Check these.

If the error persists, I'd look at the event logs. On the client, open Event Viewer → Windows Logs → System and look for source SMBClient or DFS around the time of the error. You'll often see a follow-up event with status 0xC00000BA or similar that points to a specific target. That tells you exactly which server is failing.

Also, test the target directly: try mapping to \\targetserver\share (not the DFS path). If that works but DFS doesn't, it's definitely the referral handshake. If direct mapping fails too, you've got a general SMB issue — check firewalls, DNS, and whether the target is online.

One more thing: if you're mixing SMB versions (like a Windows Server 2019 target and a Windows 7 client), the older client might not support the newer referral format. In that case, you'd need to update the client or keep a compatibility mode on the target. But honestly, if you're still running Windows 7, you've got bigger problems.

My rule of thumb: if the target doesn't advertise DFS support, it doesn't belong in the namespace. Remove it, or make it truly DFS-aware. The error is your client being honest with you.