On Mon, Feb 07, 2011 at 05:21:10PM -0600, Tom Haynes wrote:
> On Mon, Feb 07, 2011 at 04:59:35PM -0500, J. Bruce Fields wrote:
> >
> > Changes to /etc/exports aren't automatically detected, so you need a
> > server restart or an exportfs -ra after any change.
>
> Yep:
>
> exportfs -au # unload old rules
> exportfs # verify it is empty
> exportfs -a # load it up
> exportfs # verify it loaded
>
> So I would have expected it to have reloaded.
Sorry, and you said that in your original email. OK.
> > OK, so maybe the problem was just that mountd never found out about your
> > original /etc/exports file?
>
> That wouldn't explain why it has stopped working now.
>
> Neither the exportfs commands above nor a service nfs stop/start
> yields a working mount from the client.
>
> Restarting nfsd with an export of:
>
> [root@adept internal.excfb.com]# exportfs
> /fooper 192.168.2.0/255.255.255.0
> [root@adept internal.excfb.com]# uname -a
> Linux adept.internal.excfb.com 2.6.34.7-66.fc13.i686.PAE #1 SMP Wed Dec 15 07:21:49 UTC 2010 i686 i686 i386 GNU/Linux
>
> Does yield a mount.
And it's failing in the same way? ("unmatched host"?)
Like I say, I suppose my next step would be to get out the nfs-utils
source and figure out where it's failing (probably somewhere in
auth_authenticate_newcache -> get_client_hostname -> client_compose ->
client_check -> check_netgroup()).
If it's reporting "unmatched host", and if you can see it making the
right NIS request (and getting the right response), then I'm out of
other debugging ideas....
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
