Fix 0XC00002B2: Reparse Attribute Conflict on Windows

This error drives me nuts too

You're trying to set a symbolic link or a junction point, and Windows throws 0XC00002B2 at you. I've been there—it's especially maddening when you've done it a hundred times before. The good news is the fix is usually straightforward. Let's get to it.

The fix: remove the conflicting reparse attribute

Most of the time, this error means the target folder already has a reparse point (like a junction or symlink) that's invisible to Explorer, or the file system's metadata is corrupted in that spot. Here's what actually works:

1. Open Command Prompt as Administrator. Hit Start, type cmd, right-click and pick Run as administrator.
2. Identify the problem path. Suppose your error happened with C:\MyFolder. Run:

   fsutil reparsepoint query "C:\MyFolder"

   If it returns a tag or shows a reparse point, you've found the culprit.
3. Delete the reparse point. Use:

   fsutil reparsepoint delete "C:\MyFolder"

   This nukes the reparse tag without touching the folder contents underneath.
4. Try your operation again. Now set your symbolic link or junction. It should work.

If fsutil says there's no reparse point, skip to the next section.

When permissions are the real issue

I've seen this error pop up when the current user doesn't have SeCreateSymbolicLinkPrivilege—that's the right to create symlinks. On Windows 10 and 11, only admins get this by default. Check your group policy:

• Press Win+R, type gpedit.msc (Pro/Enterprise only) or secpol.msc.
• Go to Local Policies > User Rights Assignment.
• Find Create symbolic links and make sure your user or group is listed.
• If not, add it and reboot.

For Windows Home users: you can't use gpedit. Instead, run secpol.msc and check the same setting. Or just always run your command as Administrator—it sidesteps the privilege check entirely.

Why this error happens

Windows stores reparse data in the file's metadata. If that metadata is corrupt—say from a partial NTFS journal write or a bad driver—the OS refuses to write a new reparse point. The 0XC00002B2 code literally means "reparse attribute conflict." The old tag conflicts with what you're trying to set.

Another common trigger: you try to create a junction on a folder that's already a mount point (like a drive letter attached to a folder). Windows won't let you overlay a junction on top of a mount point. Use mountvol to list mount points first.

Less common variations

Antivirus interference

Some security software (I'm looking at you, McAfee and older Norton builds) hooks into reparse operations and blocks them. Temporarily disable your real-time protection and retry. If it works, add an exception for your target folder.

Corrupted NTFS volume

If deleting the reparse point works temporarily but the error returns, the volume may have bad sectors or metadata corruption. Run:

chkdsk C: /f /r

Symlink on a network drive

Windows doesn't support symbolic links on SMB shares unless the server and client both enable it. If you're hitting this on a mapped drive, copy the files locally and create the link there.

Windows Sandbox or container environments

Inside Windows Sandbox or Docker containers running on Windows, reparse operations are restricted. You can't create symlinks outside the sandbox container. That's by design—use a different approach.

Prevention tips

• Check the target folder before linking. Run fsutil reparsepoint query on it. Clear any old reparse points first.
• Keep your antivirus updated. Outdated security software often causes these conflicts. Modern Defender rarely blocks reparse operations.
• Run regular chkdsk scans. I do mine monthly. Keeps NTFS metadata healthy.
• Use mklink with the right flags. /D for directory symlinks, /J for junctions. Mixing them up can trigger this error on existing junctions.

That's it. You should be back to linking in minutes. If you're still stuck, the issue might be deeper—like a corrupted registry or a failing drive. Pop the logs open (Event Viewer, System, look for Disk errors) and check your drive health with something like CrystalDiskInfo. But 9 times out of 10, the fsutil delete does the trick.