1

Hello everyone,

I have already install openSUSE 13.1 KDE on my computer.
I have also an ubntu server 12.04 with samba to share some files and most of them are pdf, odt, doc etc.

I can open pdf files, also i can copy/move/create/remove files to my server
but i can’t open files with libreoffice (.odt or .doc etc.)

I have also try to open first local libreoffice and then file->open->“server path”->file.odt
and I took that message “You can only select local files”

any suggestions?

2

Problem solved!

I have to do some chages
** /usr/share/applications/writer.desktop**

change the line
Exec=libreoffice --writer %U => Exec=libreoffice --writer %F

But this is only for writer,
if you want to open calc, impress or something else with libreoffice then you have to change
calc.desktop
impress.desktop etc

3

Hello

On first place, thank you for sharing!!

There are some problems with this workaround:

  1. As you mentioned, user must do that change on every LibreOffice “.desktop” file
  2. Documents opened in this way, are not locked on server. Instead, KDE make a copy of file (imagine a large size file) and then copy changes to server when you EXIT from the application (not when you SAVE the file/document).

I found another trick to solve the problem, and not require to edit files: Just install “libreoffice-gnome” from Yast. That’s all. Indeed, the problem is KDE (kio-slaves) related with GTK based applications (LibreOffice, Firefox, Audaciuos, etc). GNome desktop use a trick, using gvfs to temporaly mount locally samba shared files. This is a problem long time unsolved by KDE, and I bet they are not interested in solve it .

4

That change only helps when you open a file from the filemanager.
It does not change anything when opening files inside LO.

Documents opened in this way, are not locked on server. Instead, KDE make a copy of file (imagine a large size file) and then copy changes to server when you EXIT from the application (not when you SAVE the file/document).

Yes, because that’s exactly what that change in the .desktop file tells KDE to do (%F only supports local files, so KDE downloads the file if it is not local and re-uploads the changed file when the application exits).
From the desktop file specifications: (Recognized desktop entry keys)

If files are not on the local file system (i.e. are on HTTP or FTP locations), the files will be copied to the local file system and %f will be expanded to point at the temporary file. Used for programs that do not understand the URL syntax.

I found another trick to solve the problem, and not require to edit files: Just install “libreoffice-gnome” from Yast. That’s all.

No, that’s not all.
Installing libreoffice-gnome alone will not make libreoffice use it inside KDE, it will still use libreoffice-kde4 then.
Either install ibus as well (apparently libreoffice-kde4 has problems in combination with ibus, so if ibus is installed libreoffice-gnome is forced even if you run LO in KDE), or uninstall libreoffice-kde4.
Or set the environment variable OOO_FORCE_DESKTOP=“gnome”.

Indeed, the problem is KDE (kio-slaves) related with GTK based applications (LibreOffice, Firefox, Audaciuos, etc). GNome desktop use a trick, using gvfs to temporaly mount locally samba shared files. This is a problem long time unsolved by KDE, and I bet they are not interested in solve it .

It’s not a KDE problem, as KDE applications work fine. So why should KDE “solve” it?
The problem is that GTK applications do not support using KIO-slaves, because they are GTK applications.

Why should the KDE desktop mount the share as workaround? What about other protocols than smb (KIO-slaves support many more)? And mounting them might not even be possible.
In KDE KIO-slaves exist exactly for this, using remote files as if they were local.

In Libreoffice this should done by the KDE integration anyway (libreoffice-kde4), so maybe that’s a bug/limitation there.

PS: I can open remote files from Samba shares just fine here on 13.2 in LibreOffice 4.3.5.2 using the KDE4 integration (without changing any .desktop file). I just tried. It works fine when I open a remote file in Dolphin, and when I select File->Open in LO and browse to a network share. Saving works fine as well, and has immediate effect on the remote file on the share.

5

I was hesitant to bump this thread, but given it’s still a relevant problem… here goes.

This is actually a bug stemming back several years. This functionality used to be present in KDE, but ever since this issue surfaced, there’s been limited/seemingly no desire to provide an actual fix.

We all know gvfs mounts network resources into a local location. Truth be told, this actually makes sense, as it’s a singular way for all applications to interact with the data on the network share in the same demeanor. This requires no fancy support from applications, such as the .desktop edits that were being discussed further up in this post.

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

I have replied several times in that bug report with my own findings, as I experimented quite heavily to see what worked and what didn’t. As you can see, there are applications in the default KDE environment that are having issues, such as Dragon Player. I am unsure if this is an actual “official KDE” application, but honestly, I don’t see how that matters given it’s selected as the default on many (all?) distributions. Perhaps this is a fault of the distribution for choosing it? I’m not sure. No matter how you slice it, a local mount point would allow any and all applications to seemingly fly.

I hate to be blunt, because I actually really like KDE/Plasma, but this kind of behavior lacking, unfortunately, acts as a testament to the KDE experience. A lot of people have home servers now. I have set up a multitude of Synology boxes for people as the popularity amongst your “average” user having their own centralized file server has grown. Couple that with the countless users out there spinning up their own DIY file server, OpenMediaVault, FreeNAS, etc., and the number goes up. There’s great software here, absolutely excellent software, but if the seemingly common task of accessing it on a network share acts as a show stopper, it’s quite a black mark. Sorry – I don’t mean to come across as a self righteous open source user, but user perception is still user perception.

