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