Bug 54275 - Linux: Unable to "Save" (or "Save As") New Document on Samba (gvfs) Mounted Share
Summary: Linux: Unable to "Save" (or "Save As") New Document on Samba (gvfs) Mounted S...
Status: RESOLVED DUPLICATE of bug 64311
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Stephan Bergmann
URL: https://bugs.launchpad.net/df-libreof...
Whiteboard: target:4.1.0 target:3.6.6 target:4.0.2
Keywords:
: 58320 (view as bug list)
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-08-30 16:59 UTC by joehahn
Modified: 2019-04-26 16:06 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshots of errors (111.99 KB, image/png)
2012-08-30 16:59 UTC, joehahn
Details
SaveAs workaround by manually navigating to folder (140.83 KB, image/jpeg)
2012-09-25 06:43 UTC, Rik Shaw
Details
strace of libreoffice 4.0 (703.50 KB, application/x-gzip)
2013-02-08 17:38 UTC, Sergio
Details
strace libreoffice 3.6 (652.37 KB, application/x-gzip)
2013-02-11 11:18 UTC, Sergio
Details

Note You need to log in before you can comment on or make changes to this bug.
Description joehahn 2012-08-30 16:59:50 UTC
Created attachment 66352 [details]
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.
Comment 1 Bru Baldoví 2012-09-17 15:56:57 UTC
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"
Comment 2 Rik Shaw 2012-09-25 06:20:00 UTC
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.
Comment 3 Rik Shaw 2012-09-25 06:43:22 UTC
Created attachment 67666 [details]
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)
Comment 4 Chris Billington 2012-10-08 15:21:40 UTC
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
Comment 5 Chris Billington 2012-10-08 15:35:04 UTC
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
Comment 6 Lucas 2012-10-29 23:30:20 UTC
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.
Comment 7 Sergio 2012-11-06 13:44:39 UTC
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.
Comment 8 Dale Blount 2012-12-07 14:59:11 UTC
Confirmed this bug on Arch Linux with libreoffice-base 3.6.3-3
Comment 9 Rik Shaw 2012-12-26 14:55:34 UTC
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 10 Sergio 2012-12-26 15:00:33 UTC
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.
Comment 11 Michael Meeks 2012-12-27 16:06:15 UTC
Bjoern - another duplicate of the Ubuntu specific(?) samba bug - now apparently a 3.6 MAB.
Comment 12 Jorendc 2013-01-27 18:03:40 UTC
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
Comment 13 elicoten 2013-01-28 11:56:04 UTC
Also affecting me, Ubuntu 12.10 x64, LibreOffice Version 3.6.2.2 (Build ID: 360m1(Build:2))
Comment 14 Sergio 2013-02-08 10:11:45 UTC
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.
Comment 15 Michael Meeks 2013-02-08 15:09:54 UTC
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 !
Comment 16 Sergio 2013-02-08 17:38:36 UTC
Created attachment 74442 [details]
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.
Comment 17 Sergio 2013-02-11 11:18:54 UTC
Created attachment 74599 [details]
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.
Comment 18 Michael Meeks 2013-02-11 14:18:28 UTC
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.
Comment 19 Joel Madero 2013-02-11 18:37:26 UTC
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?
Comment 20 Rik Shaw 2013-02-11 19:22:57 UTC
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?
Comment 21 earthwormgaz 2013-02-20 11:11:19 UTC
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.
Comment 22 Rik Shaw 2013-02-22 22:04:15 UTC
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.
Comment 23 Caolán McNamara 2013-02-27 14:08:41 UTC
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 ?
Comment 24 Rik Shaw 2013-03-12 21:47:03 UTC
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.
Comment 25 Stephan Bergmann 2013-03-13 09:59:55 UTC
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.
Comment 26 Michael Meeks 2013-03-13 10:20:51 UTC
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 ]
Comment 27 Stephan Bergmann 2013-03-13 11:37:13 UTC
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."
Comment 28 Commit Notification 2013-03-14 16:16:12 UTC
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.
Comment 29 Stephan Bergmann 2013-03-14 16:40:52 UTC
(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>.
Comment 30 Stephan Bergmann 2013-03-14 16:45:46 UTC
...and to libreoffice-4-0-2 as <https://gerrit.libreoffice.org/#/c/2731/>, in case we're brave enough.
Comment 31 Commit Notification 2013-03-14 17:39:36 UTC
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.
Comment 32 Commit Notification 2013-03-14 17:39:57 UTC
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.
Comment 33 Commit Notification 2013-03-15 10:45:23 UTC
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.
Comment 34 Michael Meeks 2013-03-26 16:11:47 UTC
*** Bug 58320 has been marked as a duplicate of this bug. ***
Comment 35 Mag 2013-03-29 02:18:41 UTC
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."
Comment 36 Mag 2013-03-29 05:43:35 UTC
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.
Comment 37 Rainer Bielefeld Retired 2013-03-29 08:06:13 UTC
Only 1 MAB relation allowed.
Comment 38 Stephan Bergmann 2013-04-02 07:18:21 UTC
(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.
Comment 39 Michael Meeks 2013-05-07 09:53:46 UTC
> 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 ***