NFS, Linux client, OSX server

Mounting an export from an OSX server. The Linux client, running gentoo,
is 192.168.1.100. Trying to share via NFS a partition, Volumes/Alien,
on a disk connected to the Mac via firewire.**Everything*I*can*think*of
looks OK:

# cat /proc/mounts
192.168.1.102:/Volumes/Alien /mnt/alien nfs
*****rw,nosuid,nodev,v3,rsize=16384,wsize=16384,hard,in tr,udp,lock,
*****addr=192.168.1.102**0*0

# showmount -e 192.168.1.102
Export list for 192.168.1.102:
/Volumes/Alien 192.168.1.0

root:: # rpcinfo -p 192.168.1.102
***program*vers*proto***port
****100000****2***tcp****111**portmapper
****100000****2***udp****111**portmapper
****100024****1***udp***1021**status
****100024****1***tcp****934**status
****100021****0***udp***1008**nlockmgr
****100021****1***udp***1008**nlockmgr
****100021****3***udp***1008**nlockmgr
****100021****4***udp***1008**nlockmgr
****100021****0***tcp****923**nlockmgr
****100021****1***tcp****923**nlockmgr
****100021****3***tcp****923**nlockmgr
****100021****4***tcp****923**nlockmgr
****100005****1***udp****989**mountd
****100005****3***udp****989**mountd
****100005****1***tcp****909**mountd
****100005****3***tcp****909**mountd
****100003****2***udp***2049**nfs
****100003****3***udp***2049**nfs
****100003****2***tcp***2049**nfs
****100003****3***tcp***2049**nfs

# rpcinfo -u 192.168.1.102 nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting

rpcinfo -p 192.168.1.100
***program*vers*proto***port
****100000****2***tcp****111**portmapper
****100000****2***udp****111**portmapper
****100021****1***udp**32768**nlockmgr
****100021****3***udp**32768**nlockmgr
****100021****4***udp**32768**nlockmgr

uid/gid is the same on both boxes.**But,*I*can't*read*the*mount:

ls -al /mnt/alien
ls: reading directory /mnt/alien: Input/output error
total 0

Any advice, regarding Linux or even OSX, greatly appreciated.**Thanks.

--

(E-Mail Removed) wrote in message news:<(E-Mail Removed)>...
> Mounting an export from an OSX server. The Linux client, running gentoo,
> is 192.168.1.100. Trying to share via NFS a partition, Volumes/Alien,
> on a disk connected to the Mac via firewire.**Everything*I*can*think*of
> looks OK:
>
> # cat /proc/mounts
> 192.168.1.102:/Volumes/Alien /mnt/alien nfs
> *****rw,nosuid,nodev,v3,rsize=16384,wsize=16384,hard,in tr,udp,lock,
> *****addr=192.168.1.102**0*0
>
A couple of thoughts:
1 - I'd try a smaller rsize,wsize (8192 or maybe even 1024) and see if that
helps (alternately, switch to tcp). rsize=<NNNN>,wsize=<NNNN> options
on the Linux mount command.
2 - We have lots of Linux clients talking to BSD servers (which aren't that
different than OSX, I suspect), but I avoid use of the lock manager like
the plague. Unless you really need file locking, I'd just get rid of the
lock manager on the Linux client (called rpc.statd on RedHat9). It's
started via symbolic links called S<nn>nfslock to init.d/nfslock somewhere
in the rc subtree (/etc/rc.d/rc<N>.d for RedHat9).

Good luck with it, rick

(E-Mail Removed) wrote in message news:<(E-Mail Removed)>...
>> ls -al /mnt/alien
> ls: reading directory /mnt/alien: Input/output error
> total 0

You don't mention if you can doing any else, such as cd, read, write,
mkdir, etc.

Assuming it is ls (readdir) that is just giving you
problems, a shot in the dark is that the server doesn't like
the client's transfer size request. Try set rdsize and reducing it
downward to see if that helps.

>> Mounting an export from an OSX server. The Linux client, running
>> gentoo, is 192.168.1.100. Trying to share via NFS a partition,
>> Volumes/Alien, on a disk connected to the Mac via firewire.*
>> Everything*I*can*think*of looks OK:
>>
>> # cat /proc/mounts
>> 192.168.1.102:/Volumes/Alien /mnt/alien nfs
>> rw,nosuid,nodev,v3,rsize=16384,wsize=16384,hard,in tr,udp,lock,
>> addr=192.168.1.102**0*0
>>
>> But,*I*can't*read*the*mount:
>> ls -al /mnt/alien
>> ls: reading directory /mnt/alien: Input/output error
>> total 0

Mike Eisler wrote:

