[LibreOffice] - Use of KIO SLAVES instead of CIFS to access remote files (located in the Network)

Bug #730264 reported by André Madureira on 2011-03-06
92
This bug affects 17 people
Affects Status Importance Assigned to Milestone
libreoffice (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: libreoffice

Hello,

Problem:

When I try to open a file located in another PC (via Network - being more specific, via SAMBA) with LibreOffice 3.3.1 (in my case, BrOffice 3.3.1), it says that it can't open a remote file, so I'm obligated to copy the file to my PC to be able to open it...

Solution:

Implement an opening procedure that is capable of lock the file via network and with it, enable the opening of remote files (files located in another PC via Network - SAMBA or NFS)...

Workaround:

Copy the remote file to your local PC and, after saving the modifications done by LibreOffice in this local file, move it to the PC that it came from, replacing the file...

PS: I tried opening this remote file in a PC which I have permissions to read/write as ADMINISTRATOR...

MORE INFO ABOUT MY SYSTEM:

KUBUNTU 10.10; KDE 4.5.1; LINUX KERNEL 2.6.35-27-GENERIC-PAE; LIBREOFFICE 3.3.1 (BrOffice 3.3.1); Samba Updated; OS of the PC where the remote file is: Windows 7 Ultimate 32bit with proper permissions to allow read/write acess to the path via Network; NVIDIA GEFORCE 9600 GT; INTEL QUAD CORE 2.66; INTEL MOTHERBOARD DG35EC; 4GB RAM DDR2 667 MHZ

PS²: I'd send the apport info to you, but it says that the package (libreoffice) is not Ubuntu Original, avoiding me from sending more data to you...

Thanks for your help,

André M.
---
Architecture: i386
DistroRelease: Ubuntu 11.04
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
NonfreeKernelModules: nvidia
Package: libreoffice 1:3.3.2-1ubuntu5
PackageArchitecture: i386
ProcEnviron:
 LANGUAGE=pt_BR
 PATH=(custom, no user)
 LANG=pt_BR.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic-pae 2.6.38.2
Tags: natty
Uname: Linux 2.6.38-8-generic-pae i686
UpgradeStatus: Upgraded to natty on 2011-05-02 (22 days ago)
UserGroups:

WORKAROUND 2:

I've found out that LibreOffice needs a CIFS mounting to work on a remote file... NAUTILUS does it automatically when I try to open a path ... But DOLPHIN (Default File Manager of KUBUNTU 10.10) don't... So is this a restriction of LibreOffice? Because in my Open Dialog (in my Kubuntu Desktop) I have the option to directly (without the need of CIFS mounting) access SAMBA shares (In Ubuntu I don't have such option)... And OpenOffice allow this type of opening (directly - without the need of CIFS mounting - access SAMBA shares) together with CIFS mounting opening procedure...

QUESTION:

Am I forced to mount via CIFS (in /etc/fstab) all my network to be able to work on documents, presentations and etc via LIBREOFFICE?

BEST SOLUTION FOR EVERY DESKTOP EDITION:

Modify LibreOffice code to allow it to access directly (without the CIFS mounting) a SAMBA Share and open a remote file...

IMPORTANT NOTE:

What I've noticed too is that OpenOffice 3.2.1 does such handling (it open CIFS mounting and directly SAMBA Shares, remote path)... So, if both programs have come from the same origin (LibreOffice was done by a group that came from OpenOffice group), can you guys open the source code of OpenOffice and "translate" this part to LibreOffice?

Thanks for your help,

André M.

I've put an image of the problem to you see what exactly is...

The error translated to English is:

"You can only select local files"

Hello,

This is happening because LIBREOFFICE DON'T SUPPORT KIO SLAVES functionality of KDE... So I suggest KIO SLAVES to be in the WISHLIST of LIBREOFFICE to make it support this function... It's very important to common users that want to move to LINUX and don't know how to mount manually a remote path with CIFS command...

Thanks for your help,

André M.

summary: Can't acess remote files (in another computer via Network) with
- LibreOffice 3.3.1
+ LibreOffice 3.3.1 without CIFS mounting (KIO SLAVES should be used to
+ make the remote access work)
summary: - Can't acess remote files (in another computer via Network) with
- LibreOffice 3.3.1 without CIFS mounting (KIO SLAVES should be used to
- make the remote access work)
+ [LibreOffice] - Can't acess remote files (in another computer via
+ Network) with LibreOffice 3.3.1 without CIFS mounting (KIO SLAVES should
+ be used to make the remote access work)
summary: - [LibreOffice] - Can't acess remote files (in another computer via
- Network) with LibreOffice 3.3.1 without CIFS mounting (KIO SLAVES should
- be used to make the remote access work)
+ [LibreOffice] - Use of KIO SLAVES instead of CIFS to access remote files
+ (located in the Network)

