SSHFS remote directory mounting syntax

Question

A Windows-10 64-bit PC was outfitted with:

• winfsp-1.4.19049.msi
• sshfs-win-2.7.17334-x64.msi on Github: SSHFS-Win Github: =>

A remote linux directory (mydirectory) is to be mounted to S:. The syntax is documented here

"Baby steps" indicating preliminary success (non-Admin CLI):

net use S: \\sshfs\[e-mail]\..\..

however this does not mount mydirectory

Other user's attempts to mount target directory have failed. Attempt from the Admin command-line failed:

net use S: \\sshfs\[e-mail]\\mnt\MOUNTPOINT\mydirectory

System Error 67 has occured. The network name can not be found

Other failures:

net use S: \\sshfs\[e-mail]\mnt\MOUNTPOINT\mydirectory
net use S: \\sshfs\[e-mail]:\mnt\MOUNTPOINT\mydirectory

for some reason, the syntax is such that I am required to type the username and password despite inputting the username: user@hostname

• What is the correct syntax to mount mydirectory to the S: drive?
• What diagnostics can be performed to determine corrective action?

Answer 1

This command works for me in the non-admin powershell in Windows 10:

net use S: \\sshfs\[e-mail]\..\..\my_remote_directory

This did not work for me in cmd, but neither did the first baby step.

I originally found this question when trying to use map network drive in the GUI for a remote folder in windows 10. Your baby step lead me to something that worked. I was able to mount a remote directory with the below in the folder field.

\\sshfs\[e-mail]\..\..\my_remote_directory

Answer 2

I'll add some notes on this for future googlers.

The "net use" command did not work for me, admin or not, powershell or cmd.

Open Windows Explorer, find "this pc", right click on it, select "map network drive".

Enter "\sshfs\bigfred@172.25.10.10/../../etc/blabber/mouth" in Folder. Check "Connect using different credentials". Hit Enter.

Some notes:

Windows 10 seems to be funny about permissions and folders here.

If you map "\sshfs\bigfred@172.25.10.10/" you'll be stuck in your home folder and whatever sub folders it has. But you should be able to read and write.

If you map "\sshfs\bigfred@172.25.10.10/../.." You'll be at the root folder, but will be stuck with what ever permissions your user has for the root for all folders. If you don't have write access on the root folder, you won't have write access on anything below it because Windows.

If you map "\sshfs\bigfred@172.27.10.10/../../etc/blabber/mouth" You'll have whatever permissions your user has on folder 'mouth', but you'll be stuck in that folder, same as your home folder.

For newbs, adding "/../.." is the equivalent of going into your home folder and typing "cd ../.." Also the : is ignored/not needed in Windows mapping.

On linux I can mount the remote root folder and operate as if I'm local to the machine; I can navigate to any folder.

On windows there are quirks and restrictions you have to work around, so its better to mount the folder you need to work in. Inconvenient if you need access to multiple folders, but it works.

Answer 3

In my Windows 10 mounting home directory of remote ssh server worked in user's powershell using command

net use S: \\sshfs\user@host\.

Note single dot at the end! Without the dot it did not work. For mounting root folder, use

net use S: \\sshfs\user@host\..\..

The same works (but with different syntax) on Windows Explorer -> This PC -> Map network drive. In my system I had to enter the path with leading two backward slashes: for root

\\sshfs\user@host/../..

for home

\\sshfs\user@host/

Note forward slashes here! You may need to mark "Use different credentials" and enter username / password in several subsequent dialogue boxes.

Answer 4

If you're getting an access denied error then you probably have a permissions issue, not a syntax problem. Verify that your ssh user has permissions to ssh into the server and also that the user has permissions to access that specific directory. You also might want to try running the command from an administrative prompt in Windows to make sure that it's not a Windows permission issue with sshfs.