[Upstream] Libreoffice: problems with saving docs to directories of Windows networks (through samba-connection)

Bug #1069757 reported by Johan Van Hoorde on 2012-10-22
110
This bug affects 21 people
Affects Status Importance Assigned to Milestone
LibreOffice
Invalid
Medium
gvfs (Fedora)
Invalid
Undecided
Unassigned
libreoffice (Ubuntu)
Undecided
Björn Michaelsen

Bug Description

At the office I use my Ubuntu computer as a work station and connect it to our Windows network by establishing Samba (smb) connections. In this way I can not only use the print facilities but also use directly the network directories for opening, saving of documents.

Since ubuntu 12.04 directories of windows networks have been integrated in the procedure for opening, saving of documents in Libreoffice. Directories available through open samba-connections thus are integrated in the list of directories on which docs can be saved. This was a great new features, since before 12.04 one had to save files on a local directory first and then move or copy them to the windows directory in Nautilus.

After having done the upgrade to ubuntu 12.10 QQ this facility does not work as it should. The network directories are still shown and it it still possible to open a document. But is it not possible to save it and giving it another name. Another thing which had become impossible is to open a document from another source than the network directory (e.g. local directory, attached doc to a mail) and save it in a directory of the network server.

When doing this the system gives the information 'Error saving the document #name#. The file does not exist' (see screenshot 1, text in italian). If one then presses the OK-button there is a second error communication with the following text:
Error is saving the document #name#:
General Error
Generel I/O error
(see screenshot 2, text in italian)

I have checked whether the same kind of error also occurs in other programs, at least in Evince (pdf-reader). This is not the case.

A last issue I want to report is that when one opens a doc (e.g. odt) from a network directory, modifies it and then save it, this seems to work. There is no error messsage. When checking by re-opening the saved document, in a few experiments I did the modifications were not saved. In nautilus the date indication of the file also remained the same. In other experiments however the saving of the documents with the modifications seemed to work as it should.

conclusion: the integration of network directories in LO has become unreliable, with a high risk of loss of information for the user.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: libreoffice 1:3.6.2~rc2-0ubuntu3
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic i686
ApportVersion: 2.6.1-0ubuntu4
Architecture: i386
Date: Mon Oct 22 12:47:08 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
MarkForUpload: True
SourcePackage: libreoffice
UpgradeStatus: Upgraded to quantal on 2012-10-19 (2 days ago)

Created attachment 66352
Screenshots of errors

Unable to "Save As" on Samba,"Windows Share",gvfs created from Nautilus

When trying to "Save As" to a "Windows Share" (gvfs) mounted with Nautilus in Ubuntu, three errors occur.

- The file is not created.

- Error messages appear.
-- "Error saving the document" "Nonexistent file"
-- "Error saving the document" "General Error." "General input/output error."

- Libreoffice can no longer be closed from the menu and must be Force Quit. Most menu features are now greyed out, including "About".

We are able to open and save existing files on the share with Libreoffice. Other applications, such as Sublime Text, are able to create new files and Save As.

It also appears that after we force quit, it leaves the lock files in place, which LO does initially successfully create on the share when opening an existing file. Does this mean that the file creation process for LO's lock/temp files is entirely different from how it access the share when trying to create or save normal files?

This appears to have been a problem for a long time, specific to shares mounted with these methods.

Same problem here on Ubuntu 12.04 and LibreOffice PPA (libreoffice 3.6.0). Solved removing PPA (sudo ppa-purge libreoffice) and reverting to Ubuntu repos version (libreoffice 3.5.4.2).

Seems related to http://lists.debian.org/debian-openoffice/2012/01/msg00091.html
"enable gio, disable gvfs"

I have the same problem as Bru Baldovi. Using LO 3.6 installed from the LO stable PPA (libreoffice/ppa) I cannot "Save" OR "Save As" to a SMB fileshare (connected to ~/.gvfs/xxxx through Nautilus "connect to server" dialogue).

The error messages from the attachment are the same.

UPDATE: I can get it to save by manually navigating to ~/.gvfs/xxxxxx in the Save or Save As dialogue. So the problem only exists when you try to Save or Save As using the share shortcut in the dialogue. I will attempt to add a screenshot to show what I mean.

