NFS, Linux client, OSX server - NFS

This is a discussion on NFS, Linux client, OSX server - NFS ; 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,ha ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: NFS, Linux client, OSX server

  1. 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,ha rd,intr,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.

    --

  2. Re: NFS, Linux client, OSX server

    jb_is_not@home.yet wrote in message news:<2qbbdaFsum9vU1@uni-berlin.de>...
    > 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,ha rd,intr,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=,wsize= 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 Snfslock to init.d/nfslock somewhere
    in the rc subtree (/etc/rc.d/rc.d for RedHat9).

    Good luck with it, rick

  3. Re: NFS, Linux client, OSX server

    jb_is_not@home.yet wrote in message news:<2qbbdaFsum9vU1@uni-berlin.de>...
    >> 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.

  4. Re: 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
    >>
    >> 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=,wsize=
    > 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
    > Snfslock to init.d/nfslock somewhere in the rc subtree
    > (/etc/rc.d/rc.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?

    --

  5. Re: NFS, Linux client, OSX server

    jb_is_not@home.yet wrote in message news:<2qevj3Fuke6pU1@uni-berlin.de>...
    > 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.

  6. Re: NFS, Linux client, OSX server

    Mike Eisler wrote:

    > jb_is_not@home.yet 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.

    --

  7. Re: NFS, Linux client, OSX server

    jb_is_not@home.yet wrote in message news:<2qgq2tFvduvmU1@uni-berlin.de>...
    > Mike Eisler wrote:
    >
    > > jb_is_not@home.yet 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.
    >
    > --


  8. Re: NFS, Linux client, OSX server

    spamisevi1@yahoo.com (Mike Eisler) wrote in message news:<36f0f19f.0409112000.55b12fdf@posting.google.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

  9. Re: NFS, Linux client, OSX server

    Mike Eisler wrote:

    > jb_is_not@home.yet wrote in message
    > news:<2qgq2tFvduvmU1@uni-berlin.de>...
    >> Mike Eisler wrote:
    >>
    >> > jb_is_not@home.yet 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.

    --


+ Reply to Thread