Created attachment 57141 [details] The screen capture of the error - additionally version 3.4 error capture can be produced too Problem description: Can't open or save documents using Libreoffice 3.5 and 3.4 release x64 over NFS v3 mounts. Steps to reproduce: 1. .... Install Libreoffce through yum on F16 or RPM's off libreoffice.org on F15 2. .... Attempt to open or save doc to the network mount 3. .... Error saying "general input/output error has occurred" Current behavior: Error saying "general input/output error has occurred" Expected behavior: Files to open and save like any other application Platform (if different from the browser): Observed on Fedora 15 and 16 x64 clients while connected to backend FreeBSD 8.2 x64 file server running NFS while exporting ZFS pool Browser: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0
Created attachment 57142 [details] Libreoffice 3.4 producing same error for NFS mount on /zr Illustration of the error on Fedora 16 x64
Ok managed to find a fix for this but shouldn't need to be.... Having a quick Google around just now I came across this: http://ubuntuforums.org/showthread.php?t=332043 The fix is to comment out these lines: [code] # file locking now enabled by default #SAL_ENABLE_FILE_LOCKING=1 #export SAL_ENABLE_FILE_LOCKING [/code] Under /usr/bin/soffice - F16 Haven't tested it under F15 just yet but should be similar.... Since I used the RPM's from the libreoffice.org site I'm assuming /opt/libreoffice/soffice but will check as of tomorrow UTC! So there seems to be an issue with File Locking through NFS.....
....and this issue seems to go all the way back to OpenOffice 2.1! No wonder my previous installation of OpenOffice (latest edition whatever it is 3.x) didn't work either!!! Not sure if this is an NFS thing or an (L/O)office thing?
I can confirm this bug. Client: libreoffice-core-3.4.4.2-0.3.mga1 Server: Linux station 2.6.31.8 #14 Tue Apr 5 09:27:42 JST 2011 armv5tel GNU/Linux Debian Squeeze (6.0.5) Additionally this bug has already been described in 2010 at <http://kefk.org/blog/2010/10/20/networking_mit_dem_qnap_ts_859_pro_turbo_nas#Zugriffsprobleme>
This seams to be related or even a duplicate to Bug 36852.
(In reply to comment #4) > I can confirm this bug. I found the reason - at least on my system: Loading/saving fails if the share is mounted using the "lock" option, but works if the share is mounted with "nolock". See bug 50276 comment 2 for details.
(In reply to comment #6) Bug 36852 comment 0 points to a workaround: Not setting "SAL_ENABLE_FILE_LOCKING" at all in the file/script `soffice`. I can confirm this workaround to work.
marking this as a dupe of the earlier bug report *** This bug has been marked as a duplicate of bug 36852 ***