Bug 505234

Thanks for sharing this design proposal for Dolphin. There are definitely a pain points regarding access to Samba shares, and them not appearing as a local folder. I've personally been frustrated by this. One use case for me is with music players accessing a music share on a home NAS. Certainly this is not the only use case, just one example.

With that said, I'm going to change the summary of this request, and provide a little perspective. I think the goal, as I understand it, is worthy. The suggested implementation details may not be the best way to achieve it. There are existing design choices and constraints that may not be immediately obvious. I'll forward this to the Dolphin developers to consider.

One serious limitation is that Dolphin, and indeed the system, can hang when a mount in /etc/fstab becomes unavailable. For instance see bug 423187 and bug 423187. Mounts in /etc/fstab that aren't available at boot time cause issues as well.

As a note, the ability to store credentials for a remote share already exists. For instance, I've saved credentials for a couple of samba shares in KWallet (at the auto prompt when I first accessed them).

Finally, I'd like to ask you for more detail about one thing. Can you expand on what you mean by "mount shares permanently"?. What exactly would that allow a user to do that is not possible with the current functionality of Dolphin? I don't mean "create an fstab / systemd entry", I'm asking what that enables for the user? The better we understand the desired behavior, the better we can address this. Thanks.

1. GTK apps are ubiquitous – they need real filesystem paths
GTK-based apps (Firefox, Thunderbird, LibreOffice, etc.) use the GTK file chooser, which does not reliably support KIO/GVFS network shares. Users often encounter missing drives or errors. A share mounted via /etc/fstab appears as a genuine filesystem path and works flawlessly in all apps
lincplustech.com
.

2. Safe and boot-friendly with nofail, noauto, and automount
Concerns about /etc/fstab hanging at boot are valid – but systemd options like nofail, _netdev, noauto, and x-systemd.automount resolve this effectively:

    nofail: prevents boot delays or stops if the share is missing

    Combined with _netdev, noauto, and x-systemd.automount, the share is mounted on access after network readiness, avoiding startup issues .

3. fstab mounts are reliable and consistently available
GUI-based KDE mounts often fail to persist after reboot – especially in apps like Steam, which then can’t find the share. /etc/fstab mounts are system-wide and ready at boot, ensuring all applications have immediate access.

4. Massive Steam user base & Windows switchers

    Steam boasts ~132 million monthly active users and over 37 million concurrent users .

    Around 2.7% are Linux users – approximately 3.55 million monthly .

    Many are migrating from Windows, expecting network shares to auto-mount – failures in KDE lead to frustration and poor first impressions.

5. Modern networks: 2.5–10 Gbps are mainstream
Home and hobby networks frequently use 2.5Gbit or even 10Gbit Ethernet, delivering speeds over 1 GB/s – equivalent to SATA SSDs
linustechtips.com+13reddit.com+13androidcentral.com+13
.

6. SSD caching enables “local-like” gaming performance
Many NAS devices employ NVMe or SSD caches alongside HDDs, allowing games to be streamed from the NAS at near-local SSD speeds
lincplustech.com
.

    This lets users run game libraries directly from a cached NAS, yielding high performance and credible experience for gamers and media users.

Thanks. I'll pass this along and let the more experienced developers weigh in.