0XC000026D: DFS Unavailable on Server – Fix Now

You try to access a DFS share—say \\domain.local\data\sales—and instead of your files, you get error 0XC000026D with the message “STATUS_DFS_UNAVAILABLE: The DFS service is unavailable on the contacted server.” This usually happens on Windows Server 2012 R2, 2016, or 2019, often after a reboot or a network change. It's infuriating because the server itself is running, pingable, and other shares work fine.

Why This Happens

The Distributed File System (DFS) service is a namespace layer on top of SMB. You connect to \\server\share, the client asks the DFS driver (Dfsc.sys) to resolve the path to the actual file server. If the DFS service (the DFsRole or DFsService in older versions) isn't running, or the DFS namespace isn't published correctly, the client gets this error. The root cause is almost always one of three things:

• The DFS Namespace service (Dfs) is stopped or disabled.
• The DFS Replication service (DFSR) is stalled or corrupted.
• The registry entry that tells the server which DFS roots to host is missing or misconfigured.

Step-by-Step Fix

Follow these steps in order. Skip the ones you've already tried, but don't skip the first one—it's the most common fix.

Step 1: Restart the DFS Services

On the server that's supposed to host the DFS namespace (the one you're connecting to), open PowerShell as Administrator and run:

Get-Service -Name Dfs, DFSR | Restart-Service -Force

Wait 10 seconds, then try accessing the share again. If it works, you're done. If not, proceed.

Step 2: Check Service Status and Startup Types

Verify both services are running and set to start automatically at boot:

Get-Service -Name Dfs, DFSR | Format-Table Name, Status, StartType

If DFSR shows Stopped, run Start-Service DFSR. If Dfs is stopped, run Start-Service Dfs. For both, ensure StartType is Automatic. If it's Disabled, set it with:

Set-Service -Name Dfs -StartupType Automatic
Set-Service -Name DFSR -StartupType Automatic

Step 3: Re-register the DFS Namespace in Registry

Sometimes the DFS service is running but doesn't know which roots to serve. This is especially common after removing and re-adding the DFS role. Open Registry Editor and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Roots\Domain

Check if your namespace name (e.g., data) appears as a subkey. If it's missing, you need to re-add the namespace via DFS Management console:

1. Open DFS Management (dfsmgmt.msc).
2. Right-click Namespaces and select Add Namespace to Display.
3. Enter the path to your namespace (e.g., \\domain.local\data).
4. If it fails, delete and recreate the namespace. Yes, it's a pain, but it works.

Step 4: Force DFS Discovery from Client

On the client machine, flush the DFS cache to force a fresh lookup:

dfsutil /pktflush
dfsutil /purgeMupCache

Then from an elevated command prompt, run:

net use * /delete

Reconnect to the share. This clears out stale referrals that might point to a dead server.

What to Check If It Still Fails

If the error persists, look for deeper issues:

• Event logs: Open Event Viewer > Applications and Services Logs > DFS Namespace. Error ID 144 points to a permission problem on the shared folder. ID 145 means the namespace root folder doesn't exist.
• SID mismatch: If you cloned this server or restored it from backup, the machine SID might be duplicated. Run Sysprep or use New-SID from the PSGet module.
• Network path: Try connecting directly to the file server via its IP (e.g., \\192.168.1.10\share). If that works, the issue is DNS resolution of the DFS referral.
• AD replication: DFS relies on Active Directory for namespace discovery. Check that the DFSR-LocalSettings object in AD is replicated across all domain controllers. Use repadmin /replsummary to spot replication failures.

I've seen this error a hundred times in help desk. Nine times out of ten, restarting both DFS services does the trick. The other time? It's a registry hiccup from a botched role removal. Stick with the steps above, and you'll get your shares back.