Bug 330192 - Unable to open video files in common players (VLC, MPV, etc) over smb://
Summary: Unable to open video files in common players (VLC, MPV, etc) over smb://
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.40.0
Platform: Ubuntu Linux
: NOR major
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2014-01-20 10:46 UTC by Mathieu Roy
Modified: 2020-01-02 18:29 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.66


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Roy 2014-01-20 10:46:28 UTC
Hello,

I noticed numerous bugs reports that looks related to this, bug none clearly match this.

Say I have a samba server. This samba server  is accessed by username+password. It contains different types of file.

Say I have a client. This client connect succesfully to the samba server via dolphin. It can browse the whole tree and open every and each file (text, ogg music, mp3, pdf, etc) , except video files (whatever the container mp4, m4v, avi, ogg, etc). In this case, it says it fails to open the smb://, itself containing the proper SMBUSER@SMBSERVER string.

In the samba logs, each try to open a video ends up with
[2014/01/20 11:10:38.904995,  0] smbd/service.c:995(make_connection_snum)
  Can't become connected user!

It gets funnier when, with vlc, I set in prefs a SMB user/password. Then VLC suddenly is able to open the video files when selected with dolphin Open With.

(Let also mention that if I use a win7 client to this same share, smplayer succesfully open any video.)

So it looks like Dolphin is failing to pass to video players ( DragonPlayer, smplayer, vlc, etc) proper access to the video files, specifically the password. I understand there could be a security issue to pass such data  in the command line; but how is it done for any other file? Are they opened as a tempfile? How the windows7 implementation does that?


Reproducible: Always

Steps to Reproduce:
1. start dolphin
2. go on a smb:// share
3. click on any video file
Actual Results:  
Failed to open smb://CORRECTUSER@CORRECTSERVER/Extra/videos/Animation/FILE.mp4.

Expected Results:  
Just opening the same url, with the password.
Comment 1 Frank Reininghaus 2014-01-20 11:28:58 UTC
Thanks for the bug report. I can't say much about this issue because I have zero smb knowledge.

We can reassign the bug to kio/smb, but you have to provide the Dolphin/KDE SC version. Please NEVER file bugs without specifying the version. Thanks.
Comment 2 Mathieu Roy 2014-01-20 13:08:08 UTC
The field does not provide the appropriate version. It's dolphin 2.1 as provided by the current normal (non-lts) ubuntu release.
Comment 3 Frank Reininghaus 2014-01-20 15:31:27 UTC
Thanks for the quick reply.
Comment 4 Nate Graham 2017-10-28 15:13:55 UTC
*** Bug 342272 has been marked as a duplicate of this bug. ***
Comment 5 Nate Graham 2017-10-28 15:14:39 UTC
*** Bug 355328 has been marked as a duplicate of this bug. ***
Comment 6 Nate Graham 2017-10-28 15:24:52 UTC
Migrating explanation from duped bugs:

This is essentially a flaw in the way KIO was designed. Rather than mounting Samba shares and exposing POSIX-compliant paths to information on the share, KIO itself provides transparent access to KIO clients. Unfortunately, this requires that any software run in KDE Plasma that wishes to access files on a Samba share needs to use KIO. VLC et al. don't, and likely never will. In this situation, KIO simply passes the program a URL in the form smb://user@share/path/to/file.avi

This leaves a few not-great options:

1. Every non-KIO-using program implements a Samba client and learns how to look up the share's credentials from KWallet. Cons: lots of duplicated work across video player software

2. KIO recognizes this situation and always downloads the file locally and passes the program a local path. Cons: long delay before playback starts, high local temp storage requirements

3. KIO is modified to mount Samba shares locally using FUSE. Cons: huge amount of work, will likely never be implemented.


I am attempting to work with the VLC people to get #1 implemented for their software. The upcoming version 3.0.0 purports to implement support, but it's currently buggy:
- https://trac.videolan.org/vlc/ticket/18993
- https://trac.videolan.org/vlc/ticket/18991
Comment 7 Nate Graham 2017-10-28 15:26:24 UTC
*** Bug 342646 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2017-10-28 17:09:27 UTC
*** Bug 189695 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2017-10-28 17:19:26 UTC
*** Bug 215283 has been marked as a duplicate of this bug. ***
Comment 10 Nate Graham 2017-12-11 20:12:32 UTC
The above VLC tickets are now resolved in VLC 3.0 (unreleased as of this writing). 

We now have a workaround for folks needing to access videos on Samba shares from within a KDE Plasma environment: use VLC 3.0. Potentially unstable nightly builds of VLC 3.0 can be found at https://nightlies.videolan.org/ until the formal release of VLC 3.0.
Comment 11 David Edmundson 2018-01-30 19:27:36 UTC
3. KIO is modified to mount Samba shares locally using FUSE. Cons: huge amount of work, will likely never be implemented.

You're missing the bigger con, you'll completely freeze an app if the network goes down with no hope of a solution. 

For the specific VLC case that'd super suck as VLC has native samba support (sometimes packaged separately), so you'd be throwing that away to use FUSE. 

If you ignore the problem of passwords, it isn't that VLC needs KIO support, it's that we overall need a unified URL schema for protocols.
Comment 12 Nate Graham 2018-01-30 19:45:02 UTC
How does GNOME handle this? Do apps using files on Samba shares accessed using GVFs just freeze forever?


