16

KDE Frameworks and Plasma 5 provide the Linux community with a powerful compute environment and an accessible codebase for many developers to reuse critical modules. (Example: At the time of writing, the Solus-Project is looking to implement Kwin as their window manager due to the Gnome equivalent becoming too hard-coded to the Gnome shell). Despite, this very open approach to many of the projects which fall under the KDE Banner, there is one "component" which has limited KDE's growth and hampered adoption for new and veteran Linux user alike. Namely, KIO and the method in which it handles mounts (my experience is specifically with SMB and WEBDAV). I laud the development of any free and open-source project, KIO developers should be praised for the creation of such a complex tool. However, I believe a design choice is holding the component as well as the entire KDE software stack back.

[Disclaimer: For this next section, pardon any technological confusion. I am not a developer, just a basic software deployment engineer and a Linux advocate.]
File shares are at the heart of most businesses and are now highly prevalent in many homes (especially amongst our community). Modern daily computer consumption requires the fetching of all sorts of content from these servers including documents, images, video clips, sound files, etc... More often than not, this process is performed through something other than a file manager. Content tends to be viewed, sorted, and modified with an array of external programs that may or may not be familiar with the KIO design philosophy. Both my company and personal life depend on a series of ad-hoc SMB and WEBDAV connections from various Linux devices. Libreoffice, Krita, GnomeMPV, Evolution, Kdenlive, Nextcloud, Wire, Scribus and other application all interact with my servers outside of the way Dolphin and KDialogBox wish to. Fstab modification and other workarounds do not fit the modern-day connection needs. They are not reproducible on all devices and are not accessible to the average user (or even a basic engineer). The only solution I have found to work consistently (even on plasma) is managing mount point with the Gnome developed gvfs/udisk2/fuse system. Because it mount a "physical path" in run/user/gvfs/1000, all of my applications can access the network shares, stream data, and the basic workflow behaves as seamless as one would expect on other more proprietary platforms. So basically, I have to remove the powerful Dolphin file manager and replace it with Nautilus or another GVFS friendly file manager to manage ad-hoc mount points.

More developers are creating software on/for Linux, but it feels less are concerned about integrating their work with the specific IO nature of KDE. I really do not want to see this amazing platform (my favorite) crippled because of a networking stack design. Nor do I want to recommend to my co-workers/friends the ever more hard-coded Gnome-based environments simply because of availability of the user friendly GVFS implementation of SMB. Networking is one area where KDE can not exist alone in a silo. Developers do not seem keen on adopting a networking practice linked to a single desktop. However a general high-level approach, like the gvfs/udisk2/fuse system I am currently using, seems to work in production and at play.

I encourage the community to respond to my thoughts. From a technical stand point, can KDE developers ponder if KIO can be modified or built upon to replicate this functionality. I am not advocating the inclusion of GVFS into the KDE stack (unless it make sense), but rather a duplication of the features/simplicity it represents. I see this as a long-run issue.

Thank you reading this lengthy post,
ChrisHRD

If I understand correctly, basically you want changes to KIO to accommodate access of KIO-provided paths to non-KIO applications.
You cite a feature of gvfs - providing mount points for those paths such that other applications can use the paths through those mount points - as being an option that KIO could implement to provide this feature.

I really like the (relative) transparency that KIO provides. Within KIO-enabled applications any given resource becomes what looks like a local path to the resource (and then KIO knows out how to translate that path into whatever filesystem lookups, network requests, etc. necessary to read/write that resource).
I think it could be reasonable to implement such a feature as you are requesting to enhance KIO further to be usable by non-KIO applications.

Hello airdrik,

Exposing KIO paths to non-KIO applications is definitely a part of my thought. The ability for all applications to open, view, and save to a network share seems to be a necessary aspect of a general-use desktop environment. The universality of GVFS's approach enables applications, even those not written for the Gnome desktop, to reach out and access a share through a traditional Linux path in which the user's program knows no different than a normal local system path.

