Network shares: still talking about them in 2026
17 points by FedericoSchonborn
17 points by FedericoSchonborn
I must be missing something.
Why are the two options:
Why isn't "just mount the share as a real path once" considered here?
Why isn't "just mount the share as a real path once" considered here?
Just a guess, but maybe they want to mount without acquiring root/cap_sys_mount. NFS/SMB can be mounted on other operating systems like MacOS without requiring admin permissions but not on Linux, afaik.
FUSE gets around this because fusermount3 is suid root. Editing /etc/fstab gets around this by requiring root permissions to edit the file the first time you connect to the share, but never again.
With KIO, you can e.g. browse random guy's WebDAV server, download some of his files or even upload him something. And everything from your favorite file browser without any setup - just enter the URL (or maybe the password, if required).
On the other hand, for permanent NFS or WebDAV connections, I will prefer static configuration and classic mount (either in kernel or in FUSE).
My point was: why go to the bother of making these super specific fuse mounts per-file to open a file. If someone clicks a link or icon, or enters a URL that results in a network share, why not just mount the share "normally" (i.e. via mount or FUSE) and then just open the mounted path.
I don't mean why doesn't the user do that. I mean why doesn't the file browser - which is currently doing all this per-file FUSE magic bullshit - do that FOR the user transparently.
They don't make the fuse mounts per file. They do it per share, but only after you've opened at least one file through the file manager. Gnome makes the fuse mount a little earlier (when you browse the share), and in a different location, but basically the same. They both also have their own fuse filesystems with their own backends for different protocols, partly because gvfs and kio predate fuse, partly because there's no canonical fuse filesystem for all of these. There are also good reasons you don't want to use the in-kernel CIFS (SMB) filesystem on Linux.
still talking about them
I must not have given network shares a thought in five years or more.
They're still a fairly regular pain point for me. My spouse and I regularly need to share files and we have a little NAS unit for this. I'm on Linux and my spouse is on Mac and it's been a fairly major pain getting a system where we can access the same data.
The solution I wound up on was that my partner connects on Mac via Samba while I use sshfs to mount the NAS filesystem. I'm not exactly happy about this setup. My ssh key has a password and that kills most attempts to get systemd to automount the NAS.
Things I've tried and failed:
I run Samba and NFS. Linux to Linux NFS has worked well for me.
I'd been curious about NFS, but half the discussions of it that I've found have been 90's sysadmins saying to never, ever use NFS under any circumstances, so I've been a bit scared to try it out.
I mean, my perception is that it's not trivial to make it really safe, so if you want to share files in an organization, and you need decent access control... I'd look at something else first. (And really, on those scenarios, you'd better look at sync services like Google Drive or Nextcloud.)
On a trusted network with trusted users... it's not so bad; as you have noticed, it's not so much a question of how good/bad NFS is, but rather what better options there are. For media files on a LAN, NFS has worked well for me.
Yes! As well as Linux works for a lot of things, this is something that always tripped up my boss at $DAYJOB! I would love for this be conquered, even if I don't use network shares at home.