If you just want light-weight mirroring I recommend lsyncd. For example work if you want to work on code locally and have it mirrored on a remote host. It's more reliable because it just mirrors files rather than mounting file systems or block devices.

  Lsyncd uses a filesystem event interface (inotify or fsevents) to watch for changes to local files and directories. Lsyncd collates these events for several seconds and then spawns one or more processes to synchronize the changes to a remote filesystem. The default synchronization method is rsync. Thus, Lsyncd is a light-weight live mirror solution. Lsyncd is comparatively easy to install and does not require new filesystems or block devices. Lysncd does not hamper local filesystem performance.

https://lsyncd.github.io/lsyncd/

NFSv4 (not NFSv3 or earlier) is the most efficient network FS protocol (beats SMB in all my testing), but I frequently access work machines over VPN and can't use NFS because of many reasons in which case SSHFS is very convenient.

ADD: Some might not be aware that NFSv4 is a MAJOR change from the earlier versions and has many radical changes, including: time-expiring lease-based coherency, bundled requests (do much more in each NFSv4 network packet), locking built-in to the protocol. Don't don't base your assumptions of NFS on NFSv3.

Some on this thread suggests Syncthing, scp, rsync, etc, but this not really the same. When the file system is enormous and you need to commit your changes back - it would be impractical to sync everything (many TiB of data) and a pain to try to remember which things changed.

The situation on macOS has been a bit sad; Mac Homebrew refuse to install sshfs as Mac FUSE is not open source (because the author got fed up with commercial abuse of his work). I sympathize, but that still leaves me in limbo. Ideally, Apple should just include a FUSE like facility in macOS as it's so useful.

Oh wow, inspired by the stunnel above I just successfully used

    $ ssh -Nf -L2049:my-nas:2049 my-gw
    $ sudo mount -t nfs -o vers=4 localhost:/mnt/somewhere/username /home

to mount my home (5,000 miles from where I currently sit) over ssh (over zerotier) without needing SSHFS. I'm going to use this going forward.

Beware, you may need to do a significant amount of sysctl tuning/mount option tweaking to get fast NFS performance over high latency networks.

Thanks, got pointers?

It already works very well (seat-of-the-pants feels comparable to or better than my sshfs recollection); I managed to build Rust projects over it (with target on local FS).

Googling around suggest bumping the TCP transfer window but I don't see that as option in macOS's man mount_nfs, or any other useful option for that matter.

NFS is more flexible in dynamic mapping of new users; sshfs will take a mapfile at startup but it cannot be changed unless the service is restarted.

NFS is also more tolerant to breaking and resuming the TCP connection; this is fatal to sshfs.

Encrypting NFS is a bit of a Rube-Goldberg machine, which I covered here:

https://www.linuxjournal.com/content/encrypting-nfsv4-stunne...

> NFS is also more tolerant to breaking and resuming the TCP connection; this is fatal to sshfs.

Except when...

- The kernel driver crashes, resulting in unkillable processes and orphaned, mounted files that, if accessed, result in those very processes also being unresponsive and unkillable. The solution? Reboot your machine.

- There is packet loss on the network which can greatly compromise the stability of the NFS client. The solution? Don't have packet loss.

- The RPC daemon somehow goes out of lockstep with the kernel, causing hanging and crashes. The solution? Don't let the RPC daemon get out of lockstep --- somehow.

- You foolishly misconfigure the mount options, causing NFS to hang or time out if there's even a minor issue. Woe betide you if you muck up the timeout, retrans, etc. flags. The solution? Know the arcana and all your needs ahead of time, or be prepared for days of debugging.

NFS sure is convenient and useful, but it's also terrible and antiquated.

Yea, NFS processes can get into an uninterruptible and unkillable sleep state where then only way to clean up is to reboot.

Instead of rebooting, try a lazy unmount on Linux.

  umount -l /stuck/directory

You still get stuck processes on D state which can be locking other resources. Maybe the kernel could use an alternate kill api for this, as being able to kill a D state process normally is problematic in many apps and should never be possible 'accidentally'.

So glad/validated to see this thread. I always inevitably end up ranting about this when NFS comes up.

The frustrating thing is, a shocking number of people either don't realize it or simply can't.

I've lost weeks of my life to D-state. All TCP, all new protocol revisions. Datacenter wide deployment with redundant ports, paths, everything.

Soft mount no?

You might be correct about NFSv2. However, there was significant exchange between NFSv4 and SMB versions 2 and 3. Neither is perfect, but they have practical uses.

As far as packet loss is concerned, TCP is more robust, and is the default on Linux starting with NFSv3.

When using NFSv4, rpc.portmap is not necessary, so it cannot "go out of lockstep with the kernel" because it is not running.

As far as "foolish misconfiguration," solving a problem between the keyboard and the chair is not in the current features. Maybe the next release.

p.s. NFS over UDP can cause silent corruption over gigabit ethernet - see "man 5 nfs" for details (search for "Using NFS over UDP on high-speed links"). This is one reason why TCP is the default.

