From: "J. Bruce Fields" <bfields@fieldses.org>
To: Tom Haynes <tdh-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Bug in server's export -- List of security flavors
Date: Thu, 16 Jul 2009 14:56:42 -0400 [thread overview]
Message-ID: <20090716185642.GB2495@fieldses.org> (raw)
In-Reply-To: <4A5F5C4C.3070308-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
On Thu, Jul 16, 2009 at 11:58:52AM -0500, Tom Haynes wrote:
> [tdh@adept tournament]> exportfs -rva
> exporting 192.168.2.0/255.255.255.0:/home
> exporting *:/
> exportfs: could not open /var/lib/nfs/etab for locking
> exportfs: can't lock /var/lib/nfs/etab for writing
> [tdh@adept tournament]> more /etc/exports
> / *(sync)
> /home
> 192.168.2.0/255.255.255.0(rw,async,no_subtree_check,insecure,no_root_squash)
> [tdh@adept tournament]> uname -a
> Linux adept.internal.excfb.com 2.6.29.4-167.fc11.i586 #1 SMP Wed May 27
> 17:14:37 EDT 2009 i686 i686 i386 GNU/Linux
>
> So, adept:/home is exported in a fairly typical way that I've had going for
> the past 3 years.
>
> [root@witch ~]> mount -o vers=3 adept:/home /mnt
> nfs mount: security mode does not match the server exporting adept:/home
>
> The server is not sending any authentication flavors:
>
> MOUNT:----- NFS MOUNT -----
> MOUNT:
> MOUNT:Proc = 1 (Add mount entry)
> MOUNT:Status = 0 (OK)
> MOUNT:File handle = [DADF]
> MOUNT: 01000700010005000000000053CF6DE4FF1C4572BB2950392EB6993C
> MOUNT:Authentication flavor =
> MOUNT:
>
> And yet this mount will work from a Linux box:
>
> root@slayer:~# uname -a
> Linux slayer 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC
> 2009 i686 GNU/Linux
> root@slayer:~# mount -o vers=3 adept:/home /mnt
>
> I'm guessing that the Linux client is ignoring the list and trying the
> default AUTH_SYS anyway. Is that
> also a bug on the client, using a flavor not advertised by the server?
I don't see how it could be a problem for the client to try an
unadvertised flavor. The server has to enforce the choice of flavor
anyway.
(Um, but that's pretty weird that the server's advertising an empty
list. What's the nfs-utils version?)
--b.
next prev parent reply other threads:[~2009-07-16 18:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-16 16:58 Bug in server's export -- List of security flavors Tom Haynes
[not found] ` <4A5F5C4C.3070308-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
2009-07-16 18:56 ` J. Bruce Fields [this message]
2009-07-16 19:25 ` Tom Haynes
[not found] ` <4A5F7EA9.9050309-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
2009-07-16 19:45 ` J. Bruce Fields
2009-07-16 20:13 ` Tom Haynes
[not found] ` <4A5F8A00.8000104-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
2009-07-22 0:09 ` J. Bruce Fields
2009-08-17 17:33 ` [PATCH] Don't give client an empty flavor list J. Bruce Fields
2009-08-03 13:11 ` Bug in server's export -- List of security flavors Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090716185642.GB2495@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=tdh-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox