Issue 36634 - [NFS] General input/output error opening file on NFS mount
Summary: [NFS] General input/output error opening file on NFS mount
Status: CLOSED DUPLICATE of issue 53682
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: 680m58
Hardware: PC Linux, all
: P2 Trivial with 13 votes (vote)
Target Milestone: ---
Assignee: thorsten.martens
QA Contact: issues@framework
Keywords: needmoreinfo, oooqa
Depends on:
Reported: 2004-11-04 05:02 UTC by gordonke
Modified: 2005-10-20 00:32 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description gordonke 2004-11-04 05:02:26 UTC
Every time I try to open a file on an NFS automount I get "General input/output 
error while accessing filename". NFS server is another linux box. 
This happens for both word processor and spreadsheet. The same files copied to 
a local directory open fine.
Comment 1 michael.ruess 2004-11-04 06:52:25 UTC
Framework issue.
Comment 2 michael.ruess 2004-11-04 06:53:33 UTC
Comment 3 thackert 2004-12-12 16:59:49 UTC
Have you tried this with a newer version of OOo (1.9.60 or 1.9.62 or some cws builds)? Does it occur 
there also? If not: Could this issue be closed then?
Comment 4 hpollak 2004-12-17 07:12:45 UTC
I have the same problem allso under 1.9.65.

This is a very big trouble for me, cause I use a server share for exchange with
other users, working on the same doc.
Comment 5 ibmail 2005-01-14 03:10:47 UTC
I have the same issue using 1.9.69.  However, 1.1.0 works well with NFS.
Comment 6 gordonke 2005-02-15 22:40:16 UTC
Retested under 1.9.77 and there has been some improvement. 
Documents are now successfully opened Read Only. 
Attempts to save a document (File, Save As) to an NFS share create a 0 byte 
file and the message: 
  Error saving the document <document name>: 
  General Error. 
  General input/output error. 
Comment 7 vandan 2005-02-22 00:55:37 UTC
*** Issue 36634 has been confirmed by votes. ***
Comment 8 vandan 2005-02-22 00:58:14 UTC
I've just hit this issue in OOo 1.9.79 under Linux ( Gentoo, 2.6 kernel ).

I an unable to open any documents on an nfs share - all attempts result in the
"General input / output" error. I have of course made sure I have full ( chmod
777 ) access to the files / folders.

I can also confirm that attempting to save a file results in a 0-byte file and
an input / output error.

I can create files from everything else, eg:

echo "Hi there" >> /mnt/nfs_share/test.txt
Comment 9 hpo 2005-02-28 15:38:05 UTC
This still occurs with OpenOffice 2.0 beta (build 1.9.79, dated 050222). 
Opening a file on an nfs file system yields the following error message: 
"General input/output error while accessing ...." 
Comment 10 hpo 2005-02-28 15:41:42 UTC
This still occurs with OpenOffice 2.0 beta (build 1.9.79, dated 050222). 
Opening a file on an nfs file system yields the following error message: 
"General input/output error while accessing ...." 
Comment 11 schuetzm 2005-03-02 14:22:02 UTC
The error only occurs when file locking is enabled. Setting
SAL_ENABLE_FILE_LOCKING=0 in the soffice script or calling soffice.bin directly
fixes the problem (see also #43795).

I have also noticed that having the configuration on NFS seems a lot slower in
OOo 2.0bc than in 1.1.4.
Comment 12 hpo 2005-03-03 08:58:14 UTC
For me (ooo 2.0 beta) it only works, wenn i call soffice.bin directly. Setting 
SAL_ENABLE_FILE_LOCKING=0 has no effect (still crashes). See also issue #43717 
Comment 13 schuetzm 2005-03-03 10:46:30 UTC
@hpo: You're right, setting SAL_ENABLE_FILE_LOCKING is not enough.
Comment 14 stargaizer 2005-03-08 09:20:04 UTC
@hpo and @schuetzm: comment the two lines with "SAL_ENABLE_FILE_LOCKING=1" and
"export SAL_ENABLE_FILE_LOCKING" in the soffice-script out and it works:-) I use
1.9.79 (2.0 beta).
Comment 15 schuetzm 2005-03-08 10:21:41 UTC
OK, I checked again: setting SAL_ENABLE_FILE_LOCKING=0 has indeed no effect, but
not setting/unsetting it has!
Comment 16 linuxquaker 2005-03-23 03:49:13 UTC
nfs server on fedora 2, client openoffice-1.9.84 on gentoo
when mounted with nfs version = 2, openoffice opens mounted file with noerror
general input/output error only occurs with files in nfs version = 3 mounted
Comment 17 flibby05 2005-04-03 12:08:34 UTC
@linuxquaker: cannot confirm it fails with NFS-3 only.

