Problems mounting nfs from freebsd to Mac.

[Robert Bonomi]

> 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.

> The server is running 8.1-RELEASE, exporting a collection of zfs file
> systems. All the file systems are exported with the exact same
> flags. The clients are either FreeBSD or OSX boxes. Most of them work
> fine.
>
> One OSX box - updated to the latest snow leopard while trying to fix
> this - gets "permission denied" when it tries to mount the interesting
> fie systems. But only when using it's wired connection. If it connects
> via wifi to the same router (a cisco WRT610N running dd-wrt)
> everything works fine.

That elimintes NFS on the client, and -most- of the NFS config on the
server.

> 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.
>
> #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?

Check how the client resolves the server hostname on both the wireless and
wired links.

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.

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_?

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.  

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.

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.