Fix TRK_E_VOLUME_QUOTA_EXCEEDED (0x8DEAD01C) on Windows Server

Before You Start: What This Error Means

You're seeing TRK_E_VOLUME_QUOTA_EXCEEDED (0x8DEAD01C) because the storage volume you're writing to has hit a quota limit. This happens on Windows Server (2012 through 2022) and some NAS devices that use NTFS quotas or File Server Resource Manager (FSRM). Real-world trigger: you try to save a database backup or copy a large file to a shared folder, and the server throws this error instead of completing the write.

Don't panic. Most of the time, this is either a full disk or a soft quota you can fix in under a minute. We'll start with the quickest fix and work up to more involved changes. You can stop when the error goes away.

Quick Fix (30 seconds): Clean Up Temp Files

Open File Explorer on the server (or the machine with the drive mapped to the quota volume). Navigate to the drive letter showing the error—say E:\. Right-click it and pick Properties. Look at the pie chart under the General tab. If you see less than 5% free space, that's your problem. Quotas often trigger when the volume is nearly full, even if no explicit quota is set.

Run the built-in Disk Cleanup tool. Press Windows Key + R, type cleanmgr, and hit Enter. Select the same drive. Check boxes for Temporary files, Recycle Bin, and Delivery Optimization Files. Click OK, then Delete Files. After it finishes, try your write operation again. If it works, you're done. If not, move to the moderate fix.

Expectation: after cleanup, you should see the free space increase by a few GB. The error might vanish immediately.

Moderate Fix (5 minutes): Check and Adjust NTFS Quotas

The quick fix didn't work? The volume probably has an explicit quota limit. Here's how to check it.

1. Open File Explorer and right-click the drive showing the error. Select Properties.
2. Go to the Quota tab. Click Show Quota Settings.
3. You'll see a checkbox: Enable quota management. If it's checked, look at the Limit disk space to field below it. That's the hard cap. Write down the value (e.g., 100 GB).
4. Click Quota Entries. In the window that opens, find the user or group that's hitting the limit. You'll see a red exclamation mark next to their row. Double-click that entry.
5. In the dialog, increase the Limit disk space to value. If the current limit is 100 GB, try bumping it to 150 GB. Click OK.
6. Close all quota windows. Click Apply on the drive Properties window.

Expectation: after applying, the red exclamation should disappear from Quota Entries. Try your file operation again. If the error's gone, you're set. If not, move to the advanced fix.

Note: If the Quota tab isn't there, the volume may be using FSRM instead. Skip to the advanced fix.

Advanced Fix (15+ minutes): FSRM Quotas or Command-Line Check

Some servers, especially those running File Server Resource Manager, use FSRM quotas instead of the older NTFS quotas. Here's how to check and fix that.

Check FSRM Quotas

1. Open Server Manager. Go to Tools > File Server Resource Manager.
2. In the left pane, expand Quota Management and click Quotas.
3. You'll see a list of quota paths. Look for the volume or folder where the error happens. It'll show Limit (e.g., 100 GB) and Used (e.g., 100 GB). If the used space equals the limit, that's your issue.
4. Right-click that quota entry and pick Edit Quota Properties.
5. Increase the limit by at least 20%. Click OK.
6. Close FSRM and retry your operation.

If the quota still shows red, you might have a nested quota. Check the Quotas list for any child folders—sometimes a subfolder has a stricter limit.

Command-Line Deep Dive (if UI doesn't help)

Open PowerShell as Administrator. Run this command to list all NTFS quotas on the drive (replace E: with your drive):

fsutil quota query E:

You'll see output like:

User                  Limit        Used         WarnLevel    Percent
S-1-5-21-...          107374182400 107374182400 0            100

That 107374182400 is 100 GB in bytes. If the Used equals the Limit, you've confirmed the quota is maxed. To increase it, use:

fsutil quota modify E: 150000000000 150000000000 S-1-5-21-...

Replace the size in bytes (150 GB = 161061273600 bytes) and the user SID. To find the user SID, run whoami /user on the affected machine. After modifying, run fsutil quota query E: again—the Limit should show the new value.

Expectation: after this, the error should be gone. If you still see it, the volume might be using an SMB share quota set on the NAS or storage array. Check your storage appliance's management console for share quotas.

What If None of This Works?

If you've cleaned temp files, checked NTFS and FSRM quotas, and still hit 0x8DEAD01C, the quota might be enforced at the hardware level (like a SAN or NAS that reports via SMB). Log into your storage array's admin interface. Look for Share Quotas or User Quotas for the affected volume. Adjust there. Also check the Event Viewer under Applications and Services Logs > Microsoft > Windows > FileServer-Resource-Manager > Operational for detailed quota violation logs. That will tell you exactly which user hit the limit.

One last thing: if this is a volume that stores backups or logs, consider setting up automatic cleanup scripts to prevent future hits. But for now, you're likely sorted after one of these steps.