Created attachment 67666
SaveAs workaround by manually navigating to folder

Screenshot of SaveAs dialogue that will give an error (selecting share from left panel), and of SaveAs dialogue that will be able to save (manually navigate to ~/.gvfs/share folder)

This issue also affects me, identical to symptoms described, using Libreoffice 3.6.1.2 installed using the debs on the libreoffice.org website, on Ubuntu 12.04.

Chris

This issue also appears for me with the debs for 3.6.2.2 downloaded/installed 8 October.
'Save' works as expected, 'Save As' does not.
'Save As' by manually navigating to the .gvfs/foo local mount point is a workaround.
Chris

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libreoffice (Ubuntu):
status: New → Confirmed
Julian Clark (julian.clark) wrote :

I suspect that this is an overall issue with LibreOffice 3.6 in a GNOME-based desktop environment (tested in Unity and GNOME Shell). I experienced the same behavior indicated in the original bug report when trying to save files to different forms of network storage from LO 3.6 -- in my case, Samba/SMB/CIFS and WebDAV. Opening files from network storage works fine (though LO still handles files over WebDAV independently from the OS). With the Windows shares, I could only save the file if the file already existed. Consistent with the original bug report, I could not save *new* files. With WebDAV, I could not save *at all* -- even to an existent file.

I first noticed this behavior with an otherwise successful manual backport of LO 3.6.2 from Quantal (12.10) to Precise (12.04). Thinking that the problem might have been something being different in Precise, I then tested for the problem in a fresh install of Quantal. After seeing the problem in Quantal as well, I tested for it in another Linux distribution (in that case, using LO 3.6.3). The behavior was the same across the board. In all three cases, the desktop environment was GNOME-based, with the network storage having been mounted via GVFS/GIO. I know for sure that this problem did not exist in LibreOffice 3.5. In the past, I have seen KDE handle network storage better than GNOME -- especially with OpenOffice and LibreOffice. I will soon test all of this in KDE as well, to ensure that more bases have been covered.

I would consider this bug with network storage to be a significant regression, and a high priority for anyone using LO in the enterprise (where the use of network storage is common). I hope that the importance of this bug will be considered to be high.

Julian Clark (julian.clark) wrote :

The related upstream bug report: <https://bugs.freedesktop.org/show_bug.cgi?id=54275>. I would not consider the recommended workaround to be a solution, though I have used said workaround in the past with other applications that are not GVFS-aware. LibreOffice *is* GVFS/GIO-aware, but said functionality appears to be currently broken.

If I create an empty file, I am able to save the document. However, it does not save it correctly. Rather it saves the file one directory higher with the name of the directory in the file name.

If I create the file (using touch) ".../dir1/dir2/file.odt" then select it as the save as file, the file ".../dir1/dir2 file.odt" is created instead.

I confirm this Bug using Libreoffice 3.6 from PPA. (ubuntu 12.04.1)

Reverting to Ubuntu repos version (libreoffice 3.5.2.2) fixes the issue.

Confirmed this bug on Arch Linux with libreoffice-base 3.6.3-3

I am not sure what the other commenters in 5 and 6 are seeing. Maybe they are indicating if you open an existing document on a .gvfs share, modify it, and then "save" it will save correctly, which I can confirm.

To clarify the bug, in my testing I am NOT able to "save" OR "save as" on a NEW document IF the target is a samba share (mounted to ~/.gvfs/share-name).

I have just finished installing and testing on the following version:

Version 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0)

for Ubuntu 12.04 64 bit.

