OpenOffice freezes when opening documents from NFS-server (in SuSe 10.1)
 

First of all I have to remind here, that I have commented out the lines concerning "SAL_ENABLE_FILE_LOCKING" from the soffice-script. This is not the same issue, what many people have been posting. And I have only seen this problem with SuSe 10.1, with all other distros it works with the same OpenOffice.org-version (2.0.2).

NFS-server
SimpleTech SimpleShare NAS with the latest firmware.

NFS-clients
Mandriva 2006 and SuSe 10.1. The NFS-drive is mounted with the following options: rw,nosuid,hard,intr,rsize=8192,wsize=8192

The problem
When trying to open anything from the mounted NFS-drive with OpenOffice.org in SuSe 10.1, it loads up to the last point in the splash screen's progress bar, then completely freezes. 10 - 20 minutes later I command "killall soffice.bin", as it hasn't gone anywhere. I have tried to open the documents by double-clicking it from a file manager (Konqueror/Nautilus), from the command-line ("ooffice document", will not give any errors or debug-info) and with File->Open from OpenOffice.org itself, all with the same result.

In Mandriva OOo 2.0.2 (installed from the official OOo-site, the RPM-packages) opens documents from the NFS-drive perfectly, but not in SuSe. Tried also uninstalling the SuSe OOo-packages and installing the same RPM-packages from the official OOo-site, what I use in Mandriva. Same result.

Conclusion
I can open local documents, no problem there. Haven't tried Samba. All other programs than OpenOffice.org work perfectly with the NFS-drive in SuSe 10.1. Opening files with OpenOffice.org from NFS-drives won't work, but this only happens in SuSe 10.1. This is a serious issue that prevents me from switching to SuSe. Would be really grateful if someone has a slightest idea of what might be wrong here.

Solution
Add "nolock"-option to NFS-mount options on the client side. So:
Also remember to comment out the "SAL_ENABLE_FILE_LOCKING"-lines (2 of them) from /usr/lib/ooo-2.0/program/soffice. That is, of course, unless you are really using NFS-locking.

There is a reported bug at
https://bugzilla.novell.com/show_bug.cgi?id=104655

does it relate to your problem ?

Unfortunately not. OpenOffice doesn't give me any errors, like in that bug's description. And that bug was "resolved in beta 4".

Now I've found out that sometimes it does open the document from an NFS-drive. But after like 25 - 40 minutes! Even if the document has just one line of text and is not even nearly 100 kb big. It is definitely not usable like this. Saving the document again takes just as long.

but the file does open ? strange.
did you post on the OO/SuSE bugtracker ?

(since OO is the only application with trouble perhaps it makes some wrong assuptions)
(same goes for suse)

do have a change to test it with a linux NFS server ?
(if no i would guess its the NfS server)

long shot: can you check the file locking ?
(mount with nolock)

Surprisingly it works when I set a Mandriva-PC as an NFS-server! But this NAS-device also runs internally Linux, and the Mandriva-computers have no problems whatsoever opening OpenOffice.org-documents from there, so the problem is somehow still related to SuSe. And changing the NAS-device is no option anyways.

I haven't posted the problem as a bug so far.

Problem solved!

The "nolock"-option for some reason beyond my understanding fixed the whole thing! Why Mandriva doesn't require that, is completely unknown to me. After all, I HAD disabled NFS-locking ("SAL_ENABLE_FILE_LOCKING" commented out) already from OpenOffice itself and this was enough with Mandriva.

At first I thought the "nolock"-option did nothing, but I soon noticed that it was still getting the old automounter-settings from the NSCD-cache. I am using LDAP in the network, which also provides the automounter with the necessary mountpoints to the NAS-device.

Big thanks to grumpf!

nice to hear, can you take a look if the lockd is running ?

It's not running. I don't use NFS-locking and have disabled it also from the client side.

Hi,

I reported the problem almost 5 months ago.
https://bugzilla.novell.com/show_bug.cgi?id=175918

Good to know you found a work-around for your setup. I don't think it the best option though to rely on this work-around in general.