Bug 75324

The thread that spawned this enhancement request can be found here; http://dot.kde.org/1076378191 

Now FUSE is included in the official Linux kernel - http://sourceforge.net/forum/forum.php?forum_id=495554 which makes this more interesting...

While the ioslaves may be run using the FUSE gateway for other people's needs, we will not use that in KDE. The foremost reason is that KDE runs on systems without FUSE (older Linux and non-Linux systems). And, besides, our IO needs are not the same as that provided by the system calls.

KIOSlaves are there and will stay, being accessed as they are now.

But I repeat: it doesn't mean you can't mount them using FUSE for other needs.

*** This bug has been confirmed by popular vote. ***

This issue though rather old pops up from time to time on different linux user forums; I would also love to see native fuse support for kio on linux systems and after seeing another thread on this topic decided to find something more on this in internet. The most informative thread:
http://markmail.org/message/nd2shd4tovhpwizm#query:kde4 kio fuse+page:1+mid:gin3b47qv2hokop4+state:results

"the point is that we can only use what's available, so making FUSE (or any 
other kernel-specific feature) a core part of KDE is almost certainly a 
no-go."

The explained reason not to include it to kde core is not that it is technically impossible, but that this is incorrect by ideology - not to include OS-specific code to kde core.

Following straight ideology is good, but for this requirement I do not see the difference for example with the whole Qt framework, or better - with Solid framework as it is a part of kde core as far as can see.

Both Qt and Solid have public cross-platform API and private platform specific backends.

Proof:
http://websvn.kde.org/trunk/KDE/kdelibs/solid/solid/backends/
http://websvn.kde.org/trunk/KDE/kdelibs/solid/solid/backends/hal/
http://websvn.kde.org/trunk/KDE/kdelibs/solid/solid/backends/wmi/

So, I can see HAL backend which is linux-specific as far as I know and WMI backend which would supposingly compile only on windows - and they both are in kde core. 

So, what's the ideological difference with KIO here - why not having kio/backends with "fuse" which would be compiled only on linux and "generic" which would run on all other systems?

At a minimum, it would be nice if KDE could detect if kiofuse is available, and if so, make a ~/.kioslaves directory that provides general filesystem access to the same kioslaves that are currently visible to KDE apps.

For example, if I typed "sftp://myserver" into Dolphin's location bar, KDE would automatically also mount it using kiofuse at ~/.kioslaves/sftp:__myserver/.

This could be a completely optional feature, only enabled if kiofuse is in $PATH or something.

Also, I don't know how close the KIO-GIO bridge (http://live.gnome.org/KioGioBridge) is to working, but using that should automatically fix this bug, because gvfs mounts all of its stuff in the ~/.gvfs directory.

Doing what Ryan suggests in #6 would be incredibly useful; I hadn't realized GVFS can do this <http://fedoraproject.org/wiki/Features/Gvfs#Dependencies>.

Does anyone know the status of KioFuse? It looks like it hasn't been worked on in years <http://websvn.kde.org/trunk/playground/libs/kiofuse/>.

*** Bug 185811 has been marked as a duplicate of this bug. ***

Badly, kiofuse (and KioGioBridge) are dead (no activity since 5 years).

It's really a GVFS killer feature to access distant flesystems from GTK and terminal applications (think about ls, cat, grep, sed, vim, etc).

Is the person assigned to this bug doing something to fix it?

Any news on this?

I would love such features too. For example using non-kde-tools like eclipse, which can't use kio. It even would be ok, if there would simply be a gui to setup such fuse-mounts and handle how/when they startup on login/..

*** Bug 341439 has been marked as a duplicate of this bug. ***

If there is one feature I would like to see implemented in KDE before switching to Plasma 5 it's this one. Mounting shares in the background is the only way to make sure every Linux applications (even non-GUI ones) can access network resources. The current approach with KIO would be great if we only used KDE based applications, but I think it's safe to say that it's not the case for most users. A lot of major applications like LibreOffice or Firefox do not support network access with KIO and it can be a "show stopper" for a lot of users.

There are workarounds like using smb4k or manually mounting CIFS shares using the distro's built-in tools (fstab, YaST, etc), but it's more suited for enterprise environments where desktops and laptops are centrally managed by a sysadmin team. Home users who just want to access a share on their NAS shouldn't have to deal with manually mounting them, it should work out of the box using Dolphin no matter what kind of application needs to access a network file.

