From owner-freebsd-questions@FreeBSD.ORG Sat Sep 25 20:15:16 2010 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD68106564A for ; Sat, 25 Sep 2010 20:15:16 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (ns2.r-bonomi.com [204.87.227.129]) by mx1.freebsd.org (Postfix) with ESMTP id 554B78FC24 for ; Sat, 25 Sep 2010 20:15:16 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.3/rdb1) id o8PJwLd0027577; Sat, 25 Sep 2010 14:58:21 -0500 (CDT) Date: Sat, 25 Sep 2010 14:58:21 -0500 (CDT) From: Robert Bonomi Message-ID: <201009251958.o8PJwLd0027577@mail.r-bonomi.com> To: mike.w.meyer@gmail.com, questions@freebsd.org Cc: Subject: Re: Problems mounting nfs from freebsd to Mac. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 20:15:16 -0000 > 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 > 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. > 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.