What I’m most curious about is if anybody knows what the consequence is for removing KIO and utilizing some sort of other methodology to mount samba shares in a quick, easy, and intuitive manner (and I’m not referencing something like smb4k, but within the file manager itself, since it does after all have a “Network” section that goes into your domain/workgroup and further down to the shares). I’ve considered fstab but with mobile devices on the go (laptops, etc), this simply isn’t a viable alternative.

Alexandro - I’m curious what your experience has been after your initial post here. You make a reference that LibreOffice applications with some tweaks work better, however have you tried doing other tasks such as streaming media from a samba share by clicking on a video file? Or a music file?

6

First of all, I don’t really see a point in discussing this here, as it won’t change anything.
If at all, this should be discussed with KDE’s developers.

But some remarks:
KIO is about more than just opening files on a Samba share.
It supports many other locations, which cannot be mounted really.
So, removing it would loose a lot of functionality, not available otherwise.

And KIO is not just about opening files anyway.
It is a fundamental part of KDE.
It also offers functions to copy/move files, it contains the file open/save dialog (which also allows opening all locations KIO supports via its slaves/plugins), and the file properties dialog e.g.
E.g. Konqueror and KMail use KIO and its slaves to display web sites, download or send EMails, and so on.
Getting rid of KIO would mean a rewrite of core parts of KDE, and also hundreds of applications.

KIO does support non-KDE applications. Actually it’s rather opt-in:
An application has to specify that it supports KIO in its .desktop file. If it doesn’t, KIO downloads the file to a temporary location and re-uploads it again when the application quits. So it should be rather transparent to the application.
Also, even a non-KDE application can specify which protocols it supports (e.g. smb://) in its .desktop file (i.e. the menu entry and file association). KIO won’t download the file then, but just pass the URL to the application.

Dolphin probably could mount a samba share when accessing it (or before opening a file), but that would rather be a workaround that would only help when clicking on a file in the file manager of course, not with other KDE applications.

And yes, dragonplayer is an “official” part of KDE (Applications).
It does support/use KIO, and should also be able to open (“stream”) files on network/Samba shares (via KIO).

Also, opening files on Samba-Shares with LibreOffice always worked fine here and still does.
Its .desktop files do specify that it supports the file, http, smb, ftp, and webdav protocols, so those should be just passed to LO and be opened by LO directly without KIO being involved.
At least that’s the case with openSUSE’s libreoffice packages, no idea about the ones from libreoffice.org.

7

Truth be told, it was reported to the KDE developers, but if you compare some date/time stamps, we’re nearly six years past the initial point of contact. I’m more interested in what kind of workarounds there may be that I’m not aware of. The desktop file is an interesting one, though it didn’t seem to help in all cases. Dragon Player, despite being an official KDE application, would not stream over samba on multiple distributions (openSUSE, Manjaro, Kubuntu come to mind). I heard some reports that altering VLC’s desktop files would help, though in my case it proved to be somewhat inconsistent. I had better luck adding the samba credentials into the VLC >> preferences >> advanced >> smb module field. Dragon, however, I never got to fly.

In regard to Libre Office, I’ve always used the LO packages that come bundled with the distribution. My most recent tinkering was with Manjaro KDE, which was kind of a flop with editing LO documents on a network share. This makes me wonder (and likely suspect) that openSUSE has some degree of additional packages included that make this scenario simply work better. I do not recall using LO on openSUSE KDE, but rather just focused on the video streaming over smb/LAN which didn’t pan out.

Thanks for the information about KIO. I understand better what exactly it does in the background now. I just feel a local mount point solution is a bit more straight forward. I mean, that’s what happens when you mount manually in terminal, so it mounting in a similar fashion via the interface fits. That would remove the necessity behind tailoring all of your .desktop files of applications just to gain what I feel is common functionality.

I’ll keep tinkering with it. I keep a KDE install around to check out the latest plasma developments. I just saw this thread as I was digging around for an alternative workaround and felt compelled to respond.

Cheers.

8

I know, you posted a link.

but if you compare some date/time stamps, we’re nearly six years past the initial point of contact.

So apparently they have no intention to change that, and I can understand it.
But discussing it here will have even less effect then. :wink:

Dragon Player, despite being an official KDE application, would not stream over samba on multiple distributions (openSUSE, Manjaro, Kubuntu come to mind).

Yeah, right.
The corresponding line is apparently missing in dragonplayer’s .desktop file.

TBH, I don’t use Dragonplayer and never really used it.
With Kaffeine (another KDE media player, and installed as default media player upto 13.2) this works fine though.

I heard some reports that altering VLC’s desktop files would help, though in my case it proved to be somewhat inconsistent.

openSUSE’s VLC .desktop file does specify that VLC supports smb://, no change needed.
It actually contains this line already:

X-KDE-Protocols=ftp,http,https,mms,rtmp,rtsp,sftp,smb

I had better luck adding the samba credentials into the VLC >> preferences >> advanced >> smb module field.

That’s unrelated.
It doesn’t change the way dolphin (or KIO) opens VLC.

As VLC does support smb:// natively (and doesn’t use KIO, KIO/dolphin just pass the URL), you need to specify the credentials to VLC though, yes.

Thanks for the information about KIO. I understand better what exactly it does in the background now. I just feel a local mount point solution is a bit more straight forward. I mean, that’s what happens when you mount manually in terminal, so it mounting in a similar fashion via the interface fits.

It’s more straight-forward for (non-KDE) applications that only support normal files, yes, but would only work for SMB (and some few selected other protocols maybe).

But KDE does have its KIO anyway (since years, at least KDE3, maybe even earlier), which is much more flexible (it supports plugins for new “protocols”, the kio-slaves), and is being used by all KDE applications.