[Support] mount Mosh (File System)

[ghost]

Hi,

Please Add support mount moshfs

[kmcallister]

This would happen after #41, #120, #261, etc. All four will most likely involve a feature for tunneling reliable octet streams over Mosh, which is something it doesn't do at present.

[eminence]

I would propose that this feature would never be appropriate for the mosh project. Mosh is a MObile SHell, and shells have no business implementing filesystems (or doing X11/port forwarding either).

Consider that ssh really isn't just a shell, even though remote shell access is what one usually uses ssh for. It's an encrypted transport layer (it can be a VPN, a Proxy, a network pipe).

Presumably, one would want a "Mosh Filesystem" to use the excellent latency/packet loss/roaming features of mosh. Wouldn't it be better to find another project to host this feature? Or maybe use something else like openVPN in UDP mode? (I"m not sure how well openVPN roams)

[onny]

+1
Considering that my whole OS freezes if sshfs lost the connection :(

[ghost]

@eminence, Please show alternative long-distance connections (anti timeout EDGE/GPRS)

[Freso]

@eminence And SSH is short for Secure SHell. Being able to use something similar to sshfs, but using mosh instead of ssh, would be great.

[albertz]

That cannot be that hard, can it? There are many available implementations for reliable streams. So, just nobody had time to do this, or are there more non-trivial problems which I'm not seeing right now?

[rnewton]

+1

Though perhaps this would work best as a related project. sshfs isn't a part of ssh, it just uses it.

[tiye]

Anyone knows how is this project now? https://github.com/leonidg/moshfs

[tlhonmey]

It occurs to me that a reliable byte stream is not necessary for transferring files or filesystem metadata, only reliable byte transfer. Neither end has to care what order the bytes are received in, only that they make it.

File transfer client to server is easy since Mosh makes sure all bytes are transmitted in that direction. All it needs is an escape sequence and/or (preferably and) initialization mode to tell the client and server programs to save a data stream instead of running it through the shell.

Mosh already has reliable transfer of the final state of its buffer, it just might skip some of the intermediate states. Mosh already has the ability to resize its buffer when the terminal is resized. For file transfer server to client, encode the file in a way that will not be mangled (Base64 should be perfectly safe worst-case) and then resize the client-side buffer sufficiently large to hold the encoded file. Client then talks to server in the usual way until it is certain that its buffer is in-sync, at which point it decodes the file data and saves it and then resizes the buffer back to the necessary dimensions. For large files optionally split them into chunks to avoid exhausting client-side memory.

Once bare file transfer capability is completed, layering a "moshfs" overtop of it should be relatively simple.

[cgull]

I want to point out that NFS over UDP with hard mounts is conceptually somewhat like Mosh's functionality with terminals, and it's already available in most OSes other than Windows.

For the record, Mosh is unlikely to add direct/native support for filesystems; it is after all primarily a virtual terminal. If it ever does become able to do filesystems, it'll be by tunneling reliable byte streams, as discussed in issues #41, #120, #261.

[dm17]

SSHFS still the best way to mount filesystem over the network (securely)? Any news on using mosh for this to keep it alive? If not, then what's the best way you've found to do this?
Thanks!

[ralyodio]

I'm also wanting to use mosh to mount a filesystem remote (linux)

[achernya]

It sounds like folks here really want "sshfs, but using QUIC". While we're excited about this idea, it's unclear that it belongs in mosh. There's nothing about the mosh protocol that makes it particularly well-suited for large file transfers, and QUIC has many of the same roaming capabilities mosh does.

[dm17]

Perhaps some filesystem mount over tailscale or wireguard is more ideal?

[j4hangir]

The rationale behind this request was the simplicity and ubiquity of MOSH, I have terminal open all the time on different devices and never need to worry about a closed connection, hence the idea to keep a simple folder or whatever mounted as well.

I don't understand why it got closed. This could've been maybe not the most efficient, but definitely a simple elegant solution.

[eminence]

but definitely a simple elegant solution.

I believe you are drastically underestimating the work involved here, if you think that this is a simple thing to develop :)

[j4hangir]

but definitely a simple elegant solution.

I believe you are drastically underestimating the work involved here, if you think that this is a simple thing to develop :)

Definitely not simple in implementation but simple in being a straightforward solution :) Something like this:

mosh -mount user@host:/home/user/data /Volumes/

For the implementation, from what I gather it's also not gotta be too complicated given that there should be applications out there that perform sync-over-ssh (rsync, etc.), if one could replace the SSH part with that of MOSH, then theoretically everything should work out of the box. This apparently brings us back to the #41(X11-Forwarding) issue.

Either way, these are just still ideas, overall it could've been a great addition to MOSH.

[tlhonmey]

The problem is that things like filesystem mounts and X11 Forwarding require sending every bit of a stream, while MOSH is specifically designed to discard all but the most recent data in the interest of getting the latest screen state there as fast as possible.

You could do some of it by using the screen buffer as your metaphor instead of a stream of data. Equivalent to transferring a file by breaking it into one-screen-sized chunks of encoded data and only asking for the next one once you've copied down the first one. But, at the moment, MOSH only supports one buffer at a time so that would need to be addressed first. It's quite a bit of work and not really the main point of using something like MOSH since things like a filesystem mount will hang big sections of your system waiting on latency whether you're using MOSH or just sshfs.

Automated single-file transfer could be handy though, even if it has to use the main buffer to do it.

[albertz]

I think the only real feature people want here is that it seamlessly works when the user switches networks or when the connection is bad or so. This is for many people one of the killer feature of Mosh. Sshfs with reconnect is not really so seamless.

[j4hangir]

I think the only real feature people want here is that it seamlessly works when the user switches networks or when the connection is bad or so. This is for many people one of the killer feature of Mosh. Sshfs with reconnect is not really so seamless.

That really sums it up, I personally wouldn't care about real-time performance or even resource hogging as much, as long as it could seamlessly sync a remote endpoint on my rig. May be MOSH isn't the best foundation, but I believe that really is the spirit behind the feature request.

[achernya]

The mosh issue tracker is intended to be representative of feature requests or bugs in mosh. We'd rather not lead the community on by leaving this open and give the impression that the mosh contributors are going to work towards this.

As I said earlier, the idea is exciting. But we don't feel mosh is the appropriate place for it.