Issue 104974 - Error saving document on smbfs: Could not create backup copy
Summary: Error saving document on smbfs: Could not create backup copy
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOO310m11
Hardware: PC Solaris
: P3 Trivial with 1 vote (vote)
Target Milestone: OOo 3.2
Assignee: joerg.skottke
QA Contact: issues@framework
Depends on:
Blocks: 99999
  Show dependency tree
Reported: 2009-09-11 08:51 UTC by cbessios
Modified: 2010-01-12 09:46 UTC (History)
7 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description cbessios 2009-09-11 08:51:31 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.
Comment 1 wkdv_ray 2009-11-20 14:43:53 UTC
Same issue here, but for all types of documents (not only spreadsheets). Running
OpenSolaris 2009.06 x86.
Comment 2 gwr 2009-12-08 18:39:29 UTC
This defect has also been reported here:
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.
Comment 3 gwr 2009-12-08 18:49:35 UTC
This is an OpenOffice issue, described here:
Comment 4 mdxonefour 2009-12-09 14:54:50 UTC
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!?
Comment 5 mikhail.voytenko 2009-12-09 15:23:57 UTC
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.
Comment 6 mikhail.voytenko 2009-12-09 15:30:06 UTC
Confirming the issue, since gwr is right, we should have a fallback for the case
that mmap does not work.
Comment 7 mikhail.voytenko 2009-12-09 15:30:53 UTC
Adjusting the target.
Comment 8 gwr 2009-12-09 16:06:15 UTC
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.
Comment 9 mikhail.voytenko 2009-12-09 16:33:53 UTC
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.
Comment 10 mikhail.voytenko 2009-12-09 20:24:54 UTC
mav->gwr: Oh, it was about summary reverting, not about comment reverting. Sorry
for misunderstanding.
Comment 11 mikhail.voytenko 2009-12-09 20:49:54 UTC
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
Comment 12 gwr 2009-12-09 23:05:37 UTC
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.

Comment 13 joerg.skottke 2009-12-10 12:46:58 UTC
cc me
Comment 14 mikhail.voytenko 2009-12-10 15:50:09 UTC
Although the problem is not new, it looks to be serious enough to be handled as
OOo3.2 showstopper. Adjusting the target.
Comment 15 mdxonefour 2009-12-10 16:07:02 UTC
MD: Confirmed, I see this one as stopper for 3.2
Comment 16 caolanm 2009-12-10 16:29:11 UTC
issue 106591 is possibly related
Comment 17 mikhail.voytenko 2009-12-12 08:51:11 UTC
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.
Comment 18 mikhail.voytenko 2009-12-12 09:01:20 UTC
*** Issue 106591 has been marked as a duplicate of this issue. ***
Comment 19 mikhail.voytenko 2009-12-12 09:03:59 UTC
mav->jsk: Please verify the issue. In addition please test the scenario from
issue 106591 ( the crash using Linux smb-client ).
Comment 20 lars.langhans 2009-12-14 07:46:55 UTC
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

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.
Comment 21 lars.langhans 2009-12-14 07:49:38 UTC
Change OS Type to Unix, X11
Comment 22 lars.langhans 2009-12-14 08:14:59 UTC
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.

Comment 23 joerg.skottke 2009-12-14 10:31:23 UTC

    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.

Comment 24 gwr 2009-12-14 14:44:02 UTC
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
Comment 25 cbessios 2009-12-15 07:02:06 UTC
Thank you all for your efforts!
Comment 26 joerg.skottke 2010-01-04 13:54:01 UTC

did you try the fix in a m8? Does it solve the problem for you?
Comment 27 joerg.skottke 2010-01-12 09:46:10 UTC
Good from my POV, closing.