Bug 505234 - [Feature Request] Add GUI in Dolphin to permanently mount network shares, manage them, and provide better integration with applications
Summary: [Feature Request] Add GUI in Dolphin to permanently mount network shares, man...
Status: CONFIRMED
Alias: None
Product: dolphin
Classification: Applications
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-05 13:24 UTC by Nils Arnold
Modified: 2025-06-23 17:41 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nils Arnold 2025-06-05 13:24:00 UTC
Summary:
Currently, Dolphin allows temporary access to network shares (e.g. smb://) via KIO, but lacks the ability to permanently mount them through the GUI with fstab/systemd integration. This creates major usability gaps for regular users who expect similar functionality to Windows or macOS.

Request:
Please add a graphical dialog in Dolphin to:
- Browse and select network shares (already available via smb://)
- Mount selected shares permanently using /etc/fstab with systemd options (e.g., _netdev, nofail, x-systemd.automount)
- Securely store credentials using KDE Wallet
- Allow basic mount options to be toggled via GUI (e.g., read-only, automount, mount on boot)
- Provide status/feedback if mount fails

Optional:
- Offer simplified and expert modes (e.g., beginner-friendly wizard vs. full control)
- Integrate into right-click context menu: "Mount permanently..."
- Provide GUI toggle to remove/re-edit existing fstab entries

Why it matters:
- KDE aims to be a full desktop environment. A GUI for persistent network mounts is an essential tool for usability.
- Competing environments (e.g., GNOME + Nautilus + gvfs) already provide better integration for casual users.
- This bridges the gap between casual desktop use and sysadmin workflows.
Comment 1 TraceyC 2025-06-10 17:33:51 UTC
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.
Comment 2 Nils Arnold 2025-06-21 07:42:29 UTC
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.
Comment 3 TraceyC 2025-06-23 17:41:13 UTC
Thanks. I'll pass this along and let the more experienced developers weigh in.