Kubuntu - Mount SAMBA shares when Dolphin access them via CIFS

Bug #730984 reported by André Madureira
66
This bug affects 13 people
Affects Status Importance Assigned to Milestone
kubuntu-kde4-meta (Ubuntu)
Confirmed
Undecided
Balakrishnan

Bug Description

Binary package hint: kubuntu-desktop

Hello,

Problem:

When I access a SAMBA share via Dolphin, it don't mount it with CIFS file system automatically... This causes some programs not to open the remote files properly (and I can't understand why does this happen, because Windows programs can open remote files normally without the need of mapping the remote paths)...

Solution 1:

Make Linux programs access remote files without the need of CIFS mounting...

Solution 2:

Make KDE file managers automatically mount (via CIFS) remote paths when they're been accessed... Like Nautilus does with GNOME desktop (this happens inside the .gvfs path) ...

WORKAROUND:

Mount manually the remote paths that you wish Linux Programs to access files...
For that I used the command:

sudo mount.cifs //ip_to_samba_PC/root_folder /media/dir_where_to_mount_it_locally -o username=user,password=pass,iocharset=utf8

PS: In the username and password you can't have a special character like ´ or ^ or ~ because it shows the error message above that says that you're not logging in with the right username or password:

Permission Denied

Thanks for your help,

André M.

Revision history for this message
André Madureira (andreluizromano) wrote :

SOME PROGRAMS THAT CAN'T OPEN REMOTE FILES WITHOUT CIFS MOUNTING:

VLC, BrOffice (LibreOffice), GNOME MPlayer, and others

affects: kubuntu-meta (Ubuntu) → kubuntu-kde4-meta (Ubuntu)
Revision history for this message
Jonathan Riddell (jr) wrote :

I would consider this a problem in the relevant programme. Either they should support remote file systems (such as by using kio slaves) or their .desktop file should report that they do not support remote files in which case KDE will try and download the file first.

Changed in kubuntu-kde4-meta (Ubuntu):
status: New → Invalid
Revision history for this message
André Madureira (andreluizromano) wrote : Re: [Bug 730984] Re: Kubuntu - Mount SAMBA shares when Dolphin access them via CIFS

Hello Jonathan Riddell

Thanks for your answer, but I don't have any idea of how can I alert
them about these issues... Should I make a bug report for each program?

Thanks for your help,

André Madureira

Revision history for this message
André Madureira (andreluizromano) wrote :

Hello Jonathan Riddell,

I did a bug report on VLC (https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/737192) about KIO SLAVES support like you suggested ... I'll also do a bug report to Gnome Mplayer and LibreOffice about this problem...

Thanks for your help,

André M.

Revision history for this message
zigi (ziegleka) wrote :

2Jonathan

I think that this is not effective way to copy files to some local temp directory. KDE should ask to user if he wants to mount remote/network share to local directory, when the application doesn't support remote file systems.

Now if KDE downloads the file, the user makes than some changes in it, closes the application, what happens next? KDE uploads the changed file back to the remote/network share?

Does function the KDE's detection of the application's support of remote file systems correctly? In my case VLC can't use KIO slave smb, it always copy movie files from my server's samba share to local /var/tmp/ directory.

Changed in kubuntu-kde4-meta (Ubuntu):
status: Invalid → New
Revision history for this message
zigi (ziegleka) wrote :

And I think that this bug should not be invalid but space for discussion about use cases.

Revision history for this message
André Madureira (andreluizromano) wrote : Re: [Bug 730984] Kubuntu - Mount SAMBA shares when Dolphin access them via CIFS

I think like our fellow zigi... The user should have the option to mount
the remote path when the program that don't support SMB:// KIO SLAVES
functionality accesses it... It could be done either via that program or
via a file manager like Dolphin or Konqueror...

Another info that I received is that VLC can't support KIO SLAVES and
will never support it because it needs some specific HTTP protocol
access that don't work on KIO SLAVES...

André Madureira

Em 26-03-2011 07:22, zigi escreveu:
> And I think that this bug should not be invalid but space for discussion
> about use cases.
>

Revision history for this message
André Madureira (andreluizromano) wrote :