I think smb4k's approach of mounting everything in a folder directly in the user's home directory is great. (as opposed to GNOME's way of mounting it in a hidden folder named ".gvfs" if I remember correctly?) If you need to open another network file from inside the application (using File>Open for example), you don't need to make sure that your application shows hidden directories to easily access currently mounted shares.

Yes, this is a "show stopper" and discourages use of KDE. Gnome does this correctly, although it hides the mounts in /run/user/<pid>/gvfs. Comment #6 would be a good idea. Perhaps some kind of standard could be discussed with Gnome folks so that the mounts would be in same well-known directory. This is something that has to be done.

Sadly kio can be used only by kde apps, not even plain qt apps can't use it :( .
kio reminds me of IO tower from Tron :D.

This is a rare thing to say, but this is one feature gnome does right over KDE. The limitations in using kio are beyond annoying. It's so productive to be able to mount ftp, sftp, smb, and others, and access them reliably from one app to another and to simply select the mountpoint in the file browser to re-access that shared resource.

kiofuse hasn't been touched in forever, and smb4k currently doesn't seem to work. Even when it does work it can be finicky to get the settings right to browse the network because it doesn't seem to obey settings for broadcast network, master browser, etc, correctly; And who wants to mess with that stuff anyway?

Plus, smb4k only solves the problem for samba [when it works], whereas gvfsd works with just about anything.

In fact even KDE apps themselves doesn't work without mount point very well. E.g. Dolphin (4.13.3) neither can show previews for mtp/smb files, nor does even open embedded terminal (F4 key) terminal in the right place — it being opened in pseudo-random dir.

The best solution for everybody is probably this:
https://wiki.gnome.org/Projects/KioGioBridge

Aside from the fact that the development stalled after KDE 4.1, of course…

"It's so productive to be able to mount ftp, sftp, smb, and others, and access them reliably from one app to another..." 
Even when you then close down the laptop and go home, and upon reopening the laptop, any operation on all of these mount points hangs (blockingly!) for 5 minutes because you lost the connection to the server? In my experience when this happens the application is completely blocked, not even repainting or anything, which is extremely annoying and counter-productive, isn't it?

(In reply to David Faure from comment #20)

> Even when you then close down the laptop and go home, and upon reopening the
> laptop, any operation on all of these mount points hangs (blockingly!) for 5
> minutes because you lost the connection to the server?

Those hangs are an issue on some lower level components (FUSE/plugins/kernel) and needs to be fixed there. Personally I haven't seen these for some time, but I mostly use SSHFS.

Closing them before suspending isn't that much of a problem, and even waiting for them to timeout isn't compared to the time it takes to mount via fuse ftp/sshfs/cifs.mount, etc so I can use an app like Brackets to edit a remote website, or watch a video with VLC, edit an image with gimp, etc.

As much as I would like for all my favorite apps to be native KDE, they just aren't.

On the other hand, as feature limited as gnome is, this is one area where they excel and I can use any apps, be they native gnome or not, with their gvfsd solution.

Closing them before suspending isn't that much of a problem, and even waiting for them to timeout isn't compared to the time it takes to mount via fuse ftp/sshfs/cifs.mount, etc so I can use an app like Brackets to edit a remote website, or watch a video with VLC, edit an image with gimp, etc.

As much as I would like for all my favorite apps to be native KDE, they just aren't.

On the other hand, as feature limited as gnome is, this is one area where they excel and I can use any apps, be they native gnome or not, with their gvfsd solution.

(In reply to Thiago Macieira from comment #3)
> While the ioslaves may be run using the FUSE gateway for other people's
> needs, we will not use that in KDE. The foremost reason is that KDE runs on
> systems without FUSE (older Linux and non-Linux systems).

Just make somewhere in systemsettings a checkbox to enable FUSE, which would be grayed out if it is not supported.

Also, let's look to the truth in the eyes — FUSE is supported on most existing OS, heck, even Android does! There's no good reason to not implement the most missing feature of KDE.

Yeah, the "not all platforms support FUSE therefore we can't have nice things anywhere" argument doesn't seem that strong to me.

It's interesting to see denialism about this feature. It'll block! It's counter productive! The fact is that many people use this type of feature on other desktops and OSes. If it sucked, we wouldn't be asking for it.

It's particularly frustrating that there are two partially complete (but abandoned) projects to add this feature. Is there anyone we can throw money at to fix this?

Right. Not all systems support compositing either, but there it is.

This one single feature lacking in KDE is the only thing that keeps me going back to nemo/nautilus. Mounting, so I can use other apps, greatly improves my workflow.

"Not all platforms support FUSE" is only the argument why we don't use FUSE _instead_ of our current solution in KIO (like gnome does AFAIK). But I would say this isn't what is being discussed here, which is rather about an *additional* KIO-over-FUSE feature.

The reason I don't like it is GUI apps being blocked (for a VERY long time) when pulling the plug (i.e. losing connection to the server, for whichever reason).

But if you like it, despite that risk, you can
1) resurrect https://techbase.kde.org/Projects/KioFuse
2) use sshfs

I would reassign the bug report to kiofuse if it actually had a bugzilla product/component.

I created the kiofuse product since people keep requesting this feature. Let's move this report there as David was mentioning.

*** Bug 372801 has been marked as a duplicate of this bug. ***

*** Bug 377057 has been marked as a duplicate of this bug. ***

Just to mention an alternative people might not know about.

I used to like Dolphin. A week ago I stumbled upon fun stats of Archlinux https://pkgstats.archlinux.de/fun turns out nowadays it's basically used by nobody, however many peoples are prefer pcmanfm instead, which I've never tried.

Long story short: pcmanfm with Qt backend upon running like `XDG_CURRENT_DESKTOP=kde pcmanfm-qt` looks almost completely like Dolphin! And guess what: upon entering a phone through mtp, and pressing F4 to open a terminal I see in the path "/run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C008%5D/Phone"! It's using gvfs!

The only missing feature I noted so far is lack of split-screen — but I can't remember the last time I used it, tabs are usually satisfy me; and I think I can sacrifice it in exchange to ability of using a terminal and non-Qt apps on every file system I'm entering.

Just make sure to install optional dependencies.

It's 2018 and KDE is not, IMHO, taking this headache seriously. I see projects like KioFuse or even Gnome projects like KIO-GioBridge, but the fact is that a professional can't stay fighting against the incompatibility between KIO-GIO on accessing to SMB/FTP/FISH remote files.

It's a pity, but I see this new year as one more in which I will not be able to suggest Linux desktop as a development platform in LAN/WAN environments.

*** Bug 330192 has been marked as a duplicate of this bug. ***

*** Bug 355328 has been marked as a duplicate of this bug. ***

*** Bug 342646 has been marked as a duplicate of this bug. ***

*** Bug 342272 has been marked as a duplicate of this bug. ***

*** Bug 215283 has been marked as a duplicate of this bug. ***

*** Bug 189695 has been marked as a duplicate of this bug. ***

This is a VERY strongly desired feature by a large number of our users (myself included).

I think we need to acknowledge the technical challenge of preventing app freezes and lock-ups, while also acknowledging the genuine need for this feature, particularly when one is using non-KDE software for any of the following use cases:
- Streaming large videos located on a remote location
- Intensively editing files located on a remote location
- The big kahuna: intensively editing large video files located on a remote location

What can we do to make this happen and still provide an adequately performant and responsive experience? This may be a case where we can learn something from GNOME, since they do this and frozen apps doesn't seem to be a common complaint among their users the way not having this features is for ours.

*** Bug 276047 has been marked as a duplicate of this bug. ***

@Nate: Thanks for bringing more attention to this issues!  I really like to see them improved... :-)