This is the core of my thought. Another issue tied into the current KIO implementation is the physical behavior of accessed network files. To my limited understanding, when you open a file via a GVFS share, the file is opened in RAM and data is saved back to the share as work is performed (real-time). This can be observed by the existence of lock files or other active artifacts in the share folder during usage by an application going through GVFS. KIO on the other hand, again to my limited knowledge, duplicates a file locally first (I believe in a folder called .kioexec in HOME). All changes are made to the local file, and then re-uploaded to the share upon close of the application. This is why a movie file accessed via Dolphin (KIO) doesn't stream instantly from a share, but the same file accessed from Nautilus (GVFS) will stream instantly.

Without fully understanding both KIO and GVFS, I cannot extol one fully over the other. KIO seems to follow a logical process of protecting changes locally in the event that a network configuration changes or is lost in entirety. However this is not fully practical because it requires the downloading of full files (large files like videos do not perform well in this circumstance) and it requires the program to be shut down to save a file back to the server (programs in many work cases might be open for a very long sessions and then there is always the lurking questions: "Did my file safely return to the server? Is my server version current?") As previous discussed, the current iteration of KIO also requires manual integration from developers beyond the normal save/open functionality, which might be asking to much in most cases. GVFS on hand seems to be a bit more carefree when it comes to exposing network connections (I am sure a stability argument can be made against GVFS here). But the absence of local file duplication and specialized KIO modules, allows for programs/users to interact with a network share simply, quickly, and with the ability to stream. This approach seems to meet the needs of the modern-day user (both professionally and personally) more so than the current KIO implementation. When writing the title of this brainstorm post, I alluded to the fact that this problem might not have been a problem readily considered when KIO was first developed. But, the world has changed, people are doing more with NAS devices than ever before. Networking is here to stay and I truly wish for Plasma/KDE to remain as a relevant option.

Sincerely,
ChrisHRD

I would give real money if a developper could make Dolphin/KDE mount network shares instead of using KIO. I'm stuck on Gnome since a couple of months because of this. I hate Gnome's UI with a passion but it's file manager handles network shares perfectly no matter which Linux application I use, and this is a must for me. Most of the time I work remotely over VPN with SFTP or Samba shares. Is it possible to offer an open-source bounty for this feature? I feel like Apple will have my money for a MacBook otherwise if I keep using Gnome...

So I wanted to follow-up on this topic because Plasma has had a couple iterations since my initial post. Unfortunately, the KIO design still causes fundamental interrupts in general office productivity. If you want to visualize the KIO problem, here are two simple ways to discover it.

Path 1:
--Begin a video project in kdenlive.
--Connect to your media NAS using Dolphin and smb://
--Use Dolphin to explore remote folders with hundreds of gigabytes of video files.
--Attempt to double-click on any video file to preview it prior to copying to your local drive.
--Problem encountered, no video playing application plays the video instantly from the remote location (vlc, dragon, kaffeine, totem, etc..) .
--Optional Step: Angry co-worker comes over to your desk and rants about how easy it was to do their work on an Apple Mac. *sigh

Path 2:
--Connect to your Company NAS using Dolphin and smb://
--Load Evolution, Libreoffice, Firefox, Wire, (or almost any electron, qt5, gtk app)
--Attempt to Save As to your Company NAS.
--Problem encountered, the process either doesn't show the NAS share or provides and error dialog box about unsupported protocols.

Bit by bit our company has migrated over to Linux. Unfortunately, Plasma with default networking settings is not able to meet our daily needs. Can someone in the KDE community help steer me in the right direction to solving this issue. I am currently *forcing* our staff to use Gnome due to smb, the file-manager, and daily apps behaving as expected with our company NAS . However, the continual feature dissolve found in subsequent Gnome releases is beginning to place our backs up against a wall. Help!

Sincerely,
chrisHRD

