Problems mounting nfs from freebsd to Mac.

Mike Meyer mike.w.meyer at
Sun Sep 26 20:01:21 UTC 2010

On Sat, 25 Sep 2010 14:58:21 -0500 (CDT)
Robert Bonomi <bonomi at> wrote:

> > From owner-freebsd-questions at  Sat Sep 25 03:29:33 2010
> > Date: Sat, 25 Sep 2010 04:01:18 -0400
> > From: Mike Meyer <mike.w.meyer at>
> > To: questions at
> > 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
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.

Mike Meyer <mwm at>
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail -

More information about the freebsd-questions mailing list