Unable to unmount "subst" drive

Question

So I have this G: drive which I'm 99% sure I "mounted" using subst to associate a folder with a drive letter. If I double click on it I see the contents of C:\User\Marcel\Google Drive.

Anyway, now I want to get rid of it but I haven't had any luck doing so. I've tried running subst G: /d in both a regular and elevated command prompt, as well as trying to associate a new folder over top of G: and both times I got Invalid parameter - G:. It's also still there after a reboot which is weird because subst isn't supposed to persist over reboots. I've also tried these things in Safe Mode and nothing is different.

I've checked what runs on startup using CCleaner and there's nothing related in there either.

Any ideas on how to resolve this? See screenshot below of the oddity.

Solution 1

If you just type SUBST by itself, no parameters, it will list all drive letters created by subst, e.g.

C:\>subst Z: C:\Windows
C:\>subst
 Z:\: => C:\Windows
C:\>subst z: /D
C:\>subst
 (blank)

map Z: to windows folder, show list of mappings, delete Z: mapping, show mappings again (none) So if you don't see it there, it wasn't created by subst.

Solution 2

May not be the problem the original user had, but it is one way I got into a tangle.

$ subst
I:\: => C:\Users\ME\Dropbox\Images

$ subst /D I:
Invalid parameter - D:/

$ subst I:\ /D
Invalid parameter - I: /D

$ subst I: /D
Path not found - D:/

Is the problem obvious yet? It's something simple:

$ which subst
/c/WINDOWS/system32/subst

Notice the path?! I was running subst in a Cygwin shell created by installing GitHub on Windows 10. The icons for the shells and the default colors are identical so I didn't notice - silly me. The "$" prompt should have been the clue (or the MINGW64 on the title bar).

subst is a Linux command by the way, completely different from Windows Subst.

Solution 3

You probably used subst from an elevated command prompt. When that is done calling subst from a normal command prompt doesn't return the mappings made in the elevated one.

Try calling subst in an elevated commant prompt (start -> cmd -> ctrl+shift+enter or right click and Run as administrator).

Solution 4

Try net use (as mousio suggests above). Today I had a similar problem with most drives taken by network connections and "net use * /d" was able to make the drive letters available.

D:\>net use
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
Disconnected K:        \\foo\scratch          Microsoft Windows Network
...
Disconnected Z:        \\foo\scratch          Microsoft Windows Network
The command completed successfully.

D:\>net use * /d

View more solutions

Comments

[Kevin Versfeld]

Just for giggles try a full power cycle reboot, it may/may not help.

[Marcel]

@mdpc I've had this problem for more than six months and have done about a dozen full power reboots since.

[mousio]

What does net use say (normal/elevated)?

[Marcel]

@mousio New connections will be remembered. There are no entries in the list. for both normal and elevated.

[mprill]

Can you check if the source of that letter is the registry key HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices?

[Marcel]

Nope, there's several from \DosDevices\B through to \DosDevices\V but no \DosDevices\G.

[bertieb]

Does this use the same process as the subst command the OP used?

[Jim Fell]

I was also having a problem unmounting a subst drive. It turns out that the reverse of what you suggest is true as well. I had mounted it in a non-elevated command prompt and was trying to remove it in an elevated command prompt. Switching to a command prompt with the same lower privilege level fixed the problem. Kudos!

[Scott - Слава Україні]

OK, this is an amusing scenario. It’s probably not what happened to the OP in this question, but, yeah, sure, somebody who finds this question through a search might be in this situation. And, yes, there is an obscure Unix / Linux command called subst (which is completely unrelated to the Windows command called subst). But so what? Clearly you were running the Windows version of subst — why wasn’t it working? (P.S. I mapped a drive using subst in Command Prompt, and then I was able to unmap it using subst g: /d from Cygwin with no problem.)