NFS-3 with Client and Server SuSE 9.2 running updated kernel works for me.

max@linux:/usr/src/linux-2.6.8-24.11> grep NFS .config
# CONFIG_NFS_V4 is not set
# CONFIG_NFSD_V4 is not set
Comment 18 gordonke 2005-04-04 00:27:50 UTC
I originally encountered the "General input/output error while accessing 
filename" problem with a SuSE 8.0 server (kernel 2.4.18) with a SuSE 8.3 client 
(kernel 2.4.??). 
The problem changed to only opening files read only when I upgraded the client 
to SuSE 9.2 (kernel 2.6.8). The server is still 8.0 (2.4.18). 
Comment 19 mci 2005-04-07 13:28:04 UTC
no problem here using NFS Server SuSE Linux (Kernel2.4.19)...
Client SuSE8.2...

I tried m89...
Comment 20 vandan 2005-04-12 07:02:03 UTC
Doesn't work for me. I just tried a OOo-1.9.91 binary on Gentoo Linux, with NFS
v3 shares, and I still get the 'general input/output' error.

Can someone please re-open? I don't seem to have permission for doing that.
Comment 21 schuetzm 2005-04-12 09:55:34 UTC
Why has it been closed at all? There have been several people confirming that it
does not work, but only one stating that he/she can't reproduce it.
Comment 22 flibby05 2005-04-12 12:49:36 UTC
reopen issue
Comment 23 flibby05 2005-04-12 12:51:29 UTC
Comment 24 flibby05 2005-04-12 12:52:10 UTC
Comment 25 flibby05 2005-04-12 12:52:57 UTC
Comment 26 flibby05 2005-04-12 12:57:13 UTC
how to change to Unconfirmed, i don'T know.. normally had no problem with this..
Comment 27 flibby05 2005-04-12 13:03:09 UTC
hi all,
i suggest we accept only reports from setups with from the most recent
distributions running on server _and_ client, such as f.e. 9.2, 9.3; FC 3,4; etc.
NFS is partly kernel dependent and mixing kernel branches at server / client
will not guarantee optimal results by nature. We are volunteers and will
reproduce only on recent distros, developers will also have not much motivation
to fix bugs, which occur only with outdated distros.
thank you,

WorksForMe with SuSE 9.3 on server and client, NFS V3
Comment 28 vandan 2005-04-12 23:28:04 UTC
Want recent systems, eh?
Cool. How about:

 - Gentoo, 2005.0 profile, stable ( non ~x86 ) branch, 2.6.11 kernel,
linux-threads, everything up-to-date as of yesterday

 - Gentoo, 2005.0 profile, unstable ( ~x86 ) branch, 2.6.10 & 2.6.11 kernels,
NPTL, everything up-to-date as of yesterday.
Comment 29 jaltwegg 2005-04-22 09:07:59 UTC
After updating to SuSE 9.3 with their special "Novell" OpenOffice PreVersion 2
(Build any access to NFS paths is broken by the message "general
i/o-eror". In my humble opion this is a serios problem. Especially because
OpenOffice 1.1.4 worked quite well! 

Our file server is key in our environment. Therefore a solution for this issue
would be very appreciated.

Comment 30 ron_dawson 2005-05-04 16:38:07 UTC
I just confirmed this problem with the Solaris (SPARC) 1.9.95 build.  Reading or
saving a file to an NFS share causes the application (and desktop space) to lock
up on a Solaris 8 system. 

I was able to use the following workaround in the "soffice" file.  Commenting
out the following lines that set up file locking allowed me to proceed, but
presumably with file locking disabled.

# file locking now enabled by default

Comment 31 jaltwegg 2005-05-04 17:15:27 UTC
Thank you Ron!

That was the lacking hint! I tried SAL_ENABLE_FILE_LOCKING=0 but that didn't help.
Thus, commenting out *both* lines concerning file locking helped finally for the
SuSE Linux 9.3 issue, too.

Hopefully, there is a better solution for the final version of OOo!
Comment 32 thorstenhirsch 2005-05-22 13:05:46 UTC
Hi, I want to confirm this problem for:

- OOo 1.9.104 (Gentoo ebuild)
- NFS client is my Gentoo machine, absolutely up-to-date :-) (kernel 2.6.11-r6,
gcc 3.4.3)
- NFS server is a Debian Sarge machine with the default kernel 2.6.8-2
Comment 33 mibraun 2005-06-02 16:48:26 UTC