> You don't mention if you can doing any else, such as cd, read, write,
> mkdir, etc.

> Assuming it is ls (readdir) that is just giving you
> problems, a shot in the dark is that the server doesn't like
> the client's transfer size request. Try set rdsize and reducing it
> downward to see if that helps.

It didn't occur to me that any of that would work, but they all do - I
can cd, write, read, mv, cp, mkdir, etc. So, yes, the only problem is
ls. I'm not familiar with "rdsize" at all.

Rick Macklem wrote:

> A couple of thoughts:
> 1 - I'd try a smaller rsize,wsize (8192 or maybe even 1024) and see if
> that
> helps (alternately, switch to tcp). rsize=<NNNN>,wsize=<NNNN>
> options on the Linux mount command.
> 2 - We have lots of Linux clients talking to BSD servers (which aren't
> that
> different than OSX, I suspect), but I avoid use of the lock
> manager like the plague. Unless you really need file locking, I'd
> just get rid of the lock manager on the Linux client (called
> rpc.statd on RedHat9). It's started via symbolic links called
> S<nn>nfslock to init.d/nfslock somewhere in the rc subtree
> (/etc/rc.d/rc<N>.d for RedHat9).

I don't have Redhat - Gentoo here. I tried your recommendations just
now - changed fstab to:

192.168.1.102:/Volumes/Alien /mnt/alien nfs
user,exec,rw,tcp,nolock,intr 0 0

Also tried w/o tcp but r/wsize set to 1024. Even tried w/ tcp and the
r/w size. No go - same ls error. Thanks for responding. At least the
problem's getting narrowed. Any other ideas?

--

(E-Mail Removed) wrote in message news:<(E-Mail Removed)>...
> Mike Eisler wrote:
>
> > You don't mention if you can doing any else, such as cd, read, write,
> > mkdir, etc.
>
> > Assuming it is ls (readdir) that is just giving you
> > problems, a shot in the dark is that the server doesn't like
> > the client's transfer size request. Try set rdsize and reducing it
> > downward to see if that helps.
>
> It didn't occur to me that any of that would work, but they all do - I
> can cd, write, read, mv, cp, mkdir, etc. So, yes, the only problem is
> ls. I'm not familiar with "rdsize" at all.

Sorry, typo. I meant rsize.

> Also tried w/o tcp but r/wsize set to 1024. Even tried w/ tcp and the
> r/w size. No go - same ls error. Thanks for responding. At least the
> problem's getting narrowed. Any other ideas?

Capture the network traffic, and look at it with ethereal.
If the server is returning an error from READDIR, that would be interesting.

Mike Eisler wrote:

> (E-Mail Removed) wrote:
>
>> Also tried w/o tcp but r/wsize set to 1024. Even tried w/ tcp and the
>> r/w size. No go - same ls error. Thanks for responding. At least
>> the
>> problem's getting narrowed. Any other ideas?
>
> Capture the network traffic, and look at it with ethereal.
> If the server is returning an error from READDIR, that would be
> interesting.

I installed ethereal and ran it. I'm afraid I'm at a loss as to how to
interpret the results, and the output is too long to post. However,
the following seem relevant to this untrained eye:

===================================
Remote Procedure call, Type: Reply XID:0x9b8635a4
XID: 0x9b8635a4 (2609264036)
Message Type: Reply (1)
Program: NFS (100003)
Program Version: 3
Procedure: READDIRPLUS (17)
Reply State: accepted (0)
This is a reply to a request in frame 10 <===underlined & in blue
Time from request: 0.000194000 seconds

.. . . .
Network File System, READDIRPLUS reply Error:Err_IO
Program Version: 3
V3 Procedure: READDIRPLUS (17)
Status: ERR_IO (5)

attributes
Type: Directory (2)
mode: 777
. . . .
nlink: 5
uid 1000
gid 100
size: 1024
used: 1024
===================================
cat /proc/mounts
192.168.1.102:/Volumes/Alien /mnt/alien nfs
rw,nosuid,nodev,v3,rsize=8192,wsize=8192,hard,intr ,udp,lock,addr=192.168.1.102
0 0

Any advice appreciated. Thanks.

--

