I was unable to reproduce the issue using the following OOo packages included in openSUSE 10.2 RC5:

OpenOffice_org-templates-en-2.0.4-10
OpenOffice_org-templates-presentation-layouts-2.0.4-10
OpenOffice_org-2.0.4-38
OpenOffice_org-templates-labels-a4-1.0-3
OpenOffice_org-templates-labels-letter-1.0-3
OpenOffice_org-gnome-2.0.4-38

Below are the steps I took

On a remote SLES10 server I configured a read-write NFS mount point by doing the following:
- Modified and saved /etc/exports by adding the following line
/home/erw 137.65.170.40(rw,sync)

- After saving the /etc/exports changes, I restarted the nfsserver
/etc/init.d/nfsserver restart

- From my openSUSE 10.2 RC5 client machine I mounted the nfs share
sudo mount -t nfs 151.155.173.44:/home/erw /mnt/nfs

- From the client machine I opened an existing OpenOffice.org document from the nfs mount point, modified the file, and proceeded to save it.
oowriter /mnt/nfs/SLED_10_SP1_v0.6aaaaa.odt


NOTE: Only when I specified the nfs export options with the "ro" option did I see OOo open the documents in read-only mode.

Mark - Could you either try the newer packages to see if they resolve your issue, or provide more details about your environment and the steps you take to reproduce the issue?

I can still reproduce the problem on Suse 10.1 with the following packages installed:

OpenOffice_org-galleries-2.0.4-1.2
OpenOffice_org-kde-2.0.4-1.2
OpenOffice_org-nl-2.0.4-1.2
OpenOffice_org-2.0.4-1.2

It's not just me:
http://www.suseforums.net/index.php?showtopic=27341
http://www.linuxquestions.org/questions/showthread.php?t=501606

My nfs server runs Suse 9.3.

exports line:
/home   *(rw,no_root_squash,async)

fstab line:
192.168.10.254:/home        /mnt/mozart.site/home          nfs     bg,user,auto 0 0

Various references I have found to this problem suggest that OpenOffice is attempting and failing to lock the file. The linuxquestions link above mentioned that rpc.statd might play a role, however it's not clear to me where rpc.statd is on a Suse system.

I note that OpenOffice 2.0.4 is the only program that shows this problem.

My opinion is that OpenOffice should display a warning instead of just reverting to read-only mode, even in a situation where all of the following are true:
1) OpenOffice really needs to lock the file
2) Some problem in the nfs setup prevents OpenOffice from locking the file

Kendy, I presume you can handle this as part of the locking bug.

JP - I was unable to duplicate the issue when attempting to open a odt document from a SLES10 SP1 nfs mount point that was configured with the same nfs and fstab options as coment #3. Here are the relevant nfs packages installed on the SLES10 SP1 server:
# rpm -qa|grep -i nfs |sort
limal-nfs-server-1.1.57-0.5
limal-nfs-server-perl-1.1.57-0.5
nfsidmap-0.12-16.12
nfs-utils-1.0.7-36.21
yast2-nfs-client-2.13.4-0.11
yast2-nfs-server-2.13.8-0.7


Below are the following client platforms and OOo versions I tested against this nfs server:

openSUSE 10.2
> rpm -qa|grep -i openoffice |sort
OpenOffice_org-2.0.4-38.5
OpenOffice_org-gnome-2.0.4-38.5
OpenOffice_org-templates-en-2.0.4-10
OpenOffice_org-templates-labels-a4-1.0-3
OpenOffice_org-templates-labels-letter-1.0-3
OpenOffice_org-templates-presentation-layouts-2.0.4-10

SLED10SP1
> rpm -qa|grep -i openoffice |sort
OpenOffice_org-2.1-0.26
OpenOffice_org-gnome-2.1-0.26
OpenOffice_org-kde-2.1-0.26
OpenOffice_org-nld-2.1-0.26
OpenOffice_org-pl-2.1-0.26
OpenOffice_org-Quickstarter-1.0-485.2

openSUSE 10.3 alpha7
# rpm -qa|grep -i openoffice |sort
OpenOffice_org-2.2.99.224-2
OpenOffice_org-base-2.2.99.224-2
OpenOffice_org-calc-2.2.99.224-2
OpenOffice_org-draw-2.2.99.224-2
OpenOffice_org-filters-2.2.99.224-2
OpenOffice_org-hyphen-20070719-5
OpenOffice_org-icon-themes-2.2.99.224-2
OpenOffice_org-impress-2.2.99.224-2
OpenOffice_org-mailmerge-2.2.99.224-2
OpenOffice_org-math-2.2.99.224-2
OpenOffice_org-pyuno-2.2.99.224-2
OpenOffice_org-templates-en-2.0.4-42
OpenOffice_org-templates-labels-a4-1.0-2
OpenOffice_org-templates-labels-letter-1.0-2
OpenOffice_org-templates-presentation-layouts-2.0.4-44
OpenOffice_org-thesaurus-en-20060111-5
OpenOffice_org-writer-2.2.99.224-2


Since SUSE 9.3 is no longer supported based on the following URL:
http://en.opensuse.org/SUSE_Linux_Lifetime

It may be worth it to update your server to a supported version and see if your still able to reproduce the issue.

IIRC, some implementations of NFS has an ugly issue with byte-range locking, where the NFS server returns the wrong info to the client application which leads to the client app receiving a read-lock even though it requested a write-lock.

There is obviously a workaround for this, that is to comment out the following lines from soffice

  # file locking now enabled by default
  SAL_ENABLE_FILE_LOCKING=1
  export SAL_ENABLE_FILE_LOCKING

Also, some implementation of NFS requires a NFS lock daemon running on the client side for this kind of stuff to work properly.

The reporter mentioned that other apps don't have this problem.  It's also *possible* that those other apps don't implement byte-range lock, therefore don't exhibit this problem.

I have *the same* problem over here !

OS: openSUSE 11.0 BETA2, i386.

I have mounted NFS share as RW, and all programs can use that share as RW, _except_ OpenOffice.

I use OpenOffice 2.4, which is part of openSUSE 11.0.

This is really a very serious bug, because it prevents normal workflow in networked environment.

-Alexey "Technologov", 25.5.2008.

I have tried:
SAL_ENABLE_FILE_LOCKING=1
export SAL_ENABLE_FILE_LOCKING

And it has zero effect...

-Alexey "Technologov", 25.5.2008.

Alexey: Can you please re-try with Beta3?  There was a problem with NFS locking on Beta2 (see eg. bug 384481) which should be resolved now.

If you experience the problem with Beta3 as well, please tell us _exactly_ how do you mount the share, and provide us with strace log of the failing case as described in http://en.opensuse.org/Bugs:OOo#How_to_get_strace_log

No more info provided, and it really looks like a duplicate of the abovementioned bug, so setting it to state 'resolved duplicate'.

Please feel free to reopen if you think that the bug is still there.

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