Date: Sun, 26 Sep 2010 16:01:14 -0400 From: Mike Meyer <mike.w.meyer@gmail.com> To: Robert Bonomi <bonomi@mail.r-bonomi.com> Cc: questions@freebsd.org Subject: Re: Problems mounting nfs from freebsd to Mac. Message-ID: <20100926160114.0d97a56c@bhuda.mired.org> In-Reply-To: <201009251958.o8PJwLd0027577@mail.r-bonomi.com> References: <201009251958.o8PJwLd0027577@mail.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 25 Sep 2010 14:58:21 -0500 (CDT)
Robert Bonomi <bonomi@mail.r-bonomi.com> wrote:
> > From owner-freebsd-questions@freebsd.org Sat Sep 25 03:29:33 2010
> > Date: Sat, 25 Sep 2010 04:01:18 -0400
> > From: Mike Meyer <mike.w.meyer@gmail.com>
> > To: questions@freebsd.org
> > Cc:
> > Subject: Problems mounting nfs from freebsd to Mac.
> >
> > I've got an nfs server that's refusing to mount one client - via one
> > route - and it's driving me crazy.
>
> First question, are you _SURE_ that it's a server-side problem? I under-
> stand that things are failing in one situation and not others, but there
> are about -five- possible causations, only one of which is a server-side
> NFS configuration.
No, I'm not sure. The question is more "what server tools can I use
figure out what's wrong" than "how do I fix the server". That the
FreeBSD community is the most helpful one involved might have some
bearing on which question I chose to ask here.
> > As far as I know, there are only three reasons for an NFS server to
> > refuse a mount request: 1) The exports file is borked somehow, 2) The
> > server insists that the client use a privileged port, or 3) The IP
> > address the request is coming from is disallowed.
> There _are_ others, depending on how access controls are specified in
> the exports file.
Those are pretty much what I meant by "the exports file is borked
somehow". The file systems are all zfs, all exported by zfs, and
mostly all inherited from the parent file system. For the record,
that's:
/export -maproot 0 -network 192.xx.yy.0/25
> > #1 isn't it - the file systems mount fine on other boxes. And they
> > mount fine on the problem box via Wifi.
> >
> > #2 shouldn't be it - I'm running the server with -n turned on, and the
> > mount works via wifi.
> >
> > #3 seems logical, but I only have one network enabled, and it's a
> > *.0/25. The working addresses include .96, and .106, while the failing
> > address is .105. So I'm not sure what's going on here.
> >
> > Running mountd with a -d flag generates no output at all when the
> > request is denied. This makes me think I'm not looking in the right
> > place.
>
> First thing, what does 'showmount -a', run on the misbehaving client show?
> And are there differences, depending on being on the wired vs wireless link?
Just "All mounts on localhost:" and then an empty list, whether they
are mounted or not.
> Check how the client resolves the server hostname on both the wireless and
> wired links.
It's the same. That's expected - the WRT610N is providing both dns &
dhcp services, and they both resolve through it.
> make sure the _server_ name (in the form used in the nfs mount) is
> resolving in the same way -- to the same address -- when the client is
> on thee wireless and wired links. (an 'unqualified' hostname, and a
> lack of a default domain in the wired setup _could_ cause what you
> are seeing.
Yup, both connections resolve to the same address. Yes, I use an
unqualified hostname, but the dhcp server provides a default domain.
> Check to make sure you've got network connectivity both ways on both the
> wired and wireless links. Does traceroute work in both directions on
> both links? does it show the _same_names_?
Yes, and yes.
> You've say you've got a WRT610N in the middle of things. Is it actually
> playing _router_ on all ports, or switch/hub on the lan side with routing
> on the external interface.
The latter, and it's bridging the wireless network into the LAN side
as well.
> If it's actually -routing- on all ports, check _both_ the client and server
> routing tables to make sure they're pointing in the right plac, when the
> client is connected on both paths. Also double-check the router itself
> for any access-control and/or filtering rules.
Those all look right to me. In particular, the client routing tables
are identical (module different interface names & ip addresses) when
it's on the wireless and wired connection.
> If nothing has shown up so far, an obvious next step is to look at the data
> 'on the wire' between the machines. e.g., tcpdump/etherfind/netshark etc.
I was hoping for something a little bit higher level than that, but I
guess that's what's next.
Thanks,
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100926160114.0d97a56c>