# NFS: reading directory .: Input/output error [SOLVED]

## synt4x

Here is my NFS setup:

Server: Apple OSX 10.4 (with all latest software updates) Xserve, exporting the share as READ ONLY

Client: Linux proto 2.6.11-hardened-r15 #2 SMP Fri Aug 26 15:14:08 CDT 2005 i686 Intel(R) Xeon(TM) CPU 3.00GHz GenuineIntel GNU/Linux

The directory is mounted as:

192.168.1.11:/Volumes/Sack      /files  nfs     ro,rsize=1024,hard,intr,tcp,nosuid

For about one quarter of my directories on the NFS share, when attempting to get a file listing with something like `find` or `ls`, I will not be able to get the directory contents.  The error:

NFS: reading directory .: Input/output error

This does not happen on my other NFS clients, including

Debian 2.4 machine running GRSec

Other Apple 10.4 clients

Here is the interesting part.  These input/output errors will disappear and the directory will become readable if:

* I `touch` the directory on the server, or do anything that would update the timestamp on the directory.  This includes adding a file, renaming a file, etc.

* If I `ls` or other operations on any of the other NFS clients.

However, periodically (I have not established an average time or anything else) the input/output errors will reappear on the Gentoo client.

Can anyone help me diagnose this?  It seems to be specific to the Gentoo client itself.  If it makes a difference, Apple's NFS is 64 bit as of 10.4.

Solution!!

Compiling the kernel with only NFS2 and not including NFS3 makes this work.  Don't know why.Last edited by synt4x on Thu Feb 02, 2006 8:16 pm; edited 1 time in total

----------

## synt4x

Other important notes:

* I just re-emerged nfs-utils and linux-utils, and didn't experience any changes

* Despite the previous step, I still get this in my kern.log:  nfs warning: mount version older than kernel

Also, to help hone in an on the problem, I ran an `strace` of `ls`:

```
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3

fstat64(3, {st_mode=S_IFDIR|0775, st_size=10336, ...}) = 0

fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0

getdents64(3, 0x17b2b76c, 32768)        = -1 EIO (Input/output error)

close(3)                                = 0

write(2, "ls: ", 4ls: )                     = 4

write(2, "reading directory .", 19reading directory .)     = 19

write(2, ": Input/output error", 20: Input/output error)    = 20

write(2, "\n", 1

)                       = 1

exit_group(1)                           = ?
```

----------

## synt4x

Yet another update:

I just installed a 2005.1 server from scratch, and it does not exhibit the same problems.  The servers are identical except for:

* The server with problems uses gcc 3.4.4.  I need this as this version of gcc creates its binaries such that they all support 64 bit large files successfully somehow, and the NFS exported from the OSX machine is 64 bit.  If I use a previous version of GCC, applications not written for LFS (apache, php, etc) can not read directories successfully -- getdents returns empty.

* The server with problems has much more aggressive CFLAGS, as the portage configuration was based on "jackass".  I'm attempting to trim down the problematic server down to just O2 and pipe

I'm going to give the whole thing a emerge -e world and I'll see what happens.  I'm also updating gcc 3.4.4 to 3.4.4-r1 (I originally had 3.4.4 manually keyworded for ~x86)

Hopefully it'll be all recompiled by the time I get back from Thanksgiving.

----------

## synt4x

Downgrading gcc to 3.3.6 and re-emerging world and recompiling the kernel has not fixed this either.  Does *anyone* have any ideas?

----------

## synt4x

I just reinstalled my machine, and this error is still occurring.  Does anyone have *any* ideas?

----------

## synt4x

This is likely a bug with OSX's NFSd.  Disabling the NFS v3 client in your kernel config will prevent this behavior from occurring.

----------

## mar10s

I had a similar thing. Try adding the no_root_squash option to your /etc/exports. For details, see man exports.

HTH,

mar10s

----------

