Network shares: still talking about them in 2026

By now, many of you have probably seen Linus Tech Tips’ “Linux is Easy, right?” video?

The TL;DW version is that yes, things are mostly pretty easy, and the tasks they’re having trouble are becoming become less and less common over time… but pain points remain for the “prosumer/technology enthusiast” crowd: folks who are moderately to very technical, but aren’t software developers.

KDE comes out pretty well, with one exception: network shares.

Network shares.

Yes, network shares.

Still. In 2026!

What the heck is going on here? How is this not a solved problem? Let’s talk about it today.

How it works in KDE’s software

When you access a network share from Dolphin’s built-in network share browser, it doesn’t get mounted as a local path somewhere; Dolphin is connecting to the share using its own communication protocol: smb://, nfs://, or similar.

This is fine for KDE apps; they can use those communication protocols to access files when you double-click them on network shares you’ve accessed using Dolphin.

Everything works.

When you double-click a file on a network share and it opens in a non-KDE app, at that point something called kio-fuse (that we did a ton of work to build a few years ago) secretly creates a FUSE mount of the share in the background, and passes the app a local path to the file on the secret FUSE mount.

This way, the non-KDE app opens the file from a local path as it expects, and everything still works.

No it doesn’t, you liar!

You caught me! Everything works if you open the file from Dolphin… but what if you need to access a file on the share from the “open” dialog in an app, or save a file to the share using the “save” dialog in an app?

Well, then things get more complicated.

If it’s a KDE app, the standard KDE open/save dialog knows how to access the network share so you can open or save new files there. If you’ve created a bookmark for the share in your Places panel (which is our documented recommendation in KDE Linux), it’s already right there; simply click on it to connect to the share, and navigate to the desired file or location. Easy peasy, everything works.

Sounds great! So where’s the complication? Let’s move on.

If it’s a non-KDE app that uses the KDE open/save dialog, it’s the same deal: access the share from the dialog, everything works. Example apps are VLC and LibreOffice (when run with the Qt backend). Still no complication…

If it’s a non-KDE app that uses the portal-based open/save dialog, then everything is lovely here too. The app asks the XDG Desktop Portal for an open/save dialog; the portal offers up the KDE dialog; everything works. In this respect, Flatpak has been encouraging adoption of the portal-based open/save dialogs, which produces a really nice experience: KDE users get a KDE open/save dialog in almost every Flatpak app — something we’ve all wanted for years!

But now we come to the problem:

If it’s a non-KDE app that uses its own non-KDE open/save dialog… then everything becomes terrible. Its dialog will not see any bookmarks you’ve added to the KDE dialog, and will expect you to have the share mounted locally somewhere. Even if kio-fuse created a mount, the non-KDE dialog doesn’t show it nicely in its sidebar! You have to know the secret location of the mount (/run/user/1000/kio-fuse-[something]) and use the dialog to navigate there manually.

If these apps are packaged traditionally, that’s bad enough. If they’re Flatpaks, it’s worse: they have to be packaged with a hole in the security sandbox that allows them to access the kio-fuse mount, or else you can’t access it even if you know it exists and navigate there manually. Most do this for the location where GNOME’s own system mounts shares… but not for the location where kio-fuse mounts them — nor the location of any shares you’ve manually mounted, for that matter.

In addition, the GTK open/save dialog’s built-in network browsing feature is broken unless the app’s Flatpak packaging pokes another sandbox hole for network access — many don’t! And custom dialogs may not even have this feature at all.

What a mess. Unfortunately, as of June 2026 (if you’re reading this later, please verify), apps in this unfortunate situation include some important ones like Blender, GIMP, LibreOffice (from Flathub or with the GTK backend), OnlyOffice, Inkscape, Audacity, DaVinci Resolve, and Gedit.

So, that’s bad.

If it’s a command-line tool or daemon, then everything is terrible in the same way. All previous use cases involved GUI tools accessing or mounting the network share; until and unless that happens, there’s nothing for CLI tools to see. It’s as if the share doesn’t exist. Something would need to mount the share at login. That something usually ends up being driven by changes to /etc/fstab that a random internet tutorial walked you through.

