For the most part scp or rsync gets the job done for me, which is strange considering a real file system should be way more useful.
What are peoples use cases for sshfs and is there alternative workflows?
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.
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.
$ ssh -Nf -L2049:my-nas:2049 my-gw
$ sudo mount -t nfs -o vers=4 localhost:/mnt/somewhere/username /home
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 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...
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.
umount -l /stuck/directoryThe 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.
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.
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.
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.
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.
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.
1. Open the terminal and mount sshfs.
2. Open Dolphin and Ctrl+Click 10 files among tens.
3. Cut, paste locally.
4. Unmount sshfs.
Very different tools for very different use cases.
-o reconnect -o ServerAliveInterval=5
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
ServerAliveCountMax=5,ServerAliveInterval=2,ConnectTimeout=2
to avoid it hanging for too long if the network goes away, works like a charm.
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.
Nowadays I mainly use docker-machine (can't say I recommend it, but it does the job)
In the past, I also used it as an alternative to Samba or NFS.
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.