oof, the situation can be even rougher than that. At 9000 MTU on IPv4, you have a 'safe' NFS-over-UDP data rate of roughly 18 megabytes/second. Plenty of room at 1GbE, but not enough for 10GbE or greater. I suppose using krb5i/p mounts or some other integrity-providing GSSAPI/crypto implementation could help with this, but thats a different pile of worms. You would also get issues with not-strictly-necessary retransmits impacting your effective bandwidth.

Thankfully, IPV6 can help mitigate this problem by extending the fragment id length from 16 to 32 bits. This gets you up to roughly 1.18 trillion bytes of 'safe' NFS traffic/second. There's plenty of reasons why IPv6 adoption is still fragmentary, but if you're running a high throughput network, this is certainly a motivator to move at least part of it to IPv6.

> As far as packet loss is concerned, TCP is more robust

Somehow I always felt using UDP as a basis for a file access protocol had more potential. You shouldn't care about packets arriving in the correct order, only that the (likely, concurrent) read/write operations are completed. If I request a 1MB read, I don't need it to come in 1500b sequential chunks, I can wait for the read call to return me a full 1MB buffer.

It could also enable better throughput on high-latency (but otherwise speedy) links, like moving files between datacenters across the pond.

Sun RPC / XDR doesn't have consistency checking like that built in. So you definitely can't bolt this onto older NFS protocols, but they could have for NFS v4 (and didn't).

The use case for sshfs that you can quickly get access to all the files accessible to you in some machine without needing to be root either local or remotely.

I have had very stable networks for over 10 years in most of my work, so I don't think I haver ever suffered from hangups.

It does not fail gracefully when you read or write bigger files than your connection can decently handle. But I don't know which system would behave better under such conditions.

A (better?) alternative to sshfs is Syncthing, which works somewhat like a self-hosted Dropbox; it automatically synchronizes a subtree between computers. I've used it for years, with no problems at all. Maybe it won't handle concurrent edits to the same file well, but that's not something I do.

Meanwhile, the hung mount problem in sshfs can be more or less fixed by giving it the right mount options; perhaps something along the lines of https://github.com/Baughn/machine-config/blob/041e2151dffd8e... will be helpful. Unfortunately these aren't the default.

I use both, and while SyncThing is beautiful, it doesn't cover the use cases of sshfs, where you don't even need to install anything. I'm not going to install SyncThing on a server when I just want to patch a python file or copy some log archives.

Additionally, there's a wide semantic gap between "make the remote tree appear local" and "make a local copy of the entire remote tree".

Why wouldn’t you just.. scp?

I don't know. How faster can scp make this workflow?

1. Open the terminal and mount sshfs.

2. Open Dolphin and Ctrl+Click 10 files among tens.

3. Cut, paste locally.

4. Unmount sshfs.

SSHFS and Syncthing are so different from each other, almost the only thing they have in common is that they talk on a network.

Very different tools for very different use cases.

True. I was addressing both of the GP's use cases.

I had the same problem when I first started using sshfs. I found that adding the following to my sshfs invocation did the trick:

-o reconnect -o ServerAliveInterval=5

Can put those in the ssh user config file

I use it for browsing/copying/editing files on remote servers. Once you've got ssh passwordless authentication set up with the server, then it's easy to add in a systemd automount for it in your /etc/fstab. I like the authentication and encryption compared to NFS though it is slower, so more for accessing specific files.

Example /etc/fstab line:

root@remote:/ /mnt/sshfs/remote fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,reconnect,transform_symlinks,identityfile=/root/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=1000

I usually add sth. like

ServerAliveCountMax=5,ServerAliveInterval=2,ConnectTimeout=2

to avoid it hanging for too long if the network goes away, works like a charm.

You mount the remote file system as a volume and traverse it as part of the local file system. Super convenient for comparing contents of a local folder to a remote in the command line, using local tools on the remote FS, batch copying both ways, all that good stuff.

The hung file systems can be a buttpain, enough that I wrote a Bash script that calls `mount` to get the hung FS IDs and `umount` them with the results. After that easy peasy.

I used to use SSHFS to have access to remote files in the OS file browser. But I moved onto WebDAV (via lighttpd) because I like managing the auth outside of PAM and also OS file browsers (including Win/Mac) have good support for it

I wish sshfs worked for me and hope it gets attention for someone knowledgeable. The primary issue I had was when resuming my laptop is that it would freeze the system waiting to reconnect.

I use it for temporary connections for file management since a few years ago, and it always has been very stable. Never left it connected for more than 24 hours, though.

I have sshfs connections open for weeks at a time (except when network interrupts). Works awesome. Just remount and keeps going. I don't have open handles to files there for weeks, just mounts - then open file, edit, close and it again, 100s of times a day. I love sshfs.

I used it a lot when I was running a Linux desktop and deploying random things on vps.

Nowadays I mainly use docker-machine (can't say I recommend it, but it does the job)

We used it for PyCharm to overcome its limitation with remote editing support.

In the past, I also used it as an alternative to Samba or NFS.

I use winfsp/sshfs-win to remotely access my Haiku system, which works extremely well.

SSHFS is used by KDE Connect to see files on the other device

I don't think that's true.

On my GNOME system GSConnect uses GIO. I don't have a KDE system to look at right now but I would eat my hat if they're using SSHFS instead of KIO.

I use it with my NAS.

satisifed user of rclone here