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.
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 [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)
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
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.
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 [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.
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.
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?
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.
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 ?
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 ]
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."
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.
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.
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.
*** 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."
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.
Only 1 MAB relation allowed.
(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.
> 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 ***