Fix STATUS_OBJECTID_EXISTS Error 0XC000022B

When This Error Hits You

You're running a backup script or syncing files via DFS Replication, and bam — error code 0XC000022B pops up. Maybe your robocopy command throws it, or a PowerShell script trying to set a unique identifier on every file. The exact trigger: you're trying to assign an object ID to a file or folder that already has one. This happens most often in environments where files get moved or copied across NTFS volumes, like during a file server migration or when archiving data. Had a client last month whose nightly backup to an external drive kept failing on one particular folder — turned out every file in there already had object IDs from a previous backup run.

What's Actually Going On

Object IDs are little metadata tags NTFS attaches to files and folders. They're like a unique serial number, used by Distributed Link Tracking and other Windows services to keep file links working even if you move or rename the file. The problem: each file can only have one object ID. Try to set a second one, and Windows throws 0XC000022B. The root cause is almost always either:

A backup or sync tool trying to stamp a fresh ID on every file, regardless of existing ones.
DFS Replication creating conflicting IDs when the same file exists in multiple replicas.
Manual scripts that call fsutil objectid set without checking first.

This isn't a data corruption issue — the file's content is fine. It's just a metadata conflict.

How to Fix It

Skip the Windows GUI — there's no checkbox anywhere for object IDs. You'll use fsutil from the command line. Here's the step-by-step:

Identify the files causing the error. Look at your backup or script logs. Note the full file path. Usually it'll be something like D:\Backups\ProjectX\file.txt.
Open an elevated Command Prompt. Right-click Command Prompt and pick "Run as administrator".
Check if a file has an object ID. Run:
```
fsutil objectid query "D:\Backups\ProjectX\file.txt"
```
If it returns a hex ID string, that file already has one.
Remove the existing object ID. This clears it so you can set a new one:
```
fsutil objectid delete "D:\Backups\ProjectX\file.txt"
```
No confirmation prompt — it just removes it.
Retry your backup or script. The error should vanish. If you're using a robocopy with the /COPYALL flag, it'll re-create the object ID cleanly.

For folders, same commands work. If you have hundreds of files, script it with a loop:

for /r "D:\Backups\ProjectX" %f in (*) do fsutil objectid delete "%f"

Run that from cmd (double the % signs in a batch file).

When the Fix Doesn't Stick

If the error comes back, check these three things:

Is the file locked? Another process might hold a handle on it. Use handle.exe from Sysinternals or locksmith (Windows 10/11) to find the culprit.
Are you running the command on the right drive? Object IDs only exist on NTFS volumes. If you're accidentally working on a FAT32 or exFAT drive, fsutil won't work — and that error might be something else entirely.
Does your backup tool have a switch to skip object IDs? Robocopy's /COPYALL includes object IDs. Swap to /COPY:DAT (Data, Attributes, Timestamps) to avoid the conflict. Same logic applies to Veeam or other backup software that mirrors NTFS metadata.

In rare cases, a corrupted NTFS metadata area can cause object IDs to appear on files that were never manually assigned one. Run chkdsk /f on the volume to fix that. But 9 times out of 10, it's just a backup script being too aggressive.