Problems mounting nfs from freebsd to Mac.
mike.w.meyer at gmail.com
Sun Sep 26 20:01:21 UTC 2010
On Sat, 25 Sep 2010 14:58:21 -0500 (CDT)
Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
> > From owner-freebsd-questions at freebsd.org Sat Sep 25 03:29:33 2010
> > Date: Sat, 25 Sep 2010 04:01:18 -0400
> > From: Mike Meyer <mike.w.meyer at gmail.com>
> > To: questions at 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,
/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
> 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.
Mike Meyer <mwm at 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
More information about the freebsd-questions