You're running a backup job or a dedup integrity check on a Windows Server volume that has Data Deduplication enabled. The job fails with STATUS_DIRECTORY_NOT_RM (0XC0190008) and tells you “The specified directory does not contain a file system resource manager.” This usually happens after a crash, a chkdsk run, or a botched restore that left the dedup metadata folder in a broken state.
The root cause is simple: Data Deduplication stores its metadata in a hidden system folder called System Volume Information\Dedup on the volume. If that folder is missing, corrupted, or the dedup filter driver can't load it, the volume no longer looks like a dedup volume to the OS. The backup agent or dedup tool queries it and gets this exact error.
What you're dealing with
This isn't a hardware failure. The drive itself is fine. The dedup metadata is gone or unreadable. You have two paths forward:
- Rebuild the dedup metadata from scratch.
- Disable dedup and move on without it (if you don't need it).
I'd start with rebuilding because it keeps your dedup savings. But if the volume is small or you're fed up, disabling is faster.
Step-by-step fix
Step 1: Identify the volume
Open an elevated PowerShell prompt (Run as Administrator). Run Get-Volume and note the drive letter or mount point that's failing. In my experience it's almost always a data volume, not C:. For example, D:.
Expected result: a list of volumes. Find the one that matches the error path.
Step 2: Check dedup status
Run this to see if the volume is dedup-enabled:
Get-DedupVolume -Volume D:
If it returns an error or shows Enabled : False, that's your clue. If it shows Enabled : True, the metadata is likely corrupt.
Expected result: either a status object or an error message. An error like "Cannot find an object" means the dedup store isn't recognized.
Step 3: Decide your path
Path A: Rebuild dedup metadata
Run the dedup repair job:
Start-DedupJob -Type Repair -Volume D:
Wait for it to finish. You can monitor progress with Get-DedupJob. This rebuilds the metadata from scratch by scanning all files. It can take a while on large volumes—hours if you're at 5 TB or more.
After the repair job completes, run a full integrity check:
Start-DedupJob -Type Optimization -Volume D:
That's not strictly necessary for the error, but it validates the new metadata.
Expected outcome: the error should disappear. Try your backup or dedup scan again.
Path B: Disable dedup
If you don't care about dedup savings, disable it:
Disable-DedupVolume -Volume D:
Unregister-DedupSchedule -Volume D:
The second command removes any scheduled dedup jobs. After that, the volume is just a normal NTFS volume. The error won't appear anymore because there's no dedup resource manager to look for.
Expected outcome: the volume works normally, but you lose dedup compression.
Step 4: Force cleanup if metadata is still stuck
Sometimes the old metadata folder lingers and confuses things. You can delete it manually, but be careful. Only do this if you've disabled dedup or you're absolutely sure the volume doesn't contain dedup data you need.
Open an elevated command prompt and run:
takeown /f "D:\System Volume Information\Dedup" /r /d y
rd /s /q "D:\System Volume Information\Dedup"
After deleting, re-enable dedup if you want a fresh start:
Enable-DedupVolume -Volume D:
Then start an optimization job to rebuild metadata.
Expected result: the folder is gone, and dedup re-initializes on the next job.
What to check if it still fails
If the error persists after a repair job, the filesystem itself might have issues. Run chkdsk D: /f (this requires a restart if the volume is in use). After chkdsk, try the repair again.
Also check the event log. Open Event Viewer, go to Applications and Services Logs > Microsoft > Windows > Deduplication. Look for errors with event ID 2020 or 2021. Those often give the specific reason the metadata can't be mounted—like a corrupted log or a failing disk sector.
If you see disk-related errors, run Get-PhysicalDisk and check health. If the disk is healthy and chkdsk doesn't find anything, I'd suspect a bug in the dedup driver. Update your Server to the latest cumulative update—I've seen 0xC0190008 fixed by a patch for file systems.
One more thing: if the volume is part of a failover cluster, ensure the volume is online and not in maintenance mode. A cluster resource that's paused can cause this error too.
That covers the realistic scenarios. Rebuilding the metadata fixes it in most cases. If you're in a hurry, disabling dedup gets you running again, but you'll lose the space savings.