Apache OpenOffice (AOO) Bugzilla – Issue 36634
[NFS] General input/output error opening file on NFS mount
Last modified: 2005-10-20 00:32:39 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.
Framework issue.
.
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?
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.
I have the same issue using 1.9.69. However, 1.1.0 works well with NFS.
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.
*** Issue 36634 has been confirmed by votes. ***
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
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 ...."
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.
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
@hpo: You're right, setting SAL_ENABLE_FILE_LOCKING is not enough.
@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).
OK, I checked again: setting SAL_ENABLE_FILE_LOCKING=0 has indeed no effect, but not setting/unsetting it has!
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 volumes.
@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_FS=y CONFIG_NFS_V3=y CONFIG_NFS_ACL=y # CONFIG_NFS_V4 is not set CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_ACL=y CONFIG_NFS_ACL_SUPPORT=y # CONFIG_NFSD_V4 is not set CONFIG_NFSD_TCP=y CONFIG_NCPFS_NFS_NS=y
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).
no problem here using NFS Server SuSE Linux (Kernel2.4.19)... Client SuSE8.2... I tried m89...
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.
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.
reopen issue
how to change to Unconfirmed, i don'T know.. normally had no problem with this..
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, Max WorksForMe with SuSE 9.3 on server and client, NFS V3
Want recent systems, eh? Cool. How about: Server: - Gentoo, 2005.0 profile, stable ( non ~x86 ) branch, 2.6.11 kernel, linux-threads, everything up-to-date as of yesterday Clients: - Gentoo, 2005.0 profile, unstable ( ~x86 ) branch, 2.6.10 & 2.6.11 kernels, NPTL, everything up-to-date as of yesterday.
After updating to SuSE 9.3 with their special "Novell" OpenOffice PreVersion 2 (Build 1.9.97.2.3) 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. Thanx!
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 #SAL_ENABLE_FILE_LOCKING=1 #export SAL_ENABLE_FILE_LOCKING
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!
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
Hi, I'm using OOo 2beta (104) (precompiled download von openoffice.org) with debian sarge (linux kernel 2.6.8) on both, server and client. I get exactly the same problem.
# file locking now enabled by default #SAL_ENABLE_FILE_LOCKING=1 #export SAL_ENABLE_FILE_LOCKING This works for me on a 9.0 client and 9.0 server with OO 1.9.104
Not reproducible in a more recent build like a 680m112, so closed again.
closed
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 ...")
Is anyone else except me able to reproduce this bug?
Werner Merz <suse.merz A T bluewin.ch>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).
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 ?)
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? Client: 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 Server: Portage 2.0.51.22-r1 (uclibc/x86, gcc-3.4.4, uclibc-0.9.27-r0, 2.6.11.4 i586) ================================================================= System uname: 2.6.11.4 i586 Pentium 75 - 200 Gentoo Base System version 1.6.12
Hi, 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?
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.
see #i53682#
. *** This issue has been marked as a duplicate of 53682 ***
close as dup to issue with patch
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.
This issue appears to have been subsumed by open issue 54586. People with votes here may like to move them to that issue.
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 SAL_ENABLE_FILE_LOCKING!). --- 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?