sshfs-win
sshfs-win copied to clipboard
winfsp
Symlinks do not work
I think this is simply a case of -o follow_symlinks not being provided as an argument to sshfs. Would it be sane to pass this by default within the net use handler?
I guess a bigger question would be how to actually pass extra arguments to sshfs via net use.
Can you please give me an example of a symlink that does not work? Can you show me what it looks like on the SSH server side (I am particularly interested if it is an absolute or relative symlink).
I am fairly certain that symlinks do work on SSHFS-Win. However there are caveats.
-
It does not support absolute symlinks cleanly.
-
You cannot create symlinks unless you are Administrator on Windows.
I guess a bigger question would be how to actually pass extra arguments to sshfs via net use.
I do not think sshfs-win.c supports passing extra arguments to the underlying sshfs.exe as it is currently. Patches welcome though :)
Ah, looks like they are absolute symlinks, which is likely the problem.
Patches welcome though :)
My question was more "can you think of a sane way to pass arguments", not "how can I do this in the current release".
I guess an external config file could work
My question was more "can you think of a sane way to pass arguments", not "how can I do this in the current release". Cramming yet more things into the URL doesn't sound too sensible.
I was thinking that it might be worthwhile to modify sshfs-win.c to accept extra arguments that it passes to sshfs.exe. Then one could change the registry entry at this location to pass those extra arguments:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs
Not idea having it under HKEY_LOCAL_MACHINE - ideally, it would be configurable on at least a per-user basis, if not a per-connection one
@billziss-gh Thank you very much for sshfs-win and winfsp.
I'm running into symlink issues too (the filesystems I mount have lots of them) so any quick solution (no matter how hacky) would be greatly appreciated while a more finessed solution is worked out and implemented when time allows.
Thanks again
@samej71 sorry for the very late response. I have just returned from vacation and my responses should be more timely.
What is the exact problem you are experiencing? If it is like the OP's problem, you could recompile sshfs-win.c with the -o follow_symlinks option baked in.
@billziss-gh no worries at all. Life happens! :) I currently don't have a working compiler ecosystem and I download/installed/was using the (at the time) latest binary.
When I try to open a symlink that is a folder, I get an "Open Folder"-titled alert with the message "\sshfs\me@place\symlinkname is unavailable. If the location is on this PC, make sure the device of drive is connected or the disc is inserted, and then try again. If the location is on a network, make sure you're connected to the network or Internet, and then try again. If the location still can't be found, it might have been moved or deleted." Obviously, "me", "place", and "symlinkname" are not literal and show the real user, server, and symlink name that I am trying to access.
This only happens when I try to access folders that are symlinks. I have not tried to access symlinked files yet.
I just downloaded and reinstalled both winfsp and sshfs in case the binaries were updated since the last time I tried but I'm getting the same results.
@billziss-gh would you be willing to put an experimental build somewhere and I'll download and try it out?
Would it be possible to set up a build guide for this? I've never set up a cygwin build environment before, and I have the same issue as samej71.
In order to build SSHFS-Win you will need:
- A Cygwin build environment (including gcc, autoconf, etc)
- The packages required by SSHFS. The
fusepackage is satisfied by installing WinFsp and the contained "FUSE for Cygwin". Theglibandgthreadpackages are satisfied by the Cygwinglibpackage, installable via Cygwin setup. - You will also need Wix to build the SSHFS-Win installer.
- To build SSHFS-Win simply:
$ cd sshfs-win $ make
I've just attempted to use the latest build of WinFsp with symlinks. I had success with relative links that stayed within my home directory, but no success with leaving the home directory (../../../opt/www/share/) or by specifying an absolute path (/opt/www/share/). This folder is owned by the same user as the user accessing it.
Make sure that your symlinks do not have any trailing slashes (i.e. point to /foo and not /foo/). There is a long-standing bug about this, that I will have fixed in WinFsp 2018.2 (i.e. cannot make the cut for the upcoming WinFsp 2018.1).
Hi. I tried your software and I love it for its simplicity. However, I am too having trouble with symlinks. In my case, they point to another hard drive, but I get an error saying that the location is not available. From what I read, I suppose it will be fixed sometime in the future, right?
Unfortunately it is not possible to have symlinks that point to an alternative drive using SSHFS-Win. This is because of a conflict of how symlinks work on POSIX/FUSE vs Windows.
You can only have symlinks that point within the same file system. If sshfs is started with -o rellinks then absolute symlinks will be allowed but will be assumed to point within the same file system and converted to relative ones.
But does the server actually knows that it is a different file system? From a linux perspective, a different partition is just a folder. e.g. pointing to /media/usb1 from /home/username
@wonx the problem is really on Windows.
Windows needs to understand a symlink for many reasons (e.g. when you open a file via a symlink) and it does not understand the POSIX format. So the POSIX format (single root file system) must be translated to the Windows format (with multiple roots on drives) and there lies the problem.
When the symlink is relative it is easy to translate to the Windows format. But when the symlink is absolute it is impossible for the Windows implementation to know what the symlink points to, because there is no single file system root as mentioned. For this reason, absolute symlinks are allowed only when -o rellinks is set, because then absolute symlinks are treated as relative to the mounted file system root (not the overall root).
Any chance we could get the external configuration? even a registry key would suffice, just so I can have -o follow_symlinks
I believe the problem is that the sshfs arguments are hardcoded in sshfs-win.c and to enable symlinks one has to modify and rebuild it. As not everyone has development environment ready, it would be much easier to use some runtime switch or configuration to control this functionality.
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
i just used mount --bind on the linux side rather than bother with symlinks.
Installation package with (-o follow_symlinks): .build/x64/dist/sshfs-win-3.5.20195-x64.msi
I just made aware of sshfs-win -- COOL! Should help many of our datalad users who "mount" remote datalad datasets to their beloved windows boxes. But apparently git-annex'ed files symlinks aren't resolved and thus - fiasco. I would love to see this issue to be finally addressed. I wish I knew how to program on Windows (again, since did last time 22 years ago)
I use this at command prompt cmd.exe:
installation_path\sshfs-win.exe svc \sshfs\remote_user@remote_host\root_path drive_letter sshfs_options
"C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" svc \sshfs\remote_user@remote_host\\ Z: -o -follow_symlinks
then I insert ssh_password then press enter.
I open Z: drive and i see root filesystem and all symlinks works (relative and absolute symlink).
This works with or without option -o -follow_symlinks (i think) because mounting root / filesystem.
this works too:
"C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" svc \sshfs\remote_user@remote_host\\ Z:
In Windows Registry, go to:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs\CommandLine
Change it to: svc %1 %2 %U -o follow_symlinks
