Fix ERROR_IS_JOINED (0X00000086) – Drive Already Joined

This error pops up when you try to SUBST or JOIN a drive letter that's already mapped via SUBST or JOIN. The fix is to remove the existing mapping first.

You're staring at ERROR_IS_JOINED (0X00000086) after running SUBST X: C:\SomeFolder or JOIN X: C:\SomeFolder. This happens when drive X: is already mapped—either by a previous SUBST command, a JOIN, or a network drive that's stuck. I see this most often when someone runs a script that tries to create the same virtual drive twice, or when a persistent SUBST from a login script conflicts with a manual command.

Root Cause

The underlying issue is simple: Windows can't map the same drive letter to two different paths. SUBST and JOIN both create a virtual drive that points to a folder path. If you try to create a mapping for X: when X: is already pointing to something, you get 0X00000086. The OS doesn't differentiate between a SUBST mapping and a JOIN mapping—once the letter's taken, it's taken.

How to Fix It

Step 1 – See What's Currently Mapped

Open Command Prompt as administrator and run:

subst

This lists all active SUBST mappings. You'll see something like X:\: => C:\SomeFolder. If it's a JOIN mapping, you'll see nothing here—JOIN uses a different table. To check for JOIN mappings, run:

mountvol

Scroll through. Any line with \??\Volume and a drive letter in brackets is a mount point. That includes JOINs.

Step 2 – Remove the Existing Mapping

If it's a SUBST mapping, remove it:

subst X: /d

Replace X: with your actual drive letter. The /d flag deletes the mapping. If you get "The parameter is incorrect," the letter isn't mapped via SUBST—skip to the JOIN fix below.

If it's a JOIN mapping, remove it with:

join X: /d

Same syntax. /d deletes. If JOIN isn't recognized (it's not in all Windows versions), use:

mountvol X: /d

Step 3 – Retry Your Original Command

Now run your SUBST or JOIN command again. It should work without the error. For example:

subst X: C:\Projects\Data

Still Failing After That?

Three things to check:

Persistent mappings from login scripts or Group Policy. If you're in a domain, a startup script or logon script might be recreating the SUBST every time you log in. Check gpedit.msc under User Configuration > Windows Settings > Scripts. Or look in your startup folder (shell:startup). Disable the script.
Network drives using the same letter. Run net use to list them. If you see your letter there, remove it with net use X: /delete.
A registry entry that recreates the mapping on boot. Check HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices. If your drive letter appears, delete the value. This is rare but happens with some older software.

One last trick: reboot. If a mapping was left from a crashed process, a restart clears it. That's saved me more times than I'd like to admit.