I have added this bug to the 3.6 mab (bug #44446) as 3.6 appears to be the place this bug first appeared.

Comment # 9 on bug 54275 from iveand
>
> I am not sure what the other commenters in 5 and 6 are seeing. Maybe
they are
> indicating if you open an existing document on a .gvfs share, modify it,
and
> then "save" it will save correctly, which I can confirm.
>
> To clarify the bug, in my testing I am NOT able to "save" OR "save as" on
a NEW
> document IF the target is a samba share (mounted to ~/.gvfs/share-name).

I confirm it all.
This bug is a blocker.

Bjoern - another duplicate of the Ubuntu specific(?) samba bug - now apparently a 3.6 MAB.

jj.giopa (jj.giopa) wrote :

I've the same problem, but I want describe my case study :

1. I open a file via nautilus on a smb share, LO goto to zombie and I must reboot : HORRIBLE BUG !

other case :

1. I open a local file, via nautilus. I's works. ok
2. I open a local file, on a smb share (ie smb://serverX/templates/0000/pippo.odt). ok
3. I edit the file. ok
4. I save the file via ctrl+s : he saves on the wrong path : smb://serverX/templates/0000pippo.odt
5. I try "save with name" on other location on the same smb share. I see the described by other users "errore generale I/O"

Julian Clark (julian.clark) wrote :

This bug recently made it to the LibreOffice 3.6 most annoying bugs (mab) list: < https://bugs.freedesktop.org/show_bug.cgi?id=44446 >. This bug is also reported to be currently unresolved in LibreOffice 4.0.0.

Description of problem:

When saving a file in libreoffice, using the mounted gvfs-path, the following error occurs. Libreoffice cannot get closed then and needs to be killed in the shell.

Errors:
"Error saving this document: the file doesn't exist" and then after OK, this
"Error saving this document: general error. general i/o-error"

-> Saving to /run/user/[userno.]/gvfs/ works!!

Version-Release number of selected component (if applicable):
Version 3.6.3.2 (Build ID: 3.6.3.2-8.fc1

How reproducible:
Always

Steps to Reproduce:
1. Open Libreoffice, create any new file
2. save file to a share using gvfs (preferable on a samba-share)
3. Get the error

Actual results:
Cannot save file to this path.

Expected results:
Saving File to the Path indicated in the save-as-path-dialogue to the left.

Additional info:

Hi,

Because this is that much confirmed I think we can mark this bug as NEW. If this is indeed a duplicate we can mark it as such, but this bug isn't unconfirmed :-).

Following [1] I mark this bug as 'Major High'

[1] https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Also affecting me, Ubuntu 12.10 x64, LibreOffice Version 3.6.2.2 (Build ID: 360m1(Build:2))

I've just installed LibreOffice 4.0.0.3 on Ubuntu 12.04 i386 and this bug is still present.

It's a nasty "blocker" bug.

primes2h: that is annoying, can you do:

pkill -9 -f soffice.bin
strace -f -ttt -s 256 -o /tmp/slog soffice

And then try to save a blank file as some well known name eg. "foobaa.odt" on a gvfs samba share.

Then kill it (ctrl-c is good) - and gzip / attach /tmp/slog :-)

I imagine there is some obscure / odd system error returned via FUSE for that that we are not handling properly ... it'd be great to find out what it is.

Thanks !

Created attachment 74442
strace of libreoffice 4.0

Hi Michael, here you have!

Tell me if you need more info, I really hope it'll be fixed soon.

Thanks for your help.

Created attachment 74599
strace libreoffice 3.6

@Michael
Here you have the strace using libreoffice 3.6

The first strace I uploaded was from libreoffice 4.0 (affected by this bug as well)

Let me know if you need something.

Fun so we're not using FUSE, but a direct channel to the VFS.

9008 1360581100.835641 socket(PF_FILE, SOCK_STREAM, 0) = 50
9008 1360581100.835842 connect(50, {sa_family=AF_FILE, path=@"/dbus-vfs-daemon/socket-pSgdFfMM"}, 35) = 0

9008 1360581100.835995 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC, 0) = 51
9008 1360581100.836036 connect(51, {sa_family=AF_FILE, path=@"/dbus-vfs-daemon/socket-TWLvJq4h"}, 35) = 0

Which is odd:

9008 1360581094.195836 open("/usr/lib/libreoffice/program/../program/ucpgio1.uno.so", O_RDONLY|O_CLOEXEC) = 29

Looks like we're using the gio backend - which is fun. I guess we'd want to do some more debugging with symbols and work out which methods are failing.

Failing that - potentially there is some gio debugging mechanism that we could turn on to see what is going on (I suspect).

I imagine that if we just move away the 'libucpgiolo.so' or whatever then we'll fall-back to using FUSE which will work better - but ... who knows.

Of course - this -could- be an issue with the gvfs samba implementation too - perhaps worth stracing that ... not sure.

Should this be taken out of MAB or marked as NEW, we usually don't keep NEEDINFO bugs in MAB. I can save to samba after a patch put out a week or so ago but this may be a separate issue.

Michael - thoughts?

Thanks for all the activity on this bug -- it is indeed a signifiant "blocker" that is preventing me from being able to implement for our office. Just to act as a reminder, this problem does NOT exist in 3.5.x series.

I am sorry to not be a programmer, but I wonder if there is a useful way to "diff" between 3.5.x and the newest 4.0.x version to find anything?

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Incomplete
summary: - Libreoffice: problems with saving docs to directories of Windows
- networks (through samba-connection)
+ [Upstream[ Libreoffice: problems with saving docs to directories of
+ Windows networks (through samba-connection)
summary: - [Upstream[ Libreoffice: problems with saving docs to directories of
+ [Upstream] Libreoffice: problems with saving docs to directories of
Windows networks (through samba-connection)

This is affecting me as well dealing with files on SMB, with Fedora 18. I suspect now that Nautilus has been overhauled and moved from GVFS to GIO, LibreOffice is hitting this problem.

It was okay on Fedoar 17.

I don't claim to know the details of the code, but regarding it being a Nautilus issue, remember that LO 3.5.x works fine in this regard. The issue only exists with L0 3.6.x and newer.

adding gvfs as per comment 26.

@gvfs guys: Any hint on how to best triage this one (see LibreOffice upstream bug)?

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gvfs (Ubuntu):
status: New → Confirmed
EliCoten (launchpad-elicoten) wrote :

In case it helps, I have the same problem with a permanently mounted (via fstab) samba share. Not sure what gvfs is, but my fstab makes no reference to gvfs and yet I still encounter the problem.

Does it make a difference to first set "Tools - Options... - LibreOffice - General - Open/Save dialogs - Use LibreOffice dialogs" to true and then save via that dialog ?

caolanm->sberg: is the a dup of the X-GIO-NoFuse=true issue or something else ?

Does the problem go away when you select "Tools - Options... - LibreOffice - General - Open/Save dialogs - Use LibreOffice dialogs" first?

i have changed this in libreoffice, now 2 situations occure:

Prerequisite: i saved the samba-share as a favourite within libreoffice in the open/save-dialogue

i always open a file within nautilus and want to save it.

1) i save clicking on the favourite folder and type a filename: The error comes up as described above

2) i use the path, which libreoffice seems to have and points to the local resource /run/user/100n/gvfs/[share] - this works

and if i open the file within libreoffice without nautilus, both described situations

1) the same, it won't save

2) the same, it saves.

it works always using the path from /run...

and no, it doesn't go away.

Regarding using the native LO Dialogs, they do not provide "sidebar access" to pinned (or "mounted") Samba shares, so the user can only find these shares by manually navigating to the ".gvfs" folder and then to the share. Note that as far as I can tell there is not the option with these LO Dialogs to "show hidden directories" so the only way to even see the .gvfs folder is to manually type it in the location bar.

In summary, since "mounted devices" aren't shown in the LO Dialogs there doesn't seem to be an easy way to test these dialogs for the same situation. As noted earlier, in the standard dialogs it is possible to save correctly by manually navigating to the .gvfs folder.

Rik Shaw (rik-shaw) wrote :

Here is my reply on freedesktop.org (next time I'll reply here first as I see it will then send the comment over there):

Regarding using the native LO Dialogs, they do not provide "sidebar access" to pinned (or "mounted") Samba shares, so the user can only find these shares by manually navigating to the ".gvfs" folder and then to the share. Note that as far as I can tell there is not the option with these LO Dialogs to "show hidden directories" so the only way to even see the .gvfs folder is to manually type it in the location bar.

In summary, since "mounted devices" aren't shown in the LO Dialogs there doesn't seem to be an easy way to test these dialogs for the same situation. As noted earlier, in the standard dialogs it is possible to save correctly by manually navigating to the .gvfs folder.

The description of this issue sounds very much like <https://bugzilla.redhat.com/show_bug.cgi?id=895690> "Libreoffice causing errors when SAVING files by gvfs-mount (Samba)." However, there are two alternative ways LO can access gvfs, either via the "gvfs UCP" (when the LO build is configured --enable-gnome-vfs) or via the "gio UCP" (when the LO build is configured --enable-gio).

<https://bugzilla.redhat.com/show_bug.cgi?id=895690> "Libreoffice causing errors when SAVING files by gvfs-mount (Samba)" is definitely due to the gio UCP.

The generic Linux LO builds (as can be downloaded from <http://www.libreoffice.org/download/>) use the gvfs UCP, while the LO builds included in Ubuntu (which is mentioned in many of the comments here) reportedly uses the gio UCP.

It is unclear to me whether people reporting here experienced the problem with generic builds or with Ubuntu-specific ones (or both).

So for those people (if any) who experienced this with Ubuntu-specific builds, this issue would be a duplicate of <https://bugzilla.redhat.com/show_bug.cgi?id=895690> "Libreoffice causing errors when SAVING files by gvfs-mount (Samba)" (for which I have a fix that will go into the various upstream LO branches).

And for those people (if any) who experienced this with generic builds, this would mean that a similar problem to the one fixed for the gio UCP now is also present in the gvfs UCP. I'm going to investigate that.

Thanks for the fix Stephan - merged it to: -4-0 for 4.0.3 - might be nice to have it in gerrit for the 4.0.2 branch ? [ needs another couple of reviews ]

(upstream fix is <http://cgit.freedesktop.org/libreoffice/core/commit/?id=8722f0e7ef690205d042c8a6b1fdf342a34ecbe1> "rhbz#895690: Make GIO UCP less brittle, so saving docs works again")

The status for the gio UCP fix is:

* Fixed in libreoffice-3-6 towards LO 3.6.6 as <http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-6&id=524962c4ade96412ed4c1bbf912492e39d054f0f> "rhbz#895690: Make GIO UCP less brittle, so saving docs works again."

* Fixed in libreoffice-4-0-2 towards LO 4.0.2 (in case of further RCs) as <http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-0-2&id=6892e43649e9d405c1b38e80826ebe87b2aca2e9> "rhbz#895690: Make GIO UCP less brittle, so saving docs works again."

* Fixed in libreoffice-4-0 towards LO 4.0.3 as <http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-0&id=43a4a16f60b7d1603b9984cfb355dc7e736a15f4> "rhbz#895690: Make GIO UCP less brittle, so saving docs works again."

* Fixed in master towards LO 4.1 as <http://cgit.freedesktop.org/libreoffice/core/commit/?id=8722f0e7ef690205d042c8a6b1fdf342a34ecbe1> "rhbz#895690: Make GIO UCP less brittle, so saving docs works again."

tags: added: target-4.0.3
Changed in df-libreoffice:
importance: Medium → Undecided
status: Incomplete → New
status: New → Fix Committed
Changed in libreoffice (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Björn Michaelsen (bjoern-michaelsen)

libreoffice-3.6.5.2-7.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libreoffice-3.6.5.2-7.fc18

Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=112d3287a9424e0baaa8d956e6aff8932d48658e

fdo#54275: Fix GVFS UCP, so saving docs works again

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

(In reply to comment #25)
> And for those people (if any) who experienced this with generic builds, this
> would mean that a similar problem to the one fixed for the gio UCP now is
> also present in the gvfs UCP. I'm going to investigate that.

Turned out the gvfs UCP was plagued by similar issues indeed. See comment 28 for the fix, requested backports to libreoffice-3-6 towards LO 3.6.6 as <https://gerrit.libreoffice.org/2729> and to libreoffice-4-0 towards LO 4.0.3 as <https://gerrit.libreoffice.org/2730>.

...and to libreoffice-4-0-2 as <https://gerrit.libreoffice.org/#/c/2731/>, in case we're brave enough.

Changed in df-libreoffice:
importance: Undecided → Unknown
status: Fix Committed → Unknown

Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2d8cc9f69cbfb85881e73ffa6a6926fb3395238&h=libreoffice-3-6

fdo#54275: Fix GVFS UCP, so saving docs works again

It will be available in LibreOffice 3.6.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dcd1171ccccc5be0830c59bfacff74a254295d9b&h=libreoffice-4-0

fdo#54275: Fix GVFS UCP, so saving docs works again

It will be available in LibreOffice 4.0.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Package libreoffice-3.6.5.2-7.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreoffice-3.6.5.2-7.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-3868/libreoffice-3.6.5.2-7.fc18
then log in and leave karma (feedback).

Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-4-0-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=98057f51ef662f5da25891fed01a4ccfa280b2e9&h=libreoffice-4-0-2

fdo#54275: Fix GVFS UCP, so saving docs works again

It will be available already in LibreOffice 4.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Installed, tested and left posivite karma.

Thx!

libreoffice-3.6.5.2-8.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libreoffice-3.6.5.2-8.fc18

No difference, using LibreOffice dialogs I got the same error.

Rik Shaw (rik-shaw) wrote :

The LibreOffice bug report has been updated to indicate the fixes for this bug will be in 3.6.6 and 4.0.2.

https://bugs.freedesktop.org/show_bug.cgi?id=54275

This is a huge bonus and thanks to all that have worked on it. I haven't downloaded to confirm the patch yet, but hope to soon.

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Fix Released

libreoffice-3.6.5.2-8.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.

*** Bug 926001 has been marked as a duplicate of this bug. ***

On problem with this fix, in the past I could use the recent list to load files on a gvfs mount and it would automount it (ask for a password if needed). With this fix, that doesn't work.

I do not know if you can cause the mount from file/open or not. I have had to just use nautilus to go to the mount and get it mounted, then the recent list works.

(In reply to comment #12)
> On problem with this fix, in the past I could use the recent list to load
> files on a gvfs mount and it would automount it (ask for a password if
> needed). With this fix, that doesn't work.

Are you sure that this got broken with this fix (i.e., did it still work with libreoffice-3.6.5.2-6.fc18)?

*** Bug 58320 has been marked as a duplicate of this bug. ***

Testing this with 4.0.2 RC2 (which should have the fixes) under Ubuntu 12.10, file load and save still don't work with SMB shares.

After such a load, the document opens as empty. Attempting a save, an error dialog appears saying "Error saving the document X: Nonexistent object. Path to the file does not exist."

Changed in df-libreoffice:
status: Fix Released → Confirmed

I just posted that I was still experiencing this bug, when using 4.0.2 RC2 (as downloaded from the Pre-Releases sections of libreoffice.org).

Testing again with a locally built copy from the git repo at tag libreoffice-4.0.2.2 I find that load and save are in fact working.

My build process was
$ ./autogen.sh --disable-gnome-vfs --enable-gio
$ make
$ make dev-install -o build

I don't know what the difference between that and the released package would be, but seems the code in git is OK.

Changed in df-libreoffice:
status: Confirmed → Invalid

Only 1 MAB relation allowed.

I am not sure what version it worked with. It was working with several versions post Fedora 18 release. It doesn't work now. It would be helpful if it did, but if it can't be fixed, I can understand that.

(In reply to comment #36)
> I just posted that I was still experiencing this bug, when using 4.0.2 RC2
> (as downloaded from the Pre-Releases sections of libreoffice.org).
>
> Testing again with a locally built copy from the git repo at tag
> libreoffice-4.0.2.2 I find that load and save are in fact working.
>
> My build process was
> $ ./autogen.sh --disable-gnome-vfs --enable-gio
> $ make
> $ make dev-install -o build
>
> I don't know what the difference between that and the released package would
> be, but seems the code in git is OK.

The official, generic Linux builds at <http://www.libreoffice.org/download> are built --enable-gnome-vfs --disable-gio, which does make a difference here, as --enable-gnome-vfs and --enable-gio provide alternate implementations for accessing remote files.

Jerome Warnier (jwarnier) wrote :

I can add that it also happens on sFTP, not only on SMB connections to servers.

And let me add that the version 4.0.2 from ppa:libreoffice/libreoffice-4-0 for Raring works.
I really hope 4.0.2 will do it into Raring.

Julian Clark (julian.clark) wrote :

I will second that LibreOffice 4.0.2 from the LibreOffice 4.0 PPA resolves the aforementioned issues in Raring (13.04). Just today, LO 4.0.2 moved from -proposed to -release. However, installing LO on Precise (12.04) from the same PPA does not resolve all of the issues. The only problems I could find with using files via network storage after installing in Raring were related to WebDAV (not being able to open files directly from Nautilus, and not being able to save files that do not already exist). The same issues existed in Precise, with the addition of not always being able to open files on SMB/CIFS/Samba shares from within LibreOffice. A general I/O error is the result. Opening files from Nautilus worked fine, though. I would imagine that the major focus for bug fixes in LO at this point -- regular repositories or PPAs -- is Raring and later.

Solved on raring as per comment 55.

Changed in libreoffice (Ubuntu):
status: In Progress → Fix Released
Laurent Dinclaux (dreadlox) wrote :

Great, congrat! Now it is maybe time to backport the fix to the latest LTS.

I can't imagine LTS users not being able to work in an enterprise environment, for five years ....

Great job, Björn! Fortunately, there's only a few days left before the release of 13.04. I sincerely hope that the other problems I had with LO within Ubuntu will also be resolved. The most important of these concern LO Base, which didn't work at all.

> The official, generic Linux builds at <http://www.libreoffice.org/download>
> are built --enable-gnome-vfs --disable-gio, which does make a difference

Seems like that is disabled on the -4-0 branch (oddly) - so marking a duplicate.

*** This bug has been marked as a duplicate of bug 64311 ***

(In reply to Trever Adams from comment #12)
> On problem with this fix, in the past I could use the recent list to load
> files on a gvfs mount and it would automount it (ask for a password if
> needed). With this fix, that doesn't work.
>
> I do not know if you can cause the mount from file/open or not. I have had
> to just use nautilus to go to the mount and get it mounted, then the recent
> list works.

Turns out I forgot about this but later re-discovered the problem and fixed it on upstream master towards LibreOffice 4.2 as <http://cgit.freedesktop.org/libreoffice/core/commit/?id=4d8bf09305fc4e4bd652187aac0a02398413ba65> "Always try to mount in gio::Content::getGFileInfo" (no idea when exactly it got broken, though). Anyway, will be fixed in the next libreoffice-4.1.1.1-3.fc19.

Testing this with 4.1.5 under Ubuntu 12.04, file load and save still don't work with SMB shares.
Testing this with 4.2.1 under Ubuntu 12.04, file load and save still don't work with SMB shares.

I've found a suggestion on this site
http://ask.libreoffice.org/en/question/23021/solved-open-ods-or-odt-files-from-a-smb-share-throws-damaged-file-error/.

The Suggestion said to put in the terminal the following string:
sudo sed -i 's/X-GIO-NoFuse=true/#X-GIO-NoFuse=true/' /usr/share/applications/libreoffice*

After that, I can:
- open a file (e.g.: dummy.odt) via Nautilus on a SMB share (Write will be opened to manage that file)
- save dummy.odt after adding something; the process works fine

But:
- I can't open file on a SMB share using CTRL+O: the "Open" window simply disappears!
- I can't save a new file on a SMB: Save AS (CTRL+S); I receive the error dialog: "Error saving the document X: Nonexistent object. Path to the file does not exist."

Regards

Changed in gvfs (Ubuntu):
status: Confirmed → Fix Committed

Not Fix Committed as defined in https://wiki.ubuntu.com/Bugs/Status .

Changed in gvfs (Ubuntu):
status: Fix Committed → Confirmed
Juebo (ubo-10-juebo) wrote :

This bug has returned with Ubuntu 16.04. With Ubuntu 14.04 everything worked well.
Affected are Libre Office, Open Office and Keepassx (0.4 and 2.0) - files on samba shares. Not on normal drives and not when I mount the share with mount.cifs.

Because my Keepassx and my Open Office has not changed this must be a bug with gvfs.

baubusiukas (andrius-mackonis) wrote :

I can confirm, that Ubuntu 16.04 has this same problem again with Libreoffice.
Had no problems with 15.04 and 15.10.

Note the original issue has been fixed in LibreOffice and gvfs (see history above). Likely whatever is breaking again on 16.04 is a different issue -- and thus should be a new bug, even though it has similar symptoms. Please do NOT reopen this bug on LibreOffice -- if you think this is an issue that needs fixing in LibreOffice (and not in gvfs and friends), please open a NEW bug.

I would suggest to close the issue on gvfs on the same rationale (the original bug was fixed) -- but I am not a maintainer there.

Changed in gvfs (Fedora):
importance: Unknown → High
status: Unknown → Fix Released
no longer affects: gvfs (Ubuntu)
Changed in gvfs (Fedora):
importance: High → Undecided
status: Fix Released → New
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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