jjuneau wrote:I would give real money if a developper could make Dolphin/KDE mount network shares instead of using KIO. I'm stuck on Gnome since a couple of months because of this. I hate Gnome's UI with a passion but it's file manager handles network shares perfectly no matter which Linux application I use, and this is a must for me. Most of the time I work remotely over VPN with SFTP or Samba shares. Is it possible to offer an open-source bounty for this feature? I feel like Apple will have my money for a MacBook otherwise if I keep using Gnome...

I find this a shame too. I wonder if this can help somehow? https://neptuneos.com/en/knetworkmounter.html

Mounting Samba,SFTP und NFS Networkdrives is easily possible with KNetworkmounter.
This application uses the normal mount command to access network shares which makes it possible for every application to use files from the share and not relying on KIO (KDE Input/Output) .

I took jupiterbroadcasting.com's KDE challenge and tried to convert from GNOME to KDE for 2 weeks. I was able to convert everything in my workflow (minor audio issues with my handcrafted setup) except supporting file editing on remote servers over ssh the way GVFS allows. I use different editors for different tasks because of embedded scripting I've built up over the last 10+ years. For instance, I have some things I simply love Geany to edit.. I have a worflow which is really fast and fixes many issues with files people send me. I really didn't give Dolphin that much of a chance because of the KIO requirements for remote files. Humbly, I remembered from my past to type sftp:// or fish://, so I got to the servers, but I was baffled when save the file in my application was not updating the file on the server. I had to Google to see why it wasn't working. I expected it 'just to work'.

Seems obvious in 2018.. //server/mount/file always works for every Windows application because of the file system... not because the application knows it is using SMB to access the file. I've been able to switch Windows users over to a linux desktop with access to Window shares using smb://server/share/file syntax in Nautilus without much retraining. If we have to say 'Your application is not KDE subsystem aware'... they're gone.

Electron apps are the norm now. Use Visual Studio Code in the above scenario. With GFVS... just works as normal. Same behavior with Visual Studio Code on MAC or Windows. With Dolphin navigating to the file an opening it.. I get a separate XWindows dialog popup saying the local cache copy of the file has changed, would I like to upload the changes. Again... developer just left the workstation...

I simply replaced the default file application with Nautilus. It's slower. It's bugger.. but it supports what I do.

There is a window of opportunity right now where GNOME is struggling to handle some technical debt with their implementation and transition to Wayland. Their resource consumption is horrific for gnome-shell. If KDE/Qt is to overtake Gnome/GTK for the desktop community, this seems like one of the things that have to happen for the transition. Linux subsystem for Windows 10 is breathing down your neck.

I would also donate to get virtual file mounts to work with non KIO enabled applications. Just introduce ssh:// mounts with a virtual mounted file system and I'm good.

@ianp5a Thanks for the suggestion about KNetworkMounter. I had tried this, but it has problems with alternative ports on SSH.

A quick update,

So I have been experimenting with the qt/kde application smb4k, https://www.kde.org/applications/utilities/smb4k/. Rather than forcing content through KIO, smb4k uses its own implementation of SMB. By default on my Kubuntu and Arch/Plasma rigs, the "browse the network" ability doesn't work without a properly configured samba smb.conf file. I will explore that later. In the mean time, I clicked the "Open Mount Dialog" under the Mounted Shares tab and added in the smb URL manually. It asks for a UNC and IP Address, I just wrote the normal path for both (for example, smb://fakeaddress/MyFilesExample). Then, I ticked the "add this share to bookmarks" option, gave it a label, and then repeated for my other three shares. Each share appears as a physical path in /home/username/smb4k/url/mountname.

Things I have learned:
--You can change the mount location under settings
--You can change the version of samba used under settings, samba 1.0 used by default
--(could use help) You can set smb4k to remount shares, however only my first share remounts automatically at login
--You can quickly mount all bookmarked shares from the smb4k system tray icon.
--(not determined yet) System freeze from lock screen on lock or awake from suspend.

