sshfs-win
sshfs-win copied to clipboard
Folders symbolically linked not accessible
First of all thank you for this free application.
I have tried to access a folder that is symbolically linked on the SFTP sever (Ubuntu 18.04) but got this error:
\\sshfs\[email protected]\SHARED refers to a location that is unavailable. It could be on a hard drive on this computer, or on a network. Check to make sure that the disk is properly inserted, or that you are connected to the Internet or your network, and then try again. If it still cannot be located, the information might have been moved to a different location.
There is no problem with connecting. I can see the folders and files and access those that are not symbolic links. I only get that error when trying to access a symbolically linked folder. Is it possible to fix that somehow?
Symlinks work on SSHFS-Win but there are a couple of issues. What is the exact value of the symlink on the SSHFS server? Try running a command such as ls -l SHARED (where SHARED is the name of the link) and post the output.
What is the exact value of the symlink on the SSHFS server? Try running a command such as
ls -l SHARED(whereSHAREDis the name of the link) and post the output.
the output to ls -l SHARED command is:
lrwxrwxrwx 1 root root 20 Oct 6 18:11 SHARED -> /home/shared/SHARED
It works without any problem when using SFTP Net Drive or ExpanDrive.
SSHFS-Win does not support absolute symbolic links by default. This is because an absolute symbolic link can be used to point outside the mounted file system.
You can start sshfs.exe from the command line with the -o follow_symlinks option, in which case symlinks will be followed on the SSHFS server and they will not be presented to the Windows client.
https://linux.die.net/man/1/sshfs
Thank you.
When running the command below in Command Prompt:
sshfs -o follow_symlinks [email protected]:/
I get error:
connection reset by the peer
When I run this command:
sshfs -o password_stdin,follow_symlinks [email protected]:/
I don't get any error. The cursor keeps blinking and it seems that it tries to connect but nothing appears in Command Prompt or in Windows Explorer. What is wrong?
It is likely sshfs.exe cannot find your ssh.exe in the path. Run the commands:
>cd C:\Program Files\SSHFS-Win\bin
>PATH=C:\Program Files\SSHFS-Win\bin
>sshfs -o follow_symlinks ...
IT's even worse now. Cannot write anymore even in the home folder (not symbolically linked). It says I don"t have permission and does not allow me to modify the permissions in Windows
Are you also using the options -o uid=-1,gid=-1?
Off the top of my head this should look something like:
sshfs.exe -o uid=-1,gid=-1,follow_symlinks USER@SERVER:
There may be additional options that I forget. Additional useful options often are -o idmap=user and -o umask=000.
I don't get any error. The cursor keeps blinking and it seems that it tries to connect but nothing appears in
Because it's waiting for a password from console. Type this and press return.
connection reset by the peer
IMO this issue should be finally investigated — 2/3 of my systems get this weird error whereas mounting as network drive from This PC works ok.
Thank you for your help.
It works with -o uid=-1,gid=-1,follow_symlinks.
Why do the folders have a padlock on them, even though they are accessible (can read and write inside them)?
Perhaps this is the same issue I found related to affixing / during symbolic link creation, omitting it worked for me - see: https://github.com/billziss-gh/sshfs-win/issues/69
Hi, I'm having the same problem of symlinked absolute paths (which are indeed outside the local filesystem) not being navigable.
in /home/myuser on the host:
lrwxrwxrwx 1 myuser myuser 17 Jul 26 16:39 htmldocs -> /var/www/html/doc
I'm using SSHFS-Win on Windows 10 and mounting using the instructions found here. Since this is all being done using graphical shell extensions, I don't know how I would go about specifying the follow_symlinks option (or any other for that matter) to sshfs.exe.
When I double-click on the folder as shown in Windows Explorer, nothing happens.
Also having this issue just trying to make /var/www available to my users.
Even if the options to sshfs did work, that's totally unmanagable as I would have to tell every single user this and get them to run a command vs just using the 'mount drive' interface as currently.
To me making the shared webhost folder available is one of the very most basic tasks one could expect and while I understand your concern - allowing outside mounts is an issue that should be handled completely separately - entirely unrelated to whether or not this should or should not work.
I am also having this issue. I wasn't able to get it to work with -o uid=-1,gid=-1,follow_symlinks.
I was able to get symlinks to work with -o uid=-1,gid=-1,follow_symlinks,idmap=user,umask=000 following the suggestion from @billziss-gh