[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?
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.
J. Bruce Fields wrote:
> 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.
>
Yes, the server needs to enforce it, but why is the client trying a
flavor that the server
says it does not support?
> (Um, but that's pretty weird that the server's advertising an empty
> list. What's the nfs-utils version?)
>
>
[tdh@adept root]> yum list nfs-utils
Loaded plugins: dellsysidplugin2, fastestmirror, refresh-packagekit
updates/metalink
| 2.9 kB 00:00
updates
| 4.4 kB 00:00
Installed Packages
nfs-utils.i586
1:1.1.5-6.fc11
installed
On Thu, Jul 16, 2009 at 02:25:29PM -0500, Tom Haynes wrote:
> J. Bruce Fields wrote:
>> 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.
>>
>
> Yes, the server needs to enforce it, but why is the client trying a
> flavor that the server
> says it does not support?
Could just be excessively persistent of optimistic. (Or in this case
probably it just doesn't have any negotiation code, so it's simplest
just to try the one flavor that was specified on the mount; seems fair
to me.)
There's also cases where this could also happen just due to bad timing:
maybe the export got changed in the middle. If only for that reason, I
don't think we could forbid a client from doing this.
>> (Um, but that's pretty weird that the server's advertising an empty
>> list. What's the nfs-utils version?)
>>
>>
>
>
> [tdh@adept root]> yum list nfs-utils
> Loaded plugins: dellsysidplugin2, fastestmirror, refresh-packagekit
> updates/metalink
> | 2.9 kB
> 00:00
> updates
> | 4.4 kB
> 00:00
> Installed Packages
> nfs-utils.i586
> 1:1.1.5-6.fc11
> installed
Thanks!
Hm. So this change of mine:
603017f2c1587d760e2649b889b581ca267ffee7 "Determine supported
pseudoflavors from export"
is probably at fault. I guess we need to figure out why it's producing
a zero-length array.
--b.
support/nfs/exports.c
505 if (strcmp(opt, "ro") == 0)
506 setflags(NFSEXP_READONLY, active, ep);
507 else if (strcmp(opt, "rw") == 0)
508 clearflags(NFSEXP_READONLY, active, ep);
...
624 } else if (strncmp(opt, "sec=", 4) == 0) {
625 active = parse_flavors(opt+4, ep);
If you find a 'sec=' you go ahead and set it in the e_secinfo array.
But if you encounter a rw or ro before you encounter a 'sec=', you do
not set a flavor in the e_secinfo array.
What we do is if we encounter the 'rw' or 'ro' before the 'sec=', then
it defaults to being a AUTH_SYS flavor. If we encounter it after, then
we know which flavor to set it as.
Of course, we have to account for what happens if we have the following:
share -F nfs -o rw,sec=sys,ro /foo
Because we can't have both a rw and ro export.
On Jul 16, 2009, at 3:25 PM, Tom Haynes wrote:
> J. Bruce Fields wrote:
>> 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.
>
> Yes, the server needs to enforce it, but why is the client trying a
> flavor that the server
> says it does not support?
If this mount request is generated by the kernel (kernels after 2.6.23
or so) and not by the mount command, the kernel's mount client does
not have support for reading the authlist returned by the server. I
sent patches to Trond for 2.6.32 to address this.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com