Why not just mount stuff the old-fashioned way using /etc/fstab?

Well, there are a few problems with this — the first one being that /etc/fstab is root-owned, so using it to mount a network share requires administrator privileges. That’s not gonna fly on multi-user or administrated systems.

You could work around this by using a GUI tool that can modify that file using Polkit, and then ship a Polkit rule to auto-allow this app’s requests to modify the file — even for non-admin users.

If it’s a password-protected share, you’ll also have to store the credentials in plaintext somewhere; there’s no provision for storing them in an encrypted password storage system.

This makes a mockery of security, but even if that’s acceptable, it turns out there isn’t just one way to mount a network share using /etc/fstab, but rather about twelve thousand ways. Every online tutorial gives you a slightly different set of steps, and if you don’t do it just right, you’ll end up with a mount that isn’t writable, or delays the boot process if it’s not accessible at that time, or causes apps to hang and freeze if it becomes inaccessible later, or other non-obvious problems that can be really “fun” to troubleshoot.

It’s not impossible to do this properly, but you have to know what you’re doing. So you really want this file to only be touched by a person or organization that qualifies, and to not make changes to it that you don’t fully understand.

How can we fix this?

All is not lost. Happily, KDE just received an investment of over €1.2 million from the Sovereign Tech Fund, and it includes funding for improvements to KDE’s network share handling!

Time for full disclosure: KDE e.V. is contracting with my company Techpaladin Software to run this part of the project. Network shares represent a significant paper cut, and I’m really excited to be a part of the process to finally get this topic sorted.

I’m not micromanaging the project; frankly, I don’t have the time, even if I wanted to! So my involvement so far has mostly been to put smart people in charge, gather them together into a (virtual) room where they can be productive, and make sure they’re adequately funded! Which is what I’ve done, and and I have every confidence in the team.

Here are some of the ideas under discussion:

1. Have Dolphin and open/save dialogs automatically create temporary bookmarks for recently-accessed network shares, maybe in the “Recent” section.
   This would eliminate the step of manually bookmarking transiently-accessed shares.
2. Have Dolphin and the open/save dialogs create a FUSE mount for each share they access immediately after accessing it, rather than the first time a file from the share is accessed in a non-KDE app.
   This would solve the problem for CLI tools — provided the share is manually accessed at least once beforehand.
3. Either expose the FUSE-mounted share at a location on the system that lets the legacy GTK open/save dialog see it by default, or submit patches to GTK to let the GTK open/save dialog to see kio-fuse-created network share mounts at their current location.
   This would extend that fix to non-Flatpak apps using the legacy GTK dialog.
4. If the user manually bookmarks a network share, have kio-fuse automatically create a mount for it on login, similar to “mapping a drive letter” on Windows.
   This would remove the caveat “…provided the share is manually accessed at least once beforehand.”
5. Submit patches for apps on Flathub that still use this legacy dialog that let them see the location where kio-fuse mounts network shares.
   This would extend the above fixes to these apps’ Flathub packages.
6. Submit patches to port remaining apps to use the portal-based open/save dialog.
   This would reduce the number of GUI apps that need the above fixes in the first place.
7. Standardize the location and mount arguments for these FUSE mounts so you never end up with GNOME and KDE apps FUSE-mounting the same share to different locations. That’s just ridiculous!
   I’m not sure how politically possible this is, but it would be nice to reduce duplication.
8. Look into using systemd mount units as the underlying implementation if systemd is available, and use the current kio-fuse implementation as a fallback only on systems without systemd.
   This would let us use an already standardized system and the more performant kernel drivers for remote filesystems. And it might be more feasible than #7.

Lots of ideas. Preliminary work has already started, and I expect it to be an ongoing area of focus in the coming months.

So hopefully soon this topic will finally be in the rear-view mirror. I think it’s clear that KDE is not yet 100% there on network shares, and we can do better. And we will!