Ever since the update VLC doesn’t play videos saying MRL error.
What are you trying to play?
A local file or something directly from the internet?
MP4 files from Windows 10 shared folder.
I suspect the issue is that you were using kio-fuse to get this to work before, and that program hasn’t been ported to KF6 yet, so it isn’t loading as a plugin or something.
Try to move the file to somewhere, like your ~/home and see if it works.
It might have to do with how the SMB is mounted.
I found quite a lot doing a google search for “linux MRL error VLC”
Edit
Ahh, I was a bit “slow”, above identified the problem as with the mount.
So it’s just a question of time?
Yes, or I suspect you can mount it without using kio-fuse, like making a systemd.mount, or maybe even just make the mount in fstab instead and remove the mounting in dolphin (I suspect you mount it in dolphin).
Unfortunately I’m quite newbie with linux so I don’t know what most of those things mean, and I had this issue with several other distributions and the main reason I picked Neon was that it didn’t have such problems, until now. So I’m bummed. And yeah, I’m trying to launch VLC through Dolphin.
I meant I suspect you connect to your windows SMB server in dolphin (that is where the kio-fuse mount is made).
Do an internet search for “mount SMB in fstab”, you might be able to fix it that way.
What that means is the SMB will be mounted at boot so when you open dophin the mount is already there.
Another solution would be to just wait until it is fixed with kio-fuse.
Thanks, I mounted the shared folder based on this article:
https://linuxconfig.org/how-to-mount-a-samba-shared-directory-at-boot
And now it works.
2 Likes
God job!
As long as you figured out how to use the correct package manager, pacman on arch based, and apt on debian based, etc. for the cifs-utils package you are golden.
I would have the stuff in MY home rather than in the /root home (and owned by you rather than root), but that is just a matter of preference.
I also do not understand why he recomends 550 (user & group: read/execute) to the smbcredentials file, it should be 400 (user: read), or arguably 600 (user: read/write).
I would also make it hidden by adding a “.”, ie: .smbcredentials
If you want to get fancy, you can add following to your options on the mount in your fstab:
_netdev,cache=loose,credentials=/home/USERNAME/.smbcredentials,nofail,noatime,uid=USERNAME,gid=USERGROUP,dir_mode=0755,file_mode=0644
Where USERNAME and USERGROUP is your id and group (either number or name, does not matter).
I also assumed you adopted the .smbcredentials method above or the path might have to be to /root instead of /home.
Good luck!
1 Like
Your proposal works, but for users like me who access different computers with shared folders with SAMBA (mainly Windows) it would be crazy. Also, there is an additional problem when the remote computer where the SMB folder is located is turned off and you have the boot mount … when you reboot or try to access that folder that does not exist, the boot time can take forever.
There is an alternative by mounting as a service such remote folders that avoids such problems, using “systemd”, but I haven’t actually used it.
What would be crazy?
The security for SMB should be on SMB, not the mount, if it is root vs. user you mean.
Not if you include the option nofail like in the line I suggested.
If you do not, yes, it can take a very long time to boot with a mount not accessible.
Not really any bigger difference, it doesn’t “avoid” anything, it’s just the method of mounting, the mount itself would look the same to linux once it is done.
But you DO get access to some other fancy stuff like automount and journalctl LOGS 
with systemd.
1 Like
The security will be the one implemented on each computer that shares its folders with Samba, no more, no less. In my case, I am in a Windows domain and it requires me to authenticate when accessing shared folders with Samba.
Mounting with “fstab” or with “systemd” does make a big difference. If the SMB folder mount fails to mount with fstab (with or without the “nofail” option), the user will have to launch “mount -a” to find out if the connection is active or not. However, “systemd” can take care of the mount retry task without the need to complicate the task for a user who just wants to use Dolphin.
With either option, you are complicating access to remote folders for Dolphin users. If everything works as it does so far, ideally you should not need to mount anything, but access it directly with the remote URL.
Yeah, I clearly “complicated it” by solving it for op, says the guy that did not know about nofail or ever used systemd mount or automount units.
Thanks buddy! 
Of course, I’m not criticising your support, don’t get it that way. I just want to make the user aware of the additional problems they may encounter on a case-by-case basis. If the user only accesses a couple of shared folders on computers that are usually connected, your solution is ideal. I raise other possible scenarios for anyone who wants to use this temporary solution. 
2 Likes
And what “problems” is that? Lack of knowledge?
Using fstab or systemd to mount is an extremely safe and well tested method of mounting for MANY years. Pretty much how you do mounts on linux.
That is not a problem at all, if you use the nofial tag, EVER.
If your argument is “this is not the greatest solution if I use a laptop, walking around connecting to different networks and connect to different SMB servers on those networks”, yes, maybe in that situation it could save you a minute or two.
But the instance you have mounted these SMB shares more than once, the solutions I provided immediately becomes a very solid solution and faster than having to fill in ip adress, username and password in dolphin each time.
What I am saying is, if you set up mounts with fstab or systemd, you will not have trouble accessing them in dolphin while using kiofuse, I have lost count how many times I have seen errors like op have in the past year or so on different forums.
Ideally using Dolphin/kiofuse to mount should not be a problem, but as it stands, it seems to be wonky to say the least.
Could you elaborate on that? It seems to me that the port is ready but is being held back because it’s claimed to be already KF6-compatible.
1 Like
Any update on this problem please ?
I just switched form Kubuntu where vlc playback of files from my unRAID SMB shares via Dolphin worked fine, but now mostly fail on KDE Neon.
Mounting the filesystem via fstab resolves the issue.
ps. vlc logs report a broken pipe when it fails, eg:
kv debug: | | | + Track Lacing=0
mkv debug: | | | + Track CodecId=S_HDMV/PGS
mkv debug: | | | + Track Language=`spa'
mkv debug: | | | + Track Name=Trivia
smb debug: seeking to 75
mkv debug: | - cues at 16345678355
smb debug: seeking to 16345678355
mkv debug: | + Cues
prefetch debug: end of stream
mkv debug: | - loading cues done.
smb debug: seeking to 93
smb error: read failed (Broken pipe)
Check, if there’s a package for vlc with the smb plug-in, on Fedora I had to install vlc-plugin-smb to make it work.
I think the cause of the problem is a bad .desktop file. /usr/share/applications/vlc.desktop and other .desktop files for media players contain smb on the list of X-KDE-Protocols. This used to work, because ffmpeg provided support for the smb protocol, but this feature was removed. If you remove smb from this list, Dolphin will use kio-fuse to mount the share on demand and will pass the “mounted” path to vlc.
There was a more elegant solution for editing the files. I simply copied the defective ones from /usr/local/share/applications to ~/.local/share/applications/, but it stopped working, and for some reason KDE favors the one in /usr/local/share/applications/.