(E-Mail Removed) wrote in message news:<(E-Mail Removed)>...
> Mike Eisler wrote:
>
> > (E-Mail Removed) wrote:
> >
> >> Also tried w/o tcp but r/wsize set to 1024. Even tried w/ tcp and the
> >> r/w size. No go - same ls error. Thanks for responding. At least
> >> the
> >> problem's getting narrowed. Any other ideas?
> >
> > Capture the network traffic, and look at it with ethereal.
> > If the server is returning an error from READDIR, that would be
> > interesting.
>
> I installed ethereal and ran it. I'm afraid I'm at a loss as to how to
> interpret the results, and the output is too long to post. However,
> the following seem relevant to this untrained eye:
>
> ===================================
> Remote Procedure call, Type: Reply XID:0x9b8635a4
> XID: 0x9b8635a4 (2609264036)
> Message Type: Reply (1)
> Program: NFS (100003)
> Program Version: 3
> Procedure: READDIRPLUS (17)
> Reply State: accepted (0)
> This is a reply to a request in frame 10 <===underlined & in blue
> Time from request: 0.000194000 seconds
>
> . . . .
> Network File System, READDIRPLUS reply Error:Err_IO
> Program Version: 3
> V3 Procedure: READDIRPLUS (17)
> Status: ERR_IO (5)

So this saying the NFS server doesn't like the request or doesn't
like the directory. If you could cut and paste the READDIRPLUS
request fields in what should be the previous packet, that might
help (it would probably help Rick, since the OSX server is probably
derived from his server).

It is possible the server is in the right, and client is in the wrong.
I forget if you mentioned which Linux kernel you are running.
Note that Trond, the NFS client maintainer, always has a set of
latest patches, and you will probably want to make sure you've
got the latest stuff.
>
> attributes
> Type: Directory (2)
> mode: 777
> . . . .
> nlink: 5
> uid 1000
> gid 100
> size: 1024
> used: 1024
> ===================================
> cat /proc/mounts
> 192.168.1.102:/Volumes/Alien /mnt/alien nfs
> rw,nosuid,nodev,v3,rsize=8192,wsize=8192,hard,intr ,udp,lock,addr=192.168.1.102
> 0 0
>
> Any advice appreciated. Thanks.
>
> --

(E-Mail Removed) (Mike Eisler) wrote in message news:<(E-Mail Removed). com>...
> > Network File System, READDIRPLUS reply Error:Err_IO
>
> So this saying the NFS server doesn't like the request or doesn't
> like the directory. If you could cut and paste the READDIRPLUS
> request fields in what should be the previous packet, that might
> help (it would probably help Rick, since the OSX server is probably
> derived from his server).
>
In cases like these, I'd argue "derived from" is an acronym for "has broken".:-)
My code doesn't generate EIO anywhere in the Readdirplus, so they've either
added that feature or it's coming from the underlying file system (assuming
their code is derived from BSD).

I noticed in another post that you mentioned "cd"? If this is a file system
on a CD, you might try copying files to the hard drive and exporting that?

Otherwise, I think you might want to talk to Apple about it.

Good luck with it, rick

Mike Eisler wrote:

> (E-Mail Removed) wrote in message
> news:<(E-Mail Removed)>...
>> Mike Eisler wrote:
>>
>> > (E-Mail Removed) wrote:
>> Status: ERR_IO (5)
>
> So this saying the NFS server doesn't like the request or doesn't
> like the directory. If you could cut and paste the READDIRPLUS
> request fields in what should be the previous packet, that might
> help (it would probably help Rick, since the OSX server is probably
> derived from his server).

I hope this is the right one:

Remote Procedure Call, Type:Call XID: 0x9a8635a4
XID: 0x9a8635a4 (2592486820
Message Type: Call (0)
RPC Version: 2
Program: NFS (100003)
Program Version: 3
Procedure: ACCESS (4)
The reply to this request is in frame 9
.. . . .
Network File System, ACCESS Call FH:0x9e1fb9da
Program Version: 3
V3 Procedure: Access (4)
object
length: 28
hash: 0x9e1fb9da
type: unknown
data: 0E00000F0000000C00000000002
411BDCDB0000000000000000
access: 0x01
.... .1 = allow READ
.... 0. = not allow LOOKUP
...0 .. = not allow MODIFY
..0. .. = not allow EXTEND
.0.. .. = not allow DELETE
0... .. = not allow EXECUTE

Again, I don't know how to read this stuff, and thus don't really know
what to post. The above seems to show errors, so that's what I chose.

> It is possible the server is in the right, and client is in the wrong.
> I forget if you mentioned which Linux kernel you are running.
> Note that Trond, the NFS client maintainer, always has a set of
> latest patches, and you will probably want to make sure you've
> got the latest stuff.

No, I didn't mention it. I run Gentoo, and the kernel is
gentoo-dev-sources 2.6.7-r12. I compiled it myself, but it does have
Gentoo patches in it. I don't know exactly what patches Gentoo
applied. I'll try to find out. I couldn't find Trond's patches. I'm
afraid I'm getting way over my head here.

--