(In reply to Nate Graham from comment #39)
> This is a VERY strongly desired feature by a large number of our users
> (myself included).
> 
> I think we need to acknowledge the technical challenge of preventing app
> freezes and lock-ups, while also acknowledging the genuine need for this
> feature, particularly when one is using non-KDE software for any of the
> following use cases:
> - Streaming large videos located on a remote location
> - Intensively editing files located on a remote location
> - The big kahuna: intensively editing large video files located on a remote
> location
> 
> What can we do to make this happen and still provide an adequately
> performant and responsive experience? This may be a case where we can learn
> something from GNOME, since they do this and frozen apps doesn't seem to be
> a common complaint among their users the way not having this features is for
> ours.

I couldn't say it better than you. It's a headache to work in a LAN with remote files. Simple "user" don't know what will happen when he want to save his remote opened file. Too much risk to take Plasma seriosly to work daily. It's my experiencia, unfortunately.

Regards

(In reply to Nate Graham from comment #39)
> What can we do to make this happen and still provide an adequately
> performant and responsive experience? 

We must make it clear for app developers that they can't assume file i/o is quick and always successful. Any loading and saving should be done it's own thread and the UI must be able to handle it being slow or fail. File i/o must be handled much like network operations. An asynchronous helper library could be implemented to help developers if needed. Maybe also testing tools to simulate congested or unreliable network share.

@Nate
I think the Fuse part will be (relatively) easy. The hard part will be knowing when to mount and unmount, and to make sure any KDE app remains using KIO.

The only feasible solution to retrofit something that I can think of is: dolphin and the file dialog have explicit code to mount the KIOs when a user enters the dir; rather than doing that inside KIO itself. Then we make sure the file KIO has some way to return the "correct" URL in the UDS entry when listing that dir. 

BTW: a kio fuse was made years ago: https://techbase.kde.org/Projects/KioFuse . Would have been written against kdelibs3, but KIO hasn't changed /that/ much.

Thanks David! That sounds reasonable. Users from basically all other platforms have a pre-existing expectation that remote locations need to first be navigated to and mounted before use, so I don't think that will cause undue confusion.

So we could have Dolphin perform the local mounting, and then after that we just need some logic in Dolphin and maybe KIO that can detect whether a caller uses KIO or not, and determine whether to pass it a KIO URL or else the local path to the file on the mount.

May I suggest a look at the venerable autofs package. It also has nifty (negative) timeout tunables..

Can't GVFS (refactored to) be used as a library and share so all environments benefit?

(In reply to Solerman Kaplon from comment #47)
> Can't GVFS (refactored to) be used as a library and share so all
> environments benefit?

Not easily; it's GNOME technology that's specific to their stack.

It's worth mentioning that if we're worried about implementing this for fear of having our apps hang when transient network locations become unavailable, we *already* have this exact problem with the current model. See Bug 272361 and its many duplicates.

This is not true. Applications don't hang if they are using KIO. Just tried clicking on sftp:// in places panel slave to a machine that is turned off. Dolphin shows a progress bar, then an error message, but never hangs.

Applications only hang if they access shares via mounts, not via KIO.

Ah, thanks for the clarification, Christoph.

Still, based on the number of duplicates, I think we can see that this is a legitimate problem, because people are only using static and automounted mounts in the first place because of a lack of support for a better alternative in KIO.

And as a solution for the fact that mounts can hang, you want us to use *MORE* mounts? This doesn't make sense to me.

Bug 272361 is a very good proof of the problems that I expect to see more often if KIO starts mounting remote filesystems automatically.

I agree that there is a need (for editing remote files with non-KIO-based applications), it's not just well covered by the whole idea of mounting remote filesystems...

I don't think the GNOME folks have a lot of hanging issues with their FUSE implementation. macOS likewise has largely managed to avoid the issue too (don't know about Windows).

Whatever underlying technology we use to resolve the overarching issue is fine with me.

>I don't think the GNOME folks have a lot of hanging issues with their FUSE implementation.

Given GnomeVFS (fuse mounts) was replaced by GVFS (something similar to KIO) for all gnome applications I think they do.

(In reply to David Edmundson from comment #54)
> >I don't think the GNOME folks have a lot of hanging issues with their FUSE implementation.
> 
> Given GnomeVFS (fuse mounts) was replaced by GVFS (something similar to KIO)
> for all gnome applications I think they do.

When I use a Gnome file manager (like Caja file manager) and open a remote file from it with a Gnome app (GIMP, Inkscape, ATOM editor) it does it as is expected by user: The file opened is not copied locally and you can save directly being sure it's saved in the original file. So this is the way it should work with KIO, IMHO.

*** Bug 349815 has been marked as a duplicate of this bug. ***

*** Bug 125458 has been marked as a duplicate of this bug. ***

*** Bug 98032 has been marked as a duplicate of this bug. ***

*** Bug 205896 has been marked as a duplicate of this bug. ***

*** Bug 204398 has been marked as a duplicate of this bug. ***

*** Bug 307820 has been marked as a duplicate of this bug. ***

Just out of curiosity wouldn't it be quite "easy" to apply the same approach kdeconnect does, my creating wrappers on sshfs, and variants of ftp and samba, so accessing e.g. fusessh:// would invoke sshfs and thereby get a mount, other equivalents fuseftp://, fusesmb://, etc. Thereby the existing functionality would not be broken.

I have been porting kiofuse to KF5 
https://github.com/bosim/kiofuse

That's fantastic news!

*** Bug 397705 has been marked as a duplicate of this bug. ***

Any update, Bo? :)

*** Bug 383724 has been marked as a duplicate of this bug. ***

*** Bug 398174 has been marked as a duplicate of this bug. ***

*** Bug 164015 has been marked as a duplicate of this bug. ***

*** Bug 401649 has been marked as a duplicate of this bug. ***

I'm writing because I was wondering whether there was any more progress made?


My typical daily burden coming from average KDE user/consumer:

- manually connect to smb://foo in Dolphin because of course Network->Network nor Network->Samba shares doesn't work in 18.10 even with NT1 smb.conf. ok. drag & drop file from Dolphin to e.g. media player, either nothing happens (when trying mpv) or I get spammed with unwanted 'smb authentication' dialog (in case of vlc). Excuse me, but I have just authenticated a minute ago in dolphin, wth?
- decide to open audacious with meticulously curated playlists that I have saved over the years, that on its own works fine in other gvfs aware DE's, KDE on the other hand won't play any mp3 because it doesn't understand file:///run/user/1000/gvfs/smb-share* pathnames or the audacious player has problem playing from smb:// path.
- alright I have to manually drop to terminal and run `gvfs-mount smb://192.168.1.13/dōjin` and make audacious work again, finding this workaround on its own took me hours.

- it is 2018, why do we still have to manually write out smb:// mount points in /etc/fstab?
- Current implementation of handling network shares is very subpar and borderline embarrassing compared to other DE's. It makes KDE totally unusable..

No progress was made. Feel free to use gfvs in the meantime; there is no need to demotivate contributors.

(In reply to Kyle K from comment #71)
I agree, it’s very annoying. If you want to make it a little easier, you can install gnome‘s file manager (Nautilus) and use that as a front-end for GVFS

(Re last comment: I'd recommend using Mate's `caja`, or maybe Pantheons `nemo`, unless you prefer GNOME's dumbed down version of their own software and special design.)

Several people here should read and respect KDE Community Code of Conduct:
https://www.kde.org/code-of-conduct/

Being frustrated with KDE, GNOME or someone else’s software is no reason to be disrespectful or despising.

Besides, this doesn’t help to get this bug resolved and annoys people reading the comments. Would you like to help people spitting on your work?

(In reply to ariasuni from comment #75)
> Besides, this doesn’t help to get this bug resolved and annoys people
> reading the comments. Would you like to help people spitting on your work?

Comment about any code of conduct is unlikely to resolve anything and is surely less informative to KDE developers than comments that actually provides workaround and mention that they are disappointed to actually have to resort to such workarounds. Because that should tell to whomever cares why some long-time users could stop using KDE and, worse, stop recommending KDE to other non-geek users.

You cannot ask people to feel good because simple things like what is at hand here, reported in 2004 as a sadly "often neglected feature of KDE", is still not fixed in 2018, and works perfect on other desktop environments.

Reality-check: if you recommend KDE to someone, average Joe, and it turns out he as to do so much just to play a video, he will describe this KDE you recommended in way harsher terms than these recents comments here.

Please note that this ticket is not about a bug, but a missing feature to allow non-KIO applications to enjoy the KIO features.

This actually isn't about KDE software at all; KDE applications use KIO just fine. Any other developer that is familiar with both FUSE and KIO could code the bridge, and it is just unfair that you blame KDE developers for not writing one.

> Comment about any code of conduct is unlikely to resolve anything and is surely less informative to KDE developers than comments that actually provides workaround and mention that they are disappointed to actually have to resort to such workarounds. Because that should tell to whomever cares why some long-time users could stop using KDE and, worse, stop recommending KDE to other non-geek users.

Yeah because obviously referring to GNOME’s software as «dumbed-down» and KDE software as «embarrassing» is surely very informative to KDE developers. I’m just asking to stay to facts.

But thank you for the time I lost answering to you instead of working on code or bug reports, I guess.

(In reply to Christoph Feck from comment #77)
> Please note that this ticket is not about a bug, but a missing feature to
> allow non-KIO applications to enjoy the KIO features.
> 
> This actually isn't about KDE software at all; KDE applications use KIO just
> fine. Any other developer that is familiar with both FUSE and KIO could code
> the bridge, and it is just unfair that you blame KDE developers for not
> writing one.

To the end user there is no such thing as "KDE applications using KIO". In fact, they probably don't know what KIO is and they don't have to. Their reality is that when they use Plasma as their desktop environment, most applications can't properly access files on network shares. And when they are on other DEs, it works. So yes, it's a bug and a major one.

We all know there is a problem here. Complaining won't fix it, though.  As you can see, all it does is start an argument. What you can't see is that it makes people *less* likely to work on it, because developers are sensitive people. So while it may make you feel better right now to publicly vent, it's counterproductive because you're actually having the effect of making it less likely that the feature you want will get implemented.

Words have power. Make sure you're using yours to accomplish your goals rather than hamper them.

(In reply to Nate Graham from comment #80)
> We all know there is a problem here. Complaining won't fix it, though.  As
> you can see, all it does is start an argument. What you can't see is that it
> makes people *less* likely to work on it, because developers are sensitive
> people. So while it may make you feel better right now to publicly vent,
> it's counterproductive because you're actually having the effect of making
> it less likely that the feature you want will get implemented.
> 
> Words have power. Make sure you're using yours to accomplish your goals
> rather than hamper them.

I agree with you, complaining won't fix it. And I understand the huge technical challenge that is required and that resources are limited. But you have to admit that, as a user, it's kind of frustrating to see this longstanding bug on the "WISHLIST" instead of being treated like a proper major bug. We don't ask you to fix it in one month, we ask you that you at least prioritize this issue properly.

Indeed, it is very frustrating. Though I am a KDE developer, I am also a user of non-KDE software on Plasma and have to deal with the fact that my family entertainment machine's samba share is less usable that it is on Windows or macOS machines. I get it. We all do. It's a pain in the butt.

You need to understand that KDE, like most open-source software communities, is predominately a volunteer organization. There are some paid developers, but they are paid generally to work on the things that their employers want.

I agree 100% that solving this problem in one way or another is an important strategic issue for Plasma adoption. But you need to have patience. If you (like me) don't have the technical skills to contribute, a more productive approach would be to try to go find developers who are interested, or start a bounty of more than $2,000 or so to fund the development, or try to find a company that uses Plasma internally and wants to sponsor the work.

Etc.

It's clear that the current global pool of FLOSS maintainers is overloaded and we as open source community should strive to set up more attractive incentive systems and get more people involved in development in 2019. We at https://OpenSourceEcology.de are trying to get industry investing in open source hardware, which is difficult. OSEG wants to team up with the free software free knowledge student club https://fsfw-dresden.de to circulate more of our free software USB sticks. With support of our Studentenrat, we gave away 120 8GB-sticks with a KDE debian live to uni freshers this year.. The next idea is to give these sticks with live working office & pim suite & fresh builds of freecad to f.e. industrial engineers to check out as a tool for business and offering them to invest into resolving specific bugs and implementing specific features (c.f. blog post https://fsfw-dresden.de/2018/06/interview-sander-finanzierung-freie-software.html "Interview mit Prof. Sander: Finanzierung von freier Software"). If we can offer a better more accessible ecosystem (faircoin bounties, public monuments, free chocolate? .. c.f. https://fsfw-dresden.de/2018/08/funding-floss.html "Funding Freedom Initiative - Idee zur Finanzierung freier Softwareprojekte") for this, we might have a chance to convert more of society to use and develop open source systems.

Or we wait until http://OpenAI.com learns to code and have the AI agents fix the bugs : )

If we raised enough money is it a project that developers at Blue Systems could take?

Nate, you are right: we should have made a bounty/kickstarted this earlier. Way earlier. Probably we did not because many would have though it would be done anyway. That was a mistake on our part, all of us following this reports since more than a decade.

This KDE bug tracking system should have an integrated kickstarter-alike system!   Instead of adding ourselves to CC, we would add ourselves to a pledge, I am sure at some point we could raise some reasonable amount of cash.

I personally unfortunately lost interest in KDE because that, and many other little things (I wont say what it relates to, to avoid off-topic flamewar), forced me not only to no longer use it (granted: not so meaningful, I nowadays use mostly use awesomewm - so I could deal with it and work around it) but I also was forced to make non-geek people (parents, in-laws and such) I am administering the computer of use something else because things like this had to work. But if someone is kickstarting something about it, I would donate a few coins still :-) and I am sure I would not be alone.

I agree with Mathieu Roy and Jean-Francois Juneau comments, even last talking about contributing with donations. I'm sure none of us try to understimate any developers work, but the reality is that in my case, after more of eight years using Linux and KDE, I can't recommend to any on my job to migrate to KDE precisely cause every day we need to do our job, not fighting with issues (caused from Plasma or not) accessing FTP or SMB files in an heterogenous way. I access each day to FTP and SMB local services, but each day I must take into account that it's not the same if I open a remote file from Krusader (or Dolphin) that from Caja, or if I compare remote files with Meld or with Kompare or KDiff, or if I open a remote file with Kate or with Atom ... it's really a headache for a simple user that want to work transparently from Linux systems. As other users said, it's 2018, and I can see KDE desktop changed his name a lot of time ago to Plasma, and each new version of Plasma I expected to see this issue solved, but at this point I can't recommend anyone to jump Linux if they really want to work with files outside their PCs. 

In fact, is not the unique issue that is not solved and even not recognized, despite it's easy to verify they: https://bugs.kde.org/show_bug.cgi?id=351175

Some times, as a Linux user and a Plasma fan, seeing no patches for some issues make me not want to notify issues cause seems my efforts to notify this problems are good for nothing. You can be sure non English speakers (like me) have an extra effort to try to report issues to developers.

Anyway, I give thanks and best wishes to KDE community and developers for their day to day job.

I would happily drop a hundred bucks on a fundraising/bounty campaign if this would mean somebody competent is being paid to work on this.

Nate, do you think this is something that can organized and coordinated by KDE?

I’d like at least to see what’s reasonably achievable and how much money it would cost. And maybe we could divide this goal into easier-to-achieve goal so that we could start working toward it.

This request is stuck for so long now; maybe as a community we should try to tackle it differently, and think about it outside the limited scope of a bug report.

Splitting this into multiple small tasks:

First pre-requisite step is making all KDE apps robust to blocking calls on files which it thinks are safe as they're on the local file system. Adding fuse mounts before that is introducing a ticking bomb onto your computer - and one reason why wanting to add FUSE mounts anyway is met with negativity.

Create a samba mount (manually or ksambamounter) unplug the cable and try to find code paths that freeze. Most common ones are fixed, it'll be obscure places with context menus, favourites, bookmarks, symlinks on desktop that will trigger this. etc.  If/when they do, get a backtrace and open a new bug.

If you want to help this get solved, this is the most helpful step readers here can do without any coding. 

The remaining steps are mostly outlined in comment #44 (which is buried in people spamming).

Is there any reason by KDE really needs it's own remote vfs abstraction system and cannot use GIO/GVFS instead as suggested in comment #6? (There is even some code to start off for inspiration from even if its like 10 years old.)

Some selling points GVFS/GIO has over KIO (mostly subjective, but meh):

  * Already has the mentioned FUSE layer
  * Used and maintained outside the KDE community
  * Copying many small files (locally!) is a lot faster
     - (Although it's still insanely slower than good old `cp A B`.)
  * Finally having a standard would probably make a lot more external devs happy to add native support for this (I don't think that standard could be KIO, since it's so KDE/Qt/C++-centric while GIO basically only requires GLib)
  * (Doesn't crash on MTP [might just happen to be an issue with all mobile devices I ever owned, but it never happens when using GIO instead].)

I'm honestly interested in the devs opinions here since: There may well be something obvious I'm not seeing.

Even if we did, (which would be a waaaaaay bigger project than what's proposed here) they don't have a 1:1 mapping with regards to spawning/teardown - it'd need every client app to change which isn't do-able in the 5.x series.

Lets keep things on topic and not hide the dev comments.

I think we can all thanks David Edmunson to remind us how important it is for the end users not to disturb too much developers, since they are clearly so devoted to fix this issue in particular.

So please, agree with David Edmunson to let the developers talk about how to fix this important issue, that they cared so much about between 2004 and 201.. 2019, even though this issue does not exists on any other desktop. 

We should not bother them with stupid ideas as to set a bounty for it or fund development. If we pay attention what a good guy like David says, they clearly do not care of it. And this guy must matter since his statement about how happily KDE trashed massive amount of (working features) code to replace them by some-init-that-replace-all was an omen.

Thanks to keep all the good work. I hope the conduct of conduct allows me to tell that KDE 1 was an improvement over Windows 98/NT 4.0. while KDE current is much less usable than Windows 10 as desktop (but even 7/8...). But who cares about the feeling of KDE 1 users, eh!? 

Please accept our apologies, we should never have suggested to sponsor any development.

> First pre-requisite step is making all KDE apps robust to blocking calls on files which it thinks are safe as they're on the local file system.

Uh, no. KDE applications are expected to use KIO. You would have to fix all _other_ applications, which don't use the KIO API. I guess applications using GIO are also safe, because (I hope) GIO was also designed asynchronous. But POSIX API is synchronous, and users of those applications just have to live with UI hangs unless they use separate threads for IO.

(In reply to Christoph Feck from comment #92)
> > First pre-requisite step is making all KDE apps robust to blocking calls on files which it thinks are safe as they're on the local file system.
> 
> Uh, no. KDE applications are expected to use KIO. You would have to fix all
> _other_ applications, which don't use the KIO API. I guess applications
> using GIO are also safe, because (I hope) GIO was also designed
> asynchronous. But POSIX API is synchronous, and users of those applications
> just have to live with UI hangs unless they use separate threads for IO.

It's okay to use KIO, nobody advises to drop it. Idea is just to improve a usability on FUSE mounts a little bit.

You can't reasonably expect every existing app out there to implement a new protocol just to make it compatible with KDE.

Also, imagine how bloated servers would become if every terminal utility would implement KIO just because on KDE-powered desktops it's the way to go.

---------

The main selling point of FUSE is that nobody have to implement anything, it just works™.

>Uh, no. KDE applications are expected to use KIO. 

Absolutely, I wasn't suggesting otherwise. 

What I'm saying is that any code paths that check the url.scheme() == file and take a different path need to still go through KIO. I can think of at least 3 examples in plasma over the last year where this happened. Otherwise putting FUSE mounts on the system has the risk of making our own apps worse.

(In reply to Nate Graham from comment #66)
> Any update, Bo? :)

There are really issues with kiofuse. Tried to transfer a relatively big file, got me 6 mbit/s and intensive CPU load, with plain sftp I got 100 mbit/s. I saw in the log

log_kio_sftp: seek, offset =  31170560
log_kio_sftp: write, offset =  0 , bytes =  4096

So kio_sftp is called just to write 4K, because "cp" does it. KIO provides file_copy, file_move etc for these operations. FTP has shortcomings as well, because no seek is possible kiofuse is not able to mount the ftp kioslave. 
I am quite sure an analysis will discover other shortcomings as well. I must say I am not really fan of inventing the wheel again here, maybe using existing fuse technology like sshfs is a better choice, or gvfs.

I agree, if there are existing solutions, I'd just use those.
I don't know however if GVfs lacks required features that KIO has or there are other reasons not to use it in KDE.

(In reply to Bo Simonsen from comment #95)
> (In reply to Nate Graham from comment #66)
> > Any update, Bo? :)
> 
> There are really issues with kiofuse. Tried to transfer a relatively big
> file, got me 6 mbit/s and intensive CPU load, with plain sftp I got 100
> mbit/s. I saw in the log
> 
> log_kio_sftp: seek, offset =  31170560
> log_kio_sftp: write, offset =  0 , bytes =  4096
> 
> So kio_sftp is called just to write 4K, because "cp" does it. KIO provides
> file_copy, file_move etc for these operations. FTP has shortcomings as well,
> because no seek is possible kiofuse is not able to mount the ftp kioslave. 
> I am quite sure an analysis will discover other shortcomings as well. I must
> say I am not really fan of inventing the wheel again here, maybe using
> existing fuse technology like sshfs is a better choice, or gvfs.

You're lucky. Most of the time my kio powered transfers just die. Single small files are fine. If I copy anything large, like an entire folder, or an iso, over ssh or smb, it almost always just dies.

I gave up on it. I just use nemo file manager for anything to do with remote FS. It's too frustrating.

I know there are other features concerning KIO slaves that people don't want to give up, when you cant do file operations with a file manager, that's kind of a moot point.

This is currently being worked on as a Google Summer of Code project!

The reason why we can't use GNOME's GIO+GVFS is because the architecture is completely different. Adapting it to work with our stuff, if it was even possible, would be an enormous engineering challenge on the order of just rolling our own.

It would be like adapting a jet engine to power a tugboat. You *could*, but why not just build a tugboat engine instead?

I found this implementation that mostly works:
https://gitlab.com/Vogtinator/kio-fuse

(In reply to Jan Przybylak from comment #99)
> I found this implementation that mostly works:
> https://gitlab.com/Vogtinator/kio-fuse

I understand that could be a reference for developers, but it's not a transparent and transparent solution for users.

In fact, the kio-fuse project is being worked on for Google Summer of Code this year!

Nate, I can't see anything about that https://community.kde.org/GSoC/2019/Ideas
Where is info about what you are talking about?
Thank you

(In reply to Rafael Linux User from comment #102)
> Nate, I can't see anything about that
> https://community.kde.org/GSoC/2019/Ideas
> Where is info about what you are talking about?
> Thank you

You find it here: https://summerofcode.withgoogle.com/projects/#5417220300079104

I wish we could have with that THE solution for all this years of headaches concerning this issue.

Thank you

This is now implemented with the new kio-fuse system!

https://cgit.kde.org/kio-fuse.git/

Go bug your distros of choice to package it and ship it by default!

Let's all give a big round of applause to Alexander Saoutkin and Fabian Vogt who took the lead on this challenging and important project.

(In reply to Nate Graham from comment #105)
> This is now implemented with the new kio-fuse system!
> 
> https://cgit.kde.org/kio-fuse.git/
> 
> Go bug your distros of choice to package it and ship it by default!
> 
> Let's all give a big round of applause to Alexander Saoutkin and Fabian Vogt
> who took the lead on this challenging and important project.

Yay, finally this was done. Yes, big applause to Alexander Saoutkin and Fabian Vogt. Hope that this will be added to KDE Neon soon :-)

Is that true???? I wait it for summer, but I forgot my hopes. If it's solved, my congratulations for all developers that fix this long-term issue!!!!! They will make happy to all that bet for KDE as the Linux environment for business.

;)

Very very very VERY happy it got fixed!!! 

A BIG "thanks" to all involved!

*** Bug 394753 has been marked as a duplicate of this bug. ***

*** Bug 396641 has been marked as a duplicate of this bug. ***

Please, someone can tell here which Plasma/KDE-Frameworks/KDE-Qt have been patched? I'm using Framework 5.67 and Qt 5.14 and problem is not fixed. Maybe I need to install some new library??

https://community.kde.org/GSoC/2019/StatusReports/Feverfew

Thank you

Full support is coming with the upcoming release of Dolphin/kio-extras 20.04. Frameworks support went in for 5.67. Both will require you to install the kio-fuse package.

Well, as I wrote, I'm using Framework 5.67, but no "kio-fuse" package in that repository. Dolphin is version 19. So, when Dolphin 20 have been compiled and installed, will be kio-fuse installed by default? And will it work when opening remote files from LibreOffice, Krusader, GIMP ...?

Thank you

Created attachment 126422 [details]
system copying file to local file system before opens it

I'm using Neon unstable edition, kio-fuse package is installed
but my system is still copying files from samba share to local file system before
opens them. My screenshot shows Plasma notification after I open an audio file
with Strawberry player.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.18.80
KDE Frameworks Version: 5.68.0
Qt Version: 5.14.1

Created attachment 126425 [details]
better screenshot of system copying file to local file system before opens it

It's using KRun instead of streaming, due to a lack of streaming support. Streaming support just made it in yesterday. Might need a few days to get into the repo in Neon unstable.

*** Objectionable content removed by KDE Sysadmin ***

*** Objectionable content removed by KDE Sysadmin ***

Apologize if this is a dumb question, but is there any way to get Dolphin 20.04 installed on (and thus this issue fixed in) Kubuntu 20.04?  it's not in the default repos yet (still Dolphin 19), but i.e. some "testing" repo, PPA, or other approach?  Or is the only way to just wait?  I'm a new Linux user coming over from Windows & always "fighting" with being able to reliably access network shares on various networks (it's a portable laptop) has been *the* biggest struggle for me as a new user.  Any way I could get this installed now would be greatly appreciated (i.e. I see this was reported fixed in January, aka 6 months go - no idea how long it would take if I "just wait" for it to appear in the Canonical repos ;))

(In reply to Metal450 from comment #119)
> Apologize if this is a dumb question, but is there any way to get Dolphin
> 20.04 installed on (and thus this issue fixed in) Kubuntu 20.04?  it's not
> in the default repos yet (still Dolphin 19), but i.e. some "testing" repo,
> PPA, or other approach?  Or is the only way to just wait?  I'm a new Linux
> user coming over from Windows & always "fighting" with being able to
> reliably access network shares on various networks (it's a portable laptop)
> has been *the* biggest struggle for me as a new user.  Any way I could get
> this installed now would be greatly appreciated (i.e. I see this was
> reported fixed in January, aka 6 months go - no idea how long it would take
> if I "just wait" for it to appear in the Canonical repos ;))

First of all, you're asking in the wrong place. This is upstream KDE bugtracker, and KDE has no influence over what downstream does.

But answering your question: I doubt a newer Dolphin will ever hit the default repos of Ubuntu 20.04, especially since it is an LTS release. This is a known problem with Ubuntu: they take a bunch of software, and for whatever reason freeze it at specific version, and stop to even take minor version updates. It is a real problem, I've seen quite a few posts on askubuntu site, where solution to people's problems was to just install a modern libinput on their 18.04 Ubuntu, because they were stumbling upon a bug fixed long ago, but 18.04 has a really ancient libinput.

In a sense, you're lucky here that there's at least a KDE PPA, so you can get latest KDE on your Ubuntu somehow. There's no PPA for libinput, so those users are out of luck.

You either live with it, or you use more upstream-friendly distro, like Fedora. I don't think there's much else you can do.

Gotcha, thanks.

I did some searching & found the Kubuntu Backports PPA here (https://community.kde.org/Kubuntu/PPAs#Kubuntu_Backports), but adding it didn't make the Dolphin update available.  I also since found this: https://askubuntu.com/questions/1260704/how-to-install-latest-stable-dolphin-file-manager-on-kubuntu-via-xdg-opendiscov

So, I guess the options are Flatpak, or wait until Kubuntu 20.10 ships in October (or hope that it gets added to Kubuntu PPA sometime in the interim).
Thanks for your reply :)

> I'm a new Linux user coming over from Windows & always "fighting" with being able to reliably access network shares on various networks

kiofuse won't help with accessing networks. If you cannot access them from Dolphin (by using a correct smb:// or sftp:// URL including server, path, user, and password), you won't be able to access them with kiofuse either. It is possible your issue can be resolved using the "old" version provided in Kubuntu 20.04.

But as Konstantin suggested, the best place for new users to ask questions is in forums instead of a bug tracker. Be sure to better describe your issue by providing exact steps that others can follow. "Fighting" is not a good way describe what you were doing.

(In reply to Christoph Feck from comment #122)
> the best place for new users to ask questions
> is in forums instead of a bug tracker. Be sure to better describe your issue
> by providing exact steps that others can follow. "Fighting" is not a good
> way describe what you were doing.

Hi, thanks for the reply - I actually did indeed reference a few other places (i.e. StackOverflow, Reddit), & it was suggested that the behaviors I was seeing were due to kio-fuse & that they had been fixed in 20.04.  The specific issue is that although I can browse smb, the vast majority of programs fail to be able to work with them. i.e. opening a file from smb in VLC fails; opening a photo in XnViewMP works but then cannot scroll to any others; opening a PDF in MasterPDF has to copy the entire file over the network before it can view, and so on and so forth.  Since all of these do work properly in other file managers (i.e. none of these issues exist in Nemo, Nautilus, Caja, etc), it was indicated that the problem is unique to Dolphin, and after some more searching, I was led here.  And I believe that the behavior has been fixed, & thus things should now work properly in Dolphin as well.  If I can figure out a way to get 20.04 installed ;)

Just a follow-up, I don't think Flatpak works - I was able to install Dolphin 20.04 that way, but in that case, I couldn't access smb at all.  Presumably because of its packaging / it doesn't interact with the other necessary parts of the system to take advantage of this fix.

*** Bug 343591 has been marked as a duplicate of this bug. ***

KDE Plasma Version: 5.20.2
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.1
Dolphin 20.x
kio-fuse installed

... and NOTHING CHANGED. "LibreOffice", "Visual Code", "MELD" and any application no Qt based, continue copying locally the opened remote file. Something is still going wrong. I can open and save directly any file thru FTP with Kate, and works like working in my local disk. However, mentioned applications, even on SMB remote folders, are always copied first to local. I can try to open a PDF on FTP connection but first is copied to my hard disk.

What's supposed user need to do to make this to work?

Thank you

Correction: It seems LibreOffice works ok over Samba (doesn't make a local copy yet)

(In reply to Rafael Linux User from comment #125)
> KDE Plasma Version: 5.20.2
> KDE Frameworks Version: 5.75.0
> Qt Version: 5.15.1
> Dolphin 20.x
> kio-fuse installed
> 
> ... and NOTHING CHANGED. "LibreOffice", "Visual Code", "MELD" and any
> application no Qt based, continue copying locally the opened remote file.
> Something is still going wrong. I can open and save directly any file thru
> FTP with Kate, and works like working in my local disk. However, mentioned
> applications, even on SMB remote folders, are always copied first to local.
> I can try to open a PDF on FTP connection but first is copied to my hard
> disk.
> 
> What's supposed user need to do to make this to work?
> 
> Thank you

By kio-fuse installed you mean you ran `make install` or installed the program via your package manager? If not, you'll need to do one or the other.

for anyone else, for kio-fuse to automatically start when needed, then install the application from your package manager if possible. Otherwise, when building run `make install` into your system directory to take advantage of DBus on demand start.

Otherwise, please file a bug under the kiofuse product.

I did a repository installation
sudo zypper in kio-fuse

Anyway I must clarify that MELD even don't let open remote files, so I can't consider a that case a issue of kio-fuse, but MELD. LibreOffice works now well at over samba. I didn't try still over ftp. I need to investigate more, cause I found cases (like MELD) that simply are not ready to work over network protocols.

Thank you

*** Bug 429292 has been marked as a duplicate of this bug. ***

Despite KIO-FUSE implementation does its job, unfortunately, it's still a workaround. Yes, we can open and save transparently our remote files but indeed, they are working like temp files on local storage. The issue is that if I open a remote file with (for example) "Visual Code Studio" or "LibreOffice", restart my system and I try to load them again as usually with "File, Recent files", I CAN'T load that remote files cause the stored path in such applications are pointing to temporal local files (/var/run ....) instead real remote files previously opened.

So that's why I consider this bug is not fixed, still a workaround. 

Please, fix it

That sounds like a bug. Please file it separately.

(In reply to Nate Graham from comment #131)
> That sounds like a bug. Please file it separately.

Perfect, I'll do it. I'm sorry if not the correct thread.

Best regards

(In reply to Rafael Linux User from comment #132)

> Perfect, I'll do it. I'm sorry if not the correct thread.

Please, share the bug number / link with us.

thanks

(In reply to john from comment #133)
> (In reply to Rafael Linux User from comment #132)
> 
> > Perfect, I'll do it. I'm sorry if not the correct thread.
> 
> Please, share the bug number / link with us.

https://bugs.kde.org/show_bug.cgi?id=432856

> 
> thanks

Installed recently KDE Neon User Edition to check Plasma 5.21
Tried to play video over LAN.
Neither VLC nor SMP works.

Your input can't be opened:
VLC is unable to open the MRL 'smb://192.168.100.100/CamVideo/CAM01/2021-02-25/cam1_2021-02-25_23-05-59.mkv'. Check the log for details.

There is nothing else in LOG. I am able to copy this file using Dolphin and play it from the local HDD.

(In reply to Alexander from comment #135)
> Installed recently KDE Neon User Edition to check Plasma 5.21
> Tried to play video over LAN.
> Neither VLC nor SMP works.
> 
> Your input can't be opened:
> VLC is unable to open the MRL
> 'smb://192.168.100.100/CamVideo/CAM01/2021-02-25/cam1_2021-02-25_23-05-59.
> mkv'. Check the log for details.
> 
> There is nothing else in LOG. I am able to copy this file using Dolphin and
> play it from the local HDD.

In my distro, I needed to install manually kio-fuse ... is installed by default in Neon?

kio-fuse is installed, yes.
I'm sorry - a was too hasty to report this issue. It's more complicated.

1) This time I didn't reduce protocol level for SMB, which I always did previously to use the ability to browse shared folders.
Now I just used Network->add networt folder -> Microsoft Windows Network Drive.

2) I have a few mp4 and mkv files on shared folders. Most of them with x264 encoding. SMPlayer is unable to open any of them over network.
All of them could be opened by SMPlayer from the local drive.

3) VLC opens SOME video files. It seems that it is able to open a file which is up to 12-15 MB in size. It does not open 20MB files and larger.

(In reply to Alexander from comment #135)
> Installed recently KDE Neon User Edition to check Plasma 5.21
> Tried to play video over LAN.
> Neither VLC nor SMP works.
> 
> Your input can't be opened:
> VLC is unable to open the MRL
> 'smb://192.168.100.100/CamVideo/CAM01/2021-02-25/cam1_2021-02-25_23-05-59.
> mkv'. Check the log for details.

VLC claims smb support, though kio-fuse is *not* used. On Debian-derivatives, you need vlc-plugin-smb. It also only works for password-less shares out-of-the-box, otherwise you have to configure VLCs smb plugin.

See https://bugs.kde.org/show_bug.cgi?id=436553

Need help to make the major shift to a new ERP?, Nevas Technologies can help support your current Microsoft Dynamics NAV Environment irrespective of the version that you are on. We provide Functional, Technical, Production support and Infrastructure (Server Maintenance, Finetuning, and so on…) services for your current Microsoft Dynamics Navision application. We also provide upgrade services of your old MS Navision version to the latest Dynamics Navision 2016/2017/2018 versions if you are not ready to upgrade to Dynamics 365 Business Central or Unified Operations.

https://www.nevastech.com/solutions/microsoft-dynamics-erp/microsoft-dynamics-nav/dynamics-nav-support

This is considered "CLOSED FIXED" now but I don't understand how it could be so if everything started by Alexander in #c135 is still valid.

That's an issue with VLC itself that can manifest when using a passwordless samba share. We may be able to work around it in KDE code though.

More generally, when the bug report for a feature is closed because the feature is implemented, new bug reports should be used for reporting issues with the feature.

Nate, many suggestions and bug reports got merged in tgis one as a deplicate despite those issues not being solved.

For example my own proposal to have Dolphin automativally mount smb shares when opened so applications no longer need SMB support.

If this issue is rightfully closed that means suggestions like these were ignored and unjustly merged into this issue as this would be the solution to those problems.

VLC is a good example because it can play when SMB shares are mounted and this makes the SMB experience significantly easier.

Instead of everyone effected refiling their bug report perhaps you can assist in reopening one of these duplicates so that the problem we were hoping to get solved can still be solved?

(In reply to henk717 from comment #142)
> Nate, many suggestions and bug reports got merged in tgis one as a deplicate
> despite those issues not being solved.
> 
> For example my own proposal to have Dolphin automativally mount smb shares
> when opened so applications no longer need SMB support.
> 
> If this issue is rightfully closed that means suggestions like these were
> ignored and unjustly merged into this issue as this would be the solution to
> those problems.
> 
> VLC is a good example because it can play when SMB shares are mounted and
> this makes the SMB experience significantly easier.
> 
> Instead of everyone effected refiling their bug report perhaps you can
> assist in reopening one of these duplicates so that the problem we were
> hoping to get solved can still be solved?

I spoke to soon, the implementation does function very closely to what i suggested after testing it more thoroughly on my system.
I do still think it would be better to streamline this for the people still effected and coordinate the new bug report from this one to prevent further duplication.

A year has passed since my last comment.
I installed Kubuntu 22.04 Beta to check how it goes.

Only VLC is able to play music/video over an SMB share and it asks for credentials, though share is already opened in Dolphin.
But VLC is not a very convenient music player.

Elisa is unable to open SMB files from Dolphin. Neither by drag-n-dropping nor by "open with".
DEADBEEF, installed from snap store, is unable to play smb files too.
Foobar200 installed using WINE also does not open SMB files.

Very coincidental timing, I just installed KDE Neon 5.24 literally this weekend for this exact reason.  Oddly, I wasn't even able to get VLC to work - it just shows the same error as it did in Kubuntu 20.04. That's actually the software I most want to use from smb shares - did you need to install anything extra to get it to work? kio-fuse was installed already by default.

Also, looks like this bug report is closed, even though it doesn't actually work in many cases.  Is there an updated/current one to follow...?

(In reply to Metal450 from comment #145)

No, I did not install any additional software at all before trying VLC.
My SMB shares are also runnung on Ubuntu usnig config like this:
-----------------------------
[global]
workgroup = WORKGROUP
server string = Samba Server on node01
netbios name = node01
security = user
map to guest = bad user
#guest user = nobody
dns proxy = no
server role = standalone server

local master = no
preferred master = no
os level = 30

#wins support = yes
#name resolve order = wins lmhosts hosts bcast

acl allow execute always = True

# Always advertise the shares automatically
auto services = global
min protocol = SMB2
-------------------------------
I don't know if there are any bugreports on this issue. I didn't make an effort to find any relevant bugreports because I do not have any hope for this issue to be fixed.
I do not report a bug here, I just grumble.

Anyway. Kubuntu 22.04 looks nice and I did not encounter  bug 403580 which was a showstopper for me on previous versions.

see bug 436553 about VLC player

no special configs here either.

running:
Operating System: KDE neon 5.24
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 5.13.0-39-generic (64-bit)

VLC, MPV and Firefox reads fine from SMB remote share with either audio (mp3) or video (webm).

SMPlayer (with mpv backend) and Elisa, however, do not. 
(That leads me to think it's a program-specific bug and not Plasma related)

(In reply to Patrick Silva from comment #147)
> see bug 436553 about VLC player

Thanks for the reply. Will start following that bug instead.

(In reply to Alexander from comment #144)
> A year has passed since my last comment.
> I installed Kubuntu 22.04 Beta to check how it goes.
> 
> Only VLC is able to play music/video over an SMB share and it asks for
> credentials, though share is already opened in Dolphin.
> But VLC is not a very convenient music player.
> 
> Elisa is unable to open SMB files from Dolphin. Neither by drag-n-dropping
> nor by "open with".
> DEADBEEF, installed from snap store, is unable to play smb files too.
> Foobar200 installed using WINE also does not open SMB files.

I use SMPlayer for videos and QMMP for audio files. Both can play remote files on SMB shared folders without issues. Those SMB folders are in servers or local Windows PC inside a Windows domain (DC). Dolphin ask me for credentials each time I open any shared file for the very first time on a Linux desktop session.

My FUSE related libraries installed are:
S  | Name                | Summary                                                             | Type
---+---------------------+---------------------------------------------------------------------+--------
i+ | enblend-enfuse      | Tool for Composing Images                                           | paquete
i+ | fuse                | Reference implementation of the "Filesystem in Userspace"           | paquete
i+ | fuse-exfat          | exFAT file system implementation                                    | paquete
i+ | fuse3               | Reference implementation of the "Filesystem in Userspace"           | paquete
i+ | fuseiso             | FUSE module to mount CD-ROM images with ISO9660 filesystems in them | paquete
i+ | fusesmb             | SMB for FUSE                                                        | paquete
i+ | gvfs-fuse           | VFS functionality for GLib                                          | paquete
i+ | kio-fuse            | Access KIO over the regular filesystem                              | paquete
i+ | libfuse2            | Library of FUSE, the User space File System for GNU/Linux and BSD   | paquete
i+ | libfuse3-3          | Library of FUSE, the User space File System for GNU/Linux and BSD   | paquete
i+ | python38-defusedxml | XML bomb protection for Python stdlib modules                       | paquete

Is it intended that Konsole doesn't make use of kio-fuse? When dragging & dropping a video file from Dolphin in Konsole for "mpv x...", it's not picked up and thus fails accordingly, while it works when opening the video file in Dolphin (from where it was dragged).

We do that in Dolphin's embedded Konsole view, but it probably needs to be implemented for the Konsole app itself too. Feel free to file a bug report for Konsole about that.