[meditate]

There is currently no kernel interface that I know of to do that, and I don't think it would be too hard to hook into an open() on an invalid path and try to do something (mount a network fs, call out to GVfs or KIO, etc), but I can tell you you will meet resistance if you try to because things like "//stuff" and "smb://stuff" are already valid local file paths in Linux. So I leave it up to you to figure out how to do this without breaking things.

[Mister_Snuggles]

Yeah, this is definitely not an easy problem to solve given the design of Linux.

I don't know why I didn't remember this earlier, but I actually explored this a number of years ago and came up with two things that are close, but not quite there:

First was to use a systemd automount unit[0], but I didn't really get anywhere with it. From the looks of it you have to know all the possible things you could want to automount, it can't do wildcards. Being able to do some kind of pattern matching on the requested path and translate that into a mount command would go a long way to making this work.

I also explored the good old automounter[1][2], but it has a lot of the limitations that systemd's does. It does have the advantage of supporting host maps, which gets me a bit closer to what I'm looking for. The unfortunate thing that remains is that this is NFS instead of a modern protocol. If this were somehow backended on sshfs, I suspect it would be quite useful. Of course, sshfs is missing the concept of shares but that's not a showstopper by any means. Authentication becomes a problem since the automounter probably can't ask the user for a password, and may not even know which user is requesting the mount.

I have no idea how well either will work in practice. Modern Linux on the desktop is a very different environment than the one the automounter and NFS were built for. The systemd automounter looks like it serves a very specific purpose and can't currently do what I want.

Maybe all we really need is a modernized automounter and/or some extra features in systemd's automounter. These could lead to to "vi /net/server/share/file.txt" working as expected which, quite honestly, is basically the same as what I suggested earlier.

[0] https://www.freedesktop.org/software/systemd/man/systemd.aut...

[1] https://linux.die.net/man/8/automount

[2] https://linux.die.net/man/5/auto.master

[ti_ranger]

> I also explored the good old automounter[1][2], but it has a lot of the limitations that systemd's does. It does have the advantage of supporting host maps, which gets me a bit closer to what I'm looking for. The unfortunate thing that remains is that this is NFS instead of a modern protocol.

What limitations affect you?

(At home, I have linux running on an HP MicroServer as my NAS, it exports filessytems via NFS. Other machines run autofs with the hosts map, so for example my wife's desktop - and mine for that matter - auto-mounts NFS shares on-demand and she can open any file directly in any application by accessing /net/$hostname/$path).

NFSv4 is pretty modern ...

I believe this should also work for CIFS, if the server-side supports unix extensions (to do user mapping on a single connection), but I haven't had time to try it in the past day in my limited time at home.

> Authentication becomes a problem since the automounter probably can't ask the user for a password, and may not even know which user is requesting the mount.

If you have Kerberos setup, NFSv4 does the right thing ...

If you don't have Kerberos setup, then you're probably ok with just normal NFS user mapping.

[Mister_Snuggles]

Interesting, I'll have to give automount another look.

The last time I tried it was years ago, so I can't remember what limitations I found. If I get a chance to do this in the near future I'll report back.