I did a bug report in the LIBREOFFICE package (https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/730264) and Gnome Mplayer (https://bugs.launchpad.net/ubuntu/+source/gnome-mplayer/+bug/737201) and Amarok (https://bugs.launchpad.net/ubuntu/+source/amarok/+bug/738262) because all of them don't support KIO SLAVES or (in the case of AMAROK) don't handle it as well as it should (AMAROK is a program done to work on KDE and therefore should at least support KIO SLAVES because it is a characteristic of KDE)...

I'm reporting these bug reports to the packages mentioned to make a join between the discussions about what is the best solution to this situation/problem...

Revision history for this message
Hazaar MVC (hazaar) wrote :

I'd like to add my thoughts on this as well as this effects me quite badly and increases my frustration.

Even with a stock KDE install I can navigate to a SMB share in Dolphin and click on a zip file only to have Dolphin download it first before opening it in Ark, which is the default archive manager in KDE. Some of these archives are >1GB so yeah, it takes a while.

Personally, I consider it monumentally unreasonable to present "get all other programs to support KIO" as a solution, especially considering KIO wasn't the best idea in the first place. But i'll leave the discussion of why for later. But since we have it, why not use the above suggestion of mounting the share instead of copying the file if KIO is not supported. Nautilus does this beautifully. Why can't Dolphin?

Basically my problem is, why should I go around to the 100,000+ other programs that run on Linux and ask them to support KIO when the problem can be fixed RIGHT HERE?

Changed in kubuntu-kde4-meta (Ubuntu):
status: New → Confirmed
Revision history for this message
Jens (jens-launchpad-net) wrote :

I second this. I just switched from Ubuntu to Kubuntu because Nautilus lacks some major features, but Dolphin lacks the *one* feature I use hundreds of times daily, and this is directly accessing large files on SMB servers.

PLEASE make mounting an option for KIO smb slaves. Thank you.

Balakrishnan (gbalan-me)
Changed in kubuntu-kde4-meta (Ubuntu):
assignee: nobody → Balakrishnan (gbalan-me)
Revision history for this message
Jim Buddin (jimbuddin) wrote :

+10,000 Glad to see someone is finally working on this! Go Balakrishan. Would love to be able to use KDE on my work laptop without permanently adding fstab entries which won't mount at home. At work we have a network samba share, IPv6 only (no idea of the IP address), accessed via smb:// address. We NEED to open network files and work on them in LibreOffice just like you can in Windows, Mac and other distros, this is a showstopper for roll-out of Kubuntu.

Revision history for this message
Jens (jens-launchpad-net) wrote :

Another use case for mounting SMB shares: Use any non-kio-slave-supporting app (e.g. VLC) to view a large (e.g. 3GB) video file.

In this case it is absolutely insane to download the whole file first (which can take several minutes, even on a GBit network), occupy gigabytes of temporary space locally (which might not be available) and only then start the video. The video should be opened right from the network location.

Revision history for this message
Venca B Spam (vbspam) wrote :

Let me share some thoughts about this topic.

@#9 Jamie Carl (jazz-funkynerd)

KDE use KIO-Slaves to access other then local protocol and/or meta-protocols across all platforms. It is monumentally clever idea. However it is not new idea. Microsoft uses the same technique. Just call it UNC or so. Remember \\SERVER\SHARENAME ..

Looking to the Windows world, the application wanting to use network share has two choices. Use the UNC API of Windows or use traditional DOS API accessing filesystem (yes, the C:\DIRECTORY\TRACK02.mp3 ..). Of course the use has to "map network drive" (linux users should read: "mount cifs share").

@#11 Jim Buddin (jimbuddin):
So now those who argued KDE should do it instead of 10000+ apps should bother with KIO-Slaves. Rethink that idea.. . Libre/Open Office while running Windows also use \\ to access network shares..

Of course, there is another proposed solution: "Give user the choice!" Mount or use KIO-Slave...

But, as there is almost always "but". Have you worked with KDE using mounted CIFS shares when the network disconects... . In most cases (at least in my most cases) the whole KDE hangs and waits for timeouts. Yes there must be something monumentally wrong in it, but as this is with us for years, I believe it is hard to solve it. And back to the idea of user choice mount or kio-slave. This is not hard task. It could be done by script and/or KDE services, doesn't it?

Revision history for this message
Venca B Spam (vbspam) wrote :

Anyway I feel the frustration too. At these days I discovered that VLC (originally platform independed) music player supports smb:// access better then Amarok (originally aimed to be the gratest KDE media/music player). And more then this, they believe (at least "Matěj Laitl" https://bugs.kde.org/show_bug.cgi?id=273881) that the poor support for KIO-Slaves (smb:// ..) is good by design for the main KDE media player.. See the irony. This kind of bug sleeps in the KDE bug tracking system for ages..

Revision history for this message
Julian Kalinowski (julakali) wrote :

I think this is one of the few show stoppers for using KDE as desktop for the unexperienced user.
Gnome handles SMB / ssh / ftp / ... so nicely and transparent for applications, while in KDE every single application has to support the protocol.

For experienced users, the cifs-mount-workaround is not a problem, but for the avarage user, he just doesn't understand why it is such a problem to use VLC, libreoffice and even KDE applications such as Dragon Player (doesn't handle smb) with files on the network.
As NAS Storage is common, this should be fixed and I'm thankful for everyone working on it.

Revision history for this message
Jens (jens-launchpad-net) wrote :

So, *is* anybody working on it right now? Is KDE finally able to transparently mount SMB (or FTP or whatever) file systems so *all* apps can transparently access them? I just tried a fresh Kubuntu 15.10 install, no modifications at all except I added VLC. I tried to play back a 4GB MP4 video I have on our NAS drive. This is the situation:

Dragon player (the default in KDE5) starts *downloading* the file before it can play it. Not acceptable!

VLC (which I added) refuses to play the file in the first place, claiming it cannot access "smb:/user@workstation/whatever/file.mp4". Not acceptable!

KDE5 is really a nice desktop, but with defaults such as these it is absolutely impossible to give this to a new user and make them happy with it. Especially because other desktops don't seem to have this problem. I switched a few PCs back to LXDE and/or Unity (ubuntu) for this single reason.

Revision history for this message
Jens (jens-launchpad-net) wrote :

So I just found out about "vlc-plugin-samba" which apparently allows you to enter credentials for *one* SMB server inside VLCs settings. When I do this, playback works for our NAS, but (of course) not for any other SMB server like my wife's Linux machine which also has shared folders.

So a workaround would be to get VLC to access the (saved) passwords of SMB servers that Dolphin (or any other file manager) save. Right? VLC only needs read access to those passwords, after all. It can handle smb:// URLs fine, it just can't get the authentication information - which already exists.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.