If you use SSHFS-Win + WinFsp to mount Linux directories as Windows drive letters, you may occasionally encounter a strange failure where a mapped drive suddenly becomes inaccessible.
For example, suppose P: is mapped to a remote Linux directory:
net use P: \\sshfs.r\user@server\data\storage
It may work normally for days or weeks, then suddenly Windows reports:
P:\ is not accessible.
Insufficient system resources exist to complete the requested service.
Trying to reconnect the drive may then fail with:
System error 85 has occurred.
The local device name is already in use.
The confusing part is that deleting the mapping can appear to succeed:
net use P: /delete /y
Windows reports:
P: was deleted successfully.
But immediately afterwards:
net use
still shows P:.
This is not always a normal Windows network-drive problem. In some cases, the underlying SSHFS/WinFsp filesystem process becomes stuck, leaving behind a mounted WinFsp volume even though the SSHFS launcher process is no longer healthy.
This article documents a practical way to diagnose and recover from this situation without rebooting Windows or disconnecting other working SSHFS mounts.
Example Environment
Assume the system has several SSHFS-Win mounts:
P: \\sshfs.r\user@server\data\storage
S: \\sshfs.r\user2@server\home\user2\workspace
X: \\sshfs.r\user@server\data\archive
There may also be unrelated SMB drives, for example:
Y: \\fileserver\shared
Running:
net use
might show:
Status Local Remote
-------------------------------------------------------------------------------
P: \\sshfs.r\user@server\data\storage
WinFsp.Np
S: \\sshfs.r\user2@server\home\user2\workspace
WinFsp.Np
X: \\sshfs.r\user@server\data\archive
WinFsp.Np
OK Y: \\fileserver\shared
Microsoft Windows Network
The important point is that P: still exists from the perspective of the WinFsp network provider.
Step 1: Check Whether Windows Still Sees the Drive
First, inspect current network mappings:
net use
Then check whether PowerShell sees the drive:
Get-PSDrive P -ErrorAction SilentlyContinue
If this returns nothing, check whether the drive letter was created using subst:
cmd /c "subst"
A suspicious situation looks like this:
net usestill listsP:Get-PSDrive Preturns nothingsubstshows noP:
This suggests the drive letter may still be held by SSHFS-Win/WinFsp rather than by a normal Windows mapping.
Step 2: Try the Normal Unmount First
Always try the standard method first:
net use P: /delete /y
Then check again:
net use
If P: disappears, simply reconnect it:
net use P: \\sshfs.r\user@server\data\storage
If this works, no further troubleshooting is needed.
However, sometimes Windows reports:
P: was deleted successfully.
while net use immediately shows P: again.
Trying to reconnect may still produce:
System error 85 has occurred.
The local device name is already in use.
At this point, repeatedly running net use /delete is unlikely to help because the underlying filesystem volume may still exist inside WinFsp.
Step 3: Inspect the Actual WinFsp Volumes
WinFsp includes a diagnostic utility called fsptool.
Run:
& "C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe" lsvol
You may see output similar to:
S: \Device\Volume{...}\sshfs.r\user2@server\home\user2\workspace
P: \Device\Volume{...}\sshfs.r\user@server\data\storage
X: \Device\Volume{...}\sshfs.r\user@server\data\archive
If P: still appears here, then the WinFsp volume itself is still mounted.
That explains why net use P: /delete appears to succeed while the drive letter continues to come back.
If fsptool-x64.exe is not in the expected location, search for it:
Get-ChildItem "C:\Program Files (x86)\WinFsp" -Recurse -Filter "fsptool*.exe" |
Select-Object FullName
Step 4: Inspect SSHFS Processes
Next, inspect all SSHFS-related processes and their parent-child relationships:
Get-CimInstance Win32_Process |
Where-Object {
$_.Name -match 'sshfs|winfsp'
} |
Select-Object ProcessId, ParentProcessId, Name, CommandLine |
Format-List
A typical result may look like:
ProcessId : 12000
ParentProcessId : 50000
Name : sshfs-win.exe
ProcessId : 22000
ParentProcessId : 12000
Name : sshfs.exe
ProcessId : 33000
ParentProcessId : 44000
Name : sshfs.exe
ProcessId : 55000
ParentProcessId : 50000
Name : sshfs-win.exe
ProcessId : 66000
ParentProcessId : 55000
Name : sshfs.exe
Here, two sshfs.exe processes have healthy parent sshfs-win.exe processes:
sshfs-win.exe
└── sshfs.exe
sshfs-win.exe
└── sshfs.exe
But another sshfs.exe may reference a parent process that no longer exists.
That is a strong indication that the process has become orphaned.
Step 5: Verify the Suspected Orphan
Before terminating anything, verify whether the parent process really exists:
Get-Process -Id <ParentPID> -ErrorAction SilentlyContinue
If this returns nothing, the parent process is gone.
You can also inspect SSHFS startup times:
Get-Process sshfs |
Select-Object Id, StartTime, Path |
Sort-Object StartTime |
Format-Table -Auto
Startup times can help correlate processes with mounts, but they should not be used as the sole basis for deciding which process to terminate.
The parent-child relationship is generally more useful.
Step 6: Kill Only the Broken SSHFS Process
This is the most important step.
Do not terminate every SSHFS process:
Stop-Process -Name sshfs -Force
Doing so may disconnect all working SSHFS mounts.
Instead, terminate only the process associated with the broken mount:
Stop-Process -Id <BrokenSSHFS_PID> -Force
The PID will be different every time, so always identify it first.
Step 7: Verify That the Stuck WinFsp Volume Is Gone
Run:
& "C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe" lsvol
Before terminating the broken process, you may have seen:
S: ...
P: ...
X: ...
Afterwards, the broken drive should disappear:
S: ...
X: ...
This confirms that WinFsp has released the filesystem volume.
Step 8: Remove Any Remaining Mapping
Check again:
net use
If P: still appears as a stale network entry, remove it:
net use P: /delete /y
At this point, the deletion should persist because the underlying WinFsp filesystem no longer exists.
You can optionally check whether Windows has a persistent network-drive registry entry:
reg query HKCU\Network\P
If such an entry exists and you are sure it belongs to the stale SSHFS mapping, remove it with:
reg delete HKCU\Network\P /f
If Windows reports that the registry key does not exist, no action is required.
Step 9: Remount the Drive
Reconnect the SSHFS drive normally:
net use P: \\sshfs.r\user@server\data\storage
Then verify it:
Test-Path P:\
Expected result:
True
You can also test directory access:
Get-ChildItem P:\ | Select-Object -First 5
Step 10: Verify That Other SSHFS Drives Still Work
Because only one SSHFS process was terminated, other mounts should remain available.
Check them:
Test-Path X:\
Test-Path S:\
Both should return:
True
Finally, inspect WinFsp again:
& "C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe" lsvol
After reconnecting the failed drive, all expected mounts should be visible again.
Why Can net use /delete Fail to Fully Remove the Drive?
An SSHFS-Win drive involves several layers:
Windows drive letter
↓
WinFsp Network Provider
↓
WinFsp filesystem volume
↓
sshfs.exe
↓
SSH connection
↓
Remote Linux filesystem
A failure can occur where the SSHFS wrapper exits or becomes detached while the underlying sshfs.exe process continues running.
Conceptually, the failure looks like this:
sshfs-win.exe disappears or becomes unhealthy
↓
sshfs.exe survives
↓
WinFsp volume remains mounted
↓
drive becomes inaccessible
↓
net use /delete removes only the visible mapping
↓
WinFsp exposes the volume again
↓
drive letter reappears
↓
remounting fails with System Error 85
Once the orphaned or broken sshfs.exe process is terminated, WinFsp can release the volume and the drive letter becomes available again.
Recommended Troubleshooting Flow
For future incidents, this is a practical sequence:
SSHFS drive stops working
↓
net use
↓
net use P: /delete /y
↓
net use again
↓
Did P: disappear?
↓
YES → remount it
NO
↓
fsptool-x64.exe lsvol
↓
Is P: still mounted in WinFsp?
↓
YES
↓
inspect sshfs.exe and sshfs-win.exe
↓
identify the broken or orphaned process
↓
Stop-Process -Id <PID> -Force
↓
fsptool lsvol
↓
confirm P: disappeared
↓
net use P: /delete /y
↓
remount P:
↓
Test-Path P:\
Quick Recovery Commands
For future reference, start with:
net use
net use P: /delete /y
net use
If P: comes back immediately:
& "C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe" lsvol
Inspect SSHFS processes:
Get-CimInstance Win32_Process |
Where-Object {$_.Name -match 'sshfs'} |
Select-Object ProcessId,ParentProcessId,Name
Optionally check startup times:
Get-Process sshfs |
Select-Object Id,StartTime |
Sort-Object StartTime
Verify a suspicious parent process:
Get-Process -Id <ParentPID> -ErrorAction SilentlyContinue
If the corresponding SSHFS process is clearly orphaned:
Stop-Process -Id <BrokenSSHFS_PID> -Force
Then:
& "C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe" lsvol
net use P: /delete /y
net use P: \\sshfs.r\user@server\data\storage
Test-Path P:\
What Not to Do First
If multiple SSHFS drives are mounted, avoid immediately restarting the entire WinFsp service:
Restart-Service WinFsp.Launcher -Force
Also avoid terminating all SSHFS processes:
Stop-Process -Name sshfs -Force
Either action can disconnect otherwise healthy SSHFS mounts.
That can be disruptive if applications, editors, scripts, or data-processing jobs are actively accessing those drives.
It is usually safer to identify and terminate only the broken SSHFS instance.
Final Takeaway
If an SSHFS-Win drive reports:
Insufficient system resources exist to complete the requested service.
followed by:
System error 85 has occurred.
The local device name is already in use.
and:
net use P: /delete /y
claims success while the drive immediately reappears, the problem may not be the Windows drive mapping itself.
Check the underlying WinFsp volumes:
fsptool-x64.exe lsvol
Then inspect the sshfs.exe processes and their parent processes.
If an orphaned or otherwise broken SSHFS process still owns the WinFsp volume, terminating only that process can release the stuck drive cleanly.
This approach can restore the mount without rebooting Windows and without disrupting other SSHFS drives that are still working.
Leave a Reply