Apache OpenOffice (AOO) Bugzilla – Issue 104974
Error saving document on smbfs: Could not create backup copy
Last modified: 2010-01-12 09:46:10 UTC
I use OOO310m11 (Build 9399) [CWS:ooo31osol] on an Opensolaris x86 system (snv_122). The problem is that I cannot save an edited spreadsheet (or writer) document to a mounted smbfs share (Windows share). I mount the share using: mount -F smbfs //mydomain\;username@xx.xx.xx.xx/sharename ~/localdir When I open swriter, create a new document and save it in localdir everything is fine. When I then reopen this document (from localdir), make an editing and press the save button an error pops up saying: Error saving the document xxx: Error creating object. Could not create backup copy. If I press OK the pop up closes and I try to save again. With the second save the same thing happens. As a result I cannot save the edited document in the shared folder.
Same issue here, but for all types of documents (not only spreadsheets). Running OpenSolaris 2009.06 x86.
This defect has also been reported here: http://defect.opensolaris.org/bz/show_bug.cgi?id=12831 and internal to Sun as bugster CR 6906597 Here's my evaluation note for that CR: I ran StarOffice 9 (the version included in snv_127) twice, once re-saving a file on an smbfs mount, and again re-saving a file on a tmpfs mount. In both cases, I used truss to log system call activity, i.e. "truss -p $pid -o $outfile". The two files are: soffice-tmpfs.truss, soffice-smbfs.truss Both were edited to remove all but the relevant section. Comparing the two truss outputs, we can see that StarOffice is trying to mmap(2) a file in the smbfs mount point, which returns ENOSYS because smbfs(7fs) does not support mmap. One might be tempted to close this as a duplicate of CR 6565851 [mmap support for CIFS client (and use page cache)] but this IS arguably the fault of OpenOffice. Here's why: mmap(2) system call can and sometimes does return ENOSYS, both in smbfs and other file systems, and applications are expected to fall back to use of read/write instead. Unfortunately, many applications assume mmap(2) can be used on all files in all filesystems and don't bother to implement any fallback path for cases where mmap is not supported. OpenOffice is not the first to fail here. Many GNOME applications also incorrectly assume mmap always works. Someday, we hope to implement CR 6565851 for smbfs, and then this problem will again be mostly not exposed, but this is still really a bug in these applications.
This is an OpenOffice issue, described here: http://www.openoffice.org/issues/show_bug.cgi?id=104974
MD->CD/MAV: Can you say anything about the given configuration whether this should work or not? In general smb share work just fine with the office. To me it sounds like here is something very specific!?
Indeed the correctly configured samba works well. So it is indeed a specific configuration, as I know, nowadays samba supports mmap quite good mostly, at least on linux. I am not sure how is it on OpenSolaris. But OOo uses mmap for long time already. So I assume that this problem should be even reproducible in OOo2.x. Taking the issue over.
Confirming the issue, since gwr is right, we should have a fallback for the case that mmap does not work.
Adjusting the target.
To MAV: This has nothing to do with Samba. Solaris smbfs is not Samba. This is OpenOffice working on a Solaris smbfs mount, i.e. /usr/sbin/mount -F smbfs //server/share /mnt openoffice /mnt/mydoc.odt Save and then save again (re-save) reproduces the issue described. Please revert the summary.
mav->gwr: Yes, formally speaking, smbfs is not a Samba. But the "Samba" term is often used to refer the "SMB" protocol. Correcting the summary. So, could you please explain why do you want me to revert the comment.
mav->gwr: Oh, it was about summary reverting, not about comment reverting. Sorry for misunderstanding.
I have just recognized that OOo3.2 uses now mmap also in case of opening of OOo-documents. OOo3.2 copies OOo-format files instead of streaming it, that is faster, it was an optimization. But osl copy API is based on mmap, so this scenario is now also affected. That would mean, that OOo3.2 would not even be able to open such a document from the problematic location. Could somebody test one of last OOo3.2 builds on the problematic system to check whether my assumption is correct. But even if the assumption is correct I would prefer to adjust sal copying API, instead of removing the optimization. Whether it should be done for OOo3.2 is a question, since there are SMB-clients on Solaris that support mmap correctly as it always was expected in OOo implementation.
Re: comment from MAV: [ ... Whether it should be done for OOo3.2 is a question, since there are SMB-clients on Solaris that support mmap correctly as it always was expected in OOo implementation. ] I'm not aware of any SMB client for Solaris that supports mmap. Further mmap may or may not always work on Solaris even on other filesystems, depending on what else is happening with the file. It is simply wrong on Solaris to assume mmap always works.
cc me
Although the problem is not new, it looks to be serious enough to be handled as OOo3.2 showstopper. Adjusting the target.
MD: Confirmed, I see this one as stopper for 3.2
issue 106591 is possibly related
Fixed now in cws fwk132. The fix solves also the problem from issue 106591. I will close the mentioned issue as a duplicate to this one.
*** Issue 106591 has been marked as a duplicate of this issue. ***
mav->jsk: Please verify the issue. In addition please test the scenario from issue 106591 ( the crash using Linux smb-client ).
This bug is not fixed, on my System (Gentoo) I can reproduce the behaviour. Office crash (calls Document Recovery) I mount a smb share with: 1. mount //Windows/home /mnt/Windows/ -t cifs -o domain=<workgroup>,credentials=/etc/autofs/smbfs_user,uid=<user>,gid=<group>,rw,file_mode=0664,dir_mode=0775 Replace the <...> with your values. 2. chdir to /mnt/Windows/... open an office from shell like: 3. /path/to/office/soffice odf-file You will got the Document Recovery. Close the office, chdir to '/' unmount the /mnt/Windows mount the path again with additional options: ',nobrl' (without quotes) maybe you need ',noserverino' also. go back to point 2. Now the document should open.
Change OS Type to Unix, X11
I reopened the issue 106591 and post my information there. The issue 106591 issue is NOT duplicate to this one. Therefore I change the OS back to Solaris. Therefore I change the status back to fixed.
used mount -F smbfs -o dirperms=777,fileperms=777 "//<domain>;<user>:<password>@<server>/<share> /mnt/smb to mount a smb resource. In an OOo320m7 (MWS build) i get the errormessage, in CWS fwk132 the file loads and saves (re-saves) without problems. Verified.
gwr > lla : This issue is really specifically about Oo on Solaris. (Please see my earlier comments including the detailed evaluation.) I suggest you open a new issue for your problem on Linux. Thanks -GWR
Thank you all for your efforts!
cbessios, did you try the fix in a m8? Does it solve the problem for you?
Good from my POV, closing.