I can't open the videos, I have to fill in the password in the URL in terminal by myself. ex: user@user-PC:~>mpv 'smb://user@192.168.1.xxx/影片/movie.mkv' It has to be like this: ex: user@user-PC:~>mpv 'smb://user:password@192.168.1.xxx/影片/movie.mkv' I can't do it in the dolphin file manager, it needs to be done in terminal. Reproducible: Always Steps to Reproduce: 1.Open the path of my samba sharing directory 2.Open the video. 3.nothing Actual Results: FAIL!!
Are you still able to reproduce the issue? I am able to get this working in Kubuntu 17.04 with Plasma 5.9.5 by doing the following: 1. Get another Kubuntu 17.04 machine on the same network, use it to create a Samba share, and put a movie file in it (mine was a .mov) 2. Connect to that machine from your machine via Dolphin > Network 3. Navigate to the movie file on the share 4. Open it in VLC via [right-click] -> Open With -> [select VLC] For me, this works fine. Does anybody have a reproducible set of steps that make it fail?
So this seems to work in Dolphin right now when the share is on a Linux PC, but fails when the share is on a Windows PC. As Lai Chiaheng has observed, Windows Samba seems to require the password to be specified in the URL. From my time in Mac land, I seem to remember Finder saying, "Are you sure you want to enable Windows Samba sharing? That requires storing Samba passwords in an insecure way!" So maybe this is just a poor Samba implementation in Windows that we need to handle.
I asked our resident Samba expert and he says that the problem here is that MPV and VLC aren't KIO-aware, which would allow this to just work. Instead, the SMB KIOSlave falls back to blindly passing them the path to the file, which fails because right now that path doesn't include the password. It seems somewhat unlikely that we'll get VLC or MPV to link against KIO--let alone the entire universe of other non-KDE software--so we're probably going to have to do something yucky like just add the password into the path and live with diminished security in exchange for making this work, unless we can think of a clever workaround that doesn't ruin performance.
So there is another option I hadn't considered, which is to have KIO use FUSE to mount these remote URLs locally, which exposes them to software that doesn't use KIO but is otherwise POSIX-compliant. This is what GNOME's GVFS does, which is why they don't have the same problem (though FUSE mounting does impose a performance penalty, but I suppose that's better than not having the functionality at all with popular apps like VLC). It looks like there was an effort to implement that a few years back: https://techbase.kde.org/Projects/KioFuse Sadly it appears to have been abandoned. I wonder if it's revivable.
Another option: replace the %U in VLC's desktop file with %F, which forces the system to download the file locally to a temp directory before passing it to the app. This does work (hurrah!) but you do need to wait a bit for the file to download and there's no feedback while that happens, which isn't the best user experience when the network connection is slow. This change would need to be made at the distro level, which wouldn't make sense for distros that also ship GNOME, since GNOME's GVFS is able to do this transparently, as mentioned above.
*** Bug 342272 has been marked as a duplicate of this bug. ***
Marking as a duplicate to consolidate info in one bug report. *** This bug has been marked as a duplicate of bug 330192 ***
*** This bug has been marked as a duplicate of bug 75324 ***