Any one else have smb4k experience?

-ChrisHRD

I joined the forums just to upvote this and post here.
I run my IT business on linux and have the techs use either Kubuntu or Elementary (I prefer KDE Plasma) - even though they would probably choose Windows if they had their own way.
However - it was extremely embarrassing to realise that the inbuilt KIO connections in dolphin
1) Are much much slower in regards to file transfers over an SMB share from our NAS than windows or using CIFS tools to mount from fstab
2) Refuse to let us attach a file to gmail or upload into a web form from a network share
3) Doesn't stream video directly to an application - it does some kind of intermediary copy.

Just to rub salt into the wound, I currently have the NAS automounting at boot with CIFS tools packages installed.
While this has fixed the file transfer speeds, and the ability to attach a file to the web - now Dolphin crashes if I MOVE (Copy or edit in place is fine) a file from my local disk to the fileshare.
It complains it can't write the file - then crashes except the file HAS been written successfully when you go back and check.

Anyway I can't believe it's 2018 and this kind of thing is still not working, as the OP mentioned this kind infrastructure setup is absolutely everywhere now. People work off of a NAS or central fileshare in conjunction with the cloud and expect that the application will not have to know anything about the underlying technology - the application just sees the file and uses it - it should be completely transparent.

If KIO can't be fixed to make this work then KDE Plasma needs to integrate a different tool and do it soon.

I'm following it all here, with great hope.

I note that the source code for knetworkmounter is located here
https://bazaar.launchpad.net/~leszek-le ... runk/files

It would be great if this could be leveraged to provide graphical user-mounting capability in a KDE Plasma 5 environment.

Hi all,
as I see almost 2 years passed from this topic had been started but the situation with the KIO's work with networks has not been changed.

dzavor wrote:Hi all,
as I see almost 2 years passed from this topic had been started but the situation with the KIO's work with networks has not been changed.

Hello dzavor,

In the 2 years ago since my original post, I have continued to do battle with SMB and KDE Plasma. I've tried many solutions/hacks/rival-DEs and each one had their pluses and minuses. I believe in my last post, I was testing smb4k. While the application is nice, I had my company stop using it about 8 months ago. It was just too cumbersome for non-technical users and a bit unstable in certain file transfer scenarios. I believe there was a Baloo issue with it too.

Anyways, the final solution that we have been rolling with for about 5 months is a combination of applications specific changes and better user practices. Our company is now running Fedora 30's KDE spin across the board. We dropped the majority of our SMB network shares in favour of WEBDAV shares. Libreoffice when using the gtk_kf5 VCL plugin gets native Plasma "save as" dialog boxes and can interface with and explore remote WEBDAV shares. Firefox with Plasma integration also gets native "save as" dialogs. VLC still needs to use the SMB-Backend, so we moved all of our media to a dedicated SMB Share. It is next to the WEBDAV shares in Dolphin's sidebar and no one really notices that the media share is using a different protocol. Also, we dropped Evolution in favor of Kmail. Once the last bug patches are made available in the repos [missed the Fedora 31 freeze ] KIO functionality should be fairly good. Lastly, we taught our employees to save working copies of files on desktop and then copy and paste with Dolphin back up onto the network share when work is completed.

Overall, it's still not ideal, but we can get our work done now. A few months ago, an article stated that a fuse integration layer was in progress for KIO. I wonder if that was ever completed?? If some one knows something, I would be curious to hear.

Cheers,
ChrisHRD

Doing some quick searching in KDE's phabricator yielded: https://phabricator.kde.org/T10263 (and parent task https://phabricator.kde.org/T10262) which had some movement earlier this year. These include links to a couple repositories for possible solutions (which could be downloaded and installed for testing; though it sounds like the intent is for the solution to be fully integrated into some future version of KDE's Kio): https://github.com/bosim/kiofuse and https://gitlab.com/Vogtinator/kio-fuse