I did a bug report in the Gnome MPlayer package (https://bugs.launchpad.net/ubuntu/+source/gnome-mplayer/+bug/737201) and AMAROK (https://bugs.launchpad.net/ubuntu/+source/amarok/+bug/738262) and VLC (https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/737192) 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 did a bug report in the Dolphin package about this issue too (https://bugs.launchpad.net/ubuntu/+source/kubuntu-kde4-meta/+bug/730984) because I don't know if it's better to applications support KIO SLAVES or DOLPHIN auto mount via CIFS remote paths (samba, nfs, etc)...

HubertB (hubertb) wrote :

I spotted a different behavior in Kubuntu 11.04: LibreOffice is actually able to open files on samba / cifs shares, but this is done by KDE downloading them to /var/tmp/kdecache-<username>/krun/<something> first. The problem is when you modify this files and hit the save button: LibreOffice reports no error as the file could successfully be saved, but - and that is the major problem - the file is saved to /var/tmp/kdecache-<username>/krun/<something> so the version of the server is never touched! Funny thing is that after 8 hours of work and a "successfully" save, I switched of my PC and went home. On the next day I realized that all of my changes are gone...

I had the same problem as HubertB....

I can access remote files with LibreOffice using KIO SLAVES Samba protocol (SMB://), but when any change is done in the file, this change is not committed to the computer from which this file came from (SMB server)...

 These changes are kept in the client computer (the computer that access the SMB remote file) location /var/tmp/kdecache-<username>/krun/<something>

Please solve this issue as fast as possible since this can cause serious problems to Enterprise environments that need files to be committed to a central SAMBA server...

PS: This issue is verified in LibreOffice version 1:3.3.2-1ubuntu5 (installed from LibreOffice UnOfficial Repositories) in a Kubuntu 11.04 32 bit OS with SAMBA version 2:3.5.8~dfsg-1ubuntu2.2

Thanks for your help,

André M.

tags: added: apport-collected natty
description: updated

apport information

Massimo Cora' (pescio) wrote :

I suppose it's Libreoffice that's laking support for remote file saving, which is a shame.

Changed in libreoffice (Ubuntu):
status: New → Confirmed
gonssal (gonssal) wrote :

I'd like to extend this bug report with another related issue. I'm using KDE 4.6.5, Kubuntu 11.04.

When I try to access a remote file from a protocol and server that requires authentication (i.e. FTP, sFTP...), a window pops up asking for username and password, but the username field is disabled and you can't modify it. It will let you modify the password field, but the username is disabled and it says "anonymous".

timmans (timinbrazil) wrote :

I can confirm the problem experienced by HubertB and André Madureira is happening with me too.
Ubuntu 11.10 64bit, with kde-desktop, accessing files on Ubuntu 10.04 LTS server.
- When opening remote file through Dolphin, opens a local copy in LibreOffice Calc at /var/tmp/kdecache-<username>/krun/... and adds numbers to the start of the file name (i.e. the remote file test.ods would be opened as something like 8310.0.test.ods in the above /var/temp/ address).
- Opening the same remote file through the "Open" icon in LibreOffice Calc opens it properly, from the remote address.
- Opening the same file through Nautilus (while still in KDE) opens it properly, from the remote address.
- I can confirm the same behaviour above with KeePassX (password manager) and Gnumeric but both VLC and gwenview seem to work properly when opening remote audio and picture files through Dolphin.
It appears that the fault maybe with the way Dolphin opens these Network shares and cannot properly pass the correct path of the file to the application, so it save a local copy of the file and then passes that to the application.
This is a major problem in a business/corporate environment where accessing remote files is the norm.

Could you retry if your troubles still exist with LibreOffice 3.5.X on precise? We switched from deprecated GnomeVFS to GIO.

Changed in libreoffice (Ubuntu):
status: Confirmed → Incomplete

I'm using libreoffice 1:3.5.2-2ubuntu1 on precise and the problem is still present.

I could not check the problem myself, but based on the above comment, I can assume the problem still persists...

Changed in libreoffice (Ubuntu):
status: Incomplete → Confirmed
Kevin Loughrey (kevinl) wrote :
Download full text (4.0 KiB)

10 May 2012.

I reported this problem to Launchpad a few weeks ago. My clients couldn't open and save files created in LibreOffice on a Windows network. It was, however, possible to open a file located on a server on a Windows-like network (one using SMB), in LibreOffice Writer, by browsing to the file, using "Places", right-clicking on it, and selecting LibreOffice from the context box to launch Writer with the file being automatically loaded in the process. It was possible to edit the file, opened in this manner, and then save it back to the server.

I have now "solved" the problem by upgrading from 11.10 to 12.04 but possibly found a minor bug in the installation script of the 12.04 upgrade so I thought I should report it here for the benefit of those faced with this problem and those who so marvellously fix the issues raised (and for whose efforts I am so grateful!).

I am a "mid-range" user (compared to the engineers who work for me.. they are brilliant but not disposed to reporting the things they do.) so pardon me if I write something that is not entirely precise or accurate. Please feel free, anyone, to correct what I say.

In the Gnome human interface there is a virtual file system that provides a compatible means by which Linux can interact with a network that uses Microsoft Windows-like file messaging; called SMB (standing for Server Message Block protocol which Microsoft modifed and called Common Internet File System - CIFS). The Linux application that provides compatibility between Linux systems and CIFS file servers is called SAMBA (First developed by Dr Andrew Tridgell - now supported by a team of good guys.). The compatibility layer provided by Gnome to work with the CIFS/Samba file system is called the Gnome Virtual File System. (You may have seen .gvfs in the paths of files. ) In Ubuntu 11.10, there was not a good working relationship between the GVFS and LibreOffice. Indeed, within LibreOffice (and OpenOffice for that matter) running within Gnome, the means of browsing a Windows network, or a network generally, has always been unsatisfactory. (I hasten to add this is in no way a criticism of the people who have given so much of themselves developing these applications!) For example, when browsing for a file in LibreOffice you can't rename files, copy or move files or delete files as you can so conveniently in MS Windows. There is no button to click on to go to a network and when you click on the drop-down box in LibreOffice file browse, there is no obvious tree allowing you to easily browse your network.

But, and here's the really good news, there is a Gnome compatibility layer package that you can install (if you knew about it) that will solve some of these problems. You go to the Synaptic Package manager and in the search box, type Gnome LibreOffice. For Ubuntu 12.10, you really need "office productivity suite -- GTK+ 3.0 integration" but the earlier version I found seems to work also. That's what you need if you want to browse all files at your disposal when working within LibreOffice. So install the package and things seem to work really, really well.

When you first upgrade to Ubuntu 12.10, you fi...

Read more...

marking as a dupe of 792622 as per comment 15

David Nuñez (auledoom) wrote :

this bug i'ts still present on a new clean kubuntu 12.04 installation. Defaults libreoffice version 3.5.3.2 Build ID: 350m1(Build:2). Or updating libreoffice from launchpad, version LibreOffice 3.5.5.2 Build ID: 350m1(Build:2) and should not be marked as duplicated of a fixed bug.
LibreOffice still opens smb:// shared file on a temporary folder /var/tmp/kdecache-user/krun/

JT Moree (jtmoree-l) wrote :

+1 on the invalid duplicate status. This bug is about using libreoffice with KDE. The fix suggested in comment 15 does not work on Kubuntu 13.10 or 13.04.

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

Other bug subscribers