Network shares: still talking about them in 2026 – Adventures in Linux and KDE

Skip to content

Nate

Planning, Usability & Productivity

June 22, 2026

7 Minutes

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.

A bookmarked network share for my living room HTPC. Accessible in the same way from Dolphin and KDE open/save dialogs. Works great!

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...