I'm using OOo 2beta (104) (precompiled download von with debian
sarge (linux kernel 2.6.8) on both, server and client.

I get exactly the same problem.
Comment 34 ahimhaim 2005-06-02 18:07:08 UTC
# file locking now enabled by default

This works for me on a 9.0 client and 9.0 server with OO 1.9.104
Comment 35 thorsten.martens 2005-07-01 11:04:56 UTC
Not reproducible in a more recent build like a 680m112, so closed again.
Comment 36 thorsten.martens 2005-07-01 11:09:25 UTC
Comment 37 schuetzm 2005-07-01 12:22:24 UTC
Please reopen the issue, I can reproduce it with 1.9.113.

Opening a file in readonly mode (i.e. chmod 444 or different user) works, but
opening the same file with permissions 644 produces the error described by the
reporter ("General input/output error while accessing ...")
Comment 38 schuetzm 2005-07-06 11:05:37 UTC
Is anyone else except me able to reproduce this bug?
Comment 39 cboltz 2005-07-08 23:34:27 UTC
Werner Merz <suse.merz A T>also reported this problem with m113 in 
german suse-linux mailinglist (Subject: OpenOffice 2.0(beta) & NIS & NFS öffnet 
Dateien nur Readonly; Date: 2005-07-06). 
Comment 40 richlv 2005-07-11 11:03:51 UTC
well, i can reproduce this on two slackware-current boxes with m113.

if needed, i can provide exact kernel/nfsd*/soffice configs, though i can see 
that already this has been done several times.

from the same client 1.1.4 works without any problem (probably because it does 
not lock files by default on nfs ?)
Comment 41 genstef 2005-07-25 20:30:09 UTC
I can reproduce this with openoffice-bin-1.9.118 as well as earlier versions.    
Server and Client are both recent gentoo.    
The workaround works, why not disable locking by default if it is known to    
break NFS?  
The state WORKSFORME is wrong, as it works only with workaround, sorry. 
Please REOPEN 
Any additional info needed to track this bug? 
Portage 1.589-cvs (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 
2.6.12-mm2 i686) 
System uname: 2.6.12-mm2 i686 Intel(R) Pentium(R) 4 CPU 2.50GHz 
Gentoo Base System version 1.7.1 
Portage (uclibc/x86, gcc-3.4.4, uclibc-0.9.27-r0, i586) 
System uname: i586 Pentium 75 - 200 
Gentoo Base System version 1.6.12 
Comment 42 sd98sd89saff 2005-08-14 11:38:43 UTC

bug is still there in 1.9.122, Linux, PC, FC3.

General i/o error writing, reading a nfs share.

Ignoring it or blaming nfs settings/configuration doesn't help. OO is the only
application that shows this behaviour on my box.

What do we have to do to track this one down?

Comment 43 mibraun 2005-08-14 11:55:46 UTC
As i wrote earlier, I had the same problems with OOo 1.9.x.
But after an update of sarge in june 2005, the problem disappeared. The current
OOo 1.9.122 on sarge & FC4 (x86_64) doesn't show the problem to me anymore.
Comment 44 caolanm 2005-08-23 19:20:57 UTC
see #i53682#
Comment 45 caolanm 2005-08-23 19:21:35 UTC

*** This issue has been marked as a duplicate of 53682 ***
Comment 46 caolanm 2005-08-23 19:22:20 UTC
close as dup to issue with patch
Comment 47 gordonke 2005-09-01 07:05:37 UTC
Tested again with OOo 2.0 beta 2 (aka 1.9.125) and files open on NFS shares 
appear to open without error, but read only. Attempts to save files to the NFS 
share gives: "Error saving the document xxx: General Error. General 
Input/Output Error." , even though I have write permissions to the directory. 
NFS client is SuSE 9.2. NFS server is SuSE 8.0. 
Comment 48 gordonke 2005-10-18 23:06:49 UTC
This issue appears to have been subsumed by open issue 54586. 
People with votes here may like to move them to that issue. 
Comment 49 vandan 2005-10-20 00:32:38 UTC
One of the comments in the bug mentioned above says:


It appears that there are two problems:
1  On certain Linux machines, file locking is known to fail due to the NFS lock
demon not running.
2  On certain other Linux machines, it appears that file locking fails due to
some other, not yet analyzed reason.
I would like to keep this issue concentrated on problem 1.
To analyze problem 2, please file a new issue (you can assign it to me) where
you include the output of running strace on soffice.bin (if you run soffice.bin
directly rather than through the soffice script, remember to export


So Issue 54586 will most likely not apply to most people here. Should I report a
*new* bug, and attach an strace log as per the above instructions, or should
this bug be resurrected?