On Oct 15, 2008, at 2:18 PM, Steve Dickson wrote:
Chuck Lever wrote:
Ok... The client has the nfs-utils-1.1.3 mount.nfs binary using an
FC-7 (2.6.21) kernel. New text mount interface with old binary
kernel
interface.
I have two servers:
ServerA has the nfs-utils-1.1.3 rpc.mountd binary using an F-9
2.6.26 kernel
ServerB has the nfs-utils-1.1.2 rpc.mountd binary using an F-10
2.6.27 kernel.
The following mount command work (meaning the mount was successful
and
I'm able to write the mount point):
mount -o sec=sys ServerA:/home /mnt/home
mount -o sec=none ServerA:/home /mnt/home
mount -o sec=sys ServerB:/home /mnt/home
The only mount that didn't work (meaning the actual mount failed)
was:
mount -o sec=none ServerB:/home /mnt/home
Due to the fact the 1.1.2 server failed it with:
mount.nfs: madhat.boston.devel.redhat.com:/home failed, security
flavor not supported
Which makes sense since this was the reason for bcwong's patch...
So where have I gone wrong in reproducing this?
What happens when you don't specify a sec= option at all?
'touch /mnt/home/tmp/foo && rm /mnt/home/tmp/foo' works as expected...
I'm out of ideas then.
The problem was with the mount command in nfs-utils 1.1.3 on older
kernels doing automatic security flavor negotiation incorrectly.
Maybe your exports file is set up differently?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