The larger issue is that not all software will use KIO for access, and it isn't reasonable to expect them all to. Samba shares are really common in businesses and schools, and people quite reasonably expect full file access support when using non-KDE software like LibreOffice and Blender.

As far as I can tell, there are really two primary use cases here:

1. Reading/streaming large files on Samba shares (e.g. videos)

2. Editing and saving back to files on Samba shares using non-KIO software like LibreOffice and Blender


The pain point for #1 is that unless every piece of software you'd want to use for this use case implements a Samba client, you'll get stuck with KIO downloading the file locally first, which is associated with many problems for large files (lengthy download time with no progress bar, local space issues, etc). This limits user choice. E.g I've helped solve the problem for VLC users, but what about those who prefer MPV? If you want to edit huge video files stored on a Samba share, we offer Kdenlive, which is KIO-aware, but but if you prefer Pitivi, which isn't?

The pain point for #2 is that for non-KIO apps that use %F in their desktop files, KIO will locally download the file and pass them a local path, BUT, once the app saves the file, KIO doesn't re-upload it back to the share until the program quits. This causes a lot of user confusion and pain. I've seen quite a few bug reports about this behavior causing out-of-sync versions when people save the file and don't realize that it only gets re-uploaded once they quit, and then a co-worker, fellow student, or teacher looks at the file and says "hey, it doesn't have any of the changes you said you made!"

#2 seems like we could maybe implement a tactical fix in KIO to save the file back to the share before the program quits, but #1 I think is a tougher nut to crack without implementing a local mount.

What are your thoughts, David?
Comment 13 David Edmundson 2018-01-30 21:30:39 UTC
As I understand it (and I'm obviously not a gnome dev, so please double check they've had a few itterations) Gnome apps do not use fuse. 

Gnome apps use something that's effectively identical to KIO. For the same reasons that we use KIO. 
However their daemon also a Fuse mount that talks to the daemon. Non gnome apps use the Fuse mount.

Picture explains best:
https://developer.gnome.org/gio/stable/gvfs-overview.png

There'd need some fancy magic I don't know how to do to match up the URLs, and I'm not sure how their daemon would know when to disconnect. Maybe they make users do it in the file browser UI?
Comment 14 Nate Graham 2018-01-30 21:53:54 UTC
Thanks for engaging with me on this, David. Much appreciated.

As far as I know, GNOME users are expected to first mount the remote location using Nautilus, yes. It's also possible that the mounts can automount in response to filesystem events that request a path that was previously on one of the FUSE mounts. That's just speculation though (but it sounds cool and useful, and I know that macOS does this).

Essentially the key difference is that GIO provides a FUSE mount for non-GNOME apps, which allows all POSIX-compatible apps to access network locations normally. KIO provides this support without a FUSE mount and instead just downloads the remote files locally to a temp location and then re-uploads them after the app quits, which is associated with the drawbacks mentioned in this bug and all the duplicates.

I'm not advocating that we use FUSE for everything, but rather proposing that we do the same thing as GIO and make a "KVFs" that provides similarly transparent access to non-KIO-aware POSIX apps so our users don't have to choose non-KDE apps that have Samba clients or understand the implementation details of how files get read, stored, and saved back to the remote location.
Comment 15 Christoph Feck 2018-01-31 05:56:14 UTC
See bug 75324.
Comment 16 Nate Graham 2018-01-31 17:19:52 UTC
Ah, perfect. Let's continue there and I'll dupe everything to that.

*** This bug has been marked as a duplicate of bug 75324 ***
Comment 17 a.saoutkin 2020-01-02 18:29:48 UTC
Git commit fcf4529f62e15cfc891757cf372c4ef7ee7ea4d1 by Alexander Saoutkin.
Committed on 02/01/2020 at 18:29.
Pushed by asaoutkin into branch 'master'.

Adding support for mounting KIOFuse URLs for applications that don't use KIO

Summary:
This patch is required to provide seamless integration with KIOFuse and KIO.

The patch attempts to convert URLs that applications will not understand
natively into local paths based on a KIOFuse mount. If successful, the URL
passed to the application is changed to its location within the KIOFuse mount.
If it is not successful, the URL is not changed.

If KIOFuse is not installed, then kioexec is simply used.
Related: bug 75324, bug 398216, bug 398446
FIXED-IN: 5.66

Test Plan:
Compile KIO with this patch.

Build and install KIOFuse (follow instructions in README): https://invent.kde.org/kde/kio-fuse

Once KIO is built, Dolphin is built with this newly built KIO, and kio-fuse is built,
one should start the kio-fuse process.

The easiest way to test this is via Dolphin (that is built with this patch): `dbus-launch dolphin`.

Once you have done the above one can simply browse to any non-local location in
say, Dolphin, where upon opening a URL in a non-KIO enabled app, it should open
in the KIOFuse mount, except for MTP/Gdrive URLs - those will use KIOExec.
Conversely, KIO URLs in KIO-enabled apps should not use KIOFuse.

Reviewers: fvogt, davidedmundson, dfaure, ngraham

Reviewed By: dfaure, ngraham

Subscribers: alexde, broulik, sitter, davidedmundson, kde-frameworks-devel, ngraham

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D23384

M  +1    -0    src/core/CMakeLists.txt
M  +45   -12   src/core/desktopexecparser.cpp
A  +9    -0    src/core/org.kde.KIOFuse.VFS.xml

https://commits.kde.org/kio/fcf4529f62e15cfc891757cf372c4ef7ee7ea4d1