Bug 197504

Summary: nfs4 AUTH_GSSAPI server returning EACCESS on all mount attempts
Product: [Fedora] Fedora Reporter: Jeff Layton <jlayton>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: k.georgiou, steved
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-08 09:50:41 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
temporary patch to fix problem
none
corrected patch none

Description Jeff Layton 2006-07-03 08:14:08 EDT
Description of problem:

Yesterday, I updated my main NFS server to these package revisions:

nfs-utils-1.0.8-2.fc5
nfs-utils-lib-1.0.8-4.FC5
libgssapi-0.9-1.FC5

Afterward, I was unable to mount any filesystems via NFS4. All mount attempts
failed with an EPERM. The server showed a similar warning to this with each
mount attempt:

Jul  3 08:01:25 salusa rpc.svcgssd[14831]: WARNING: get_ids: unable to map name
'nfs/client.domain.net@DOMAIN.NET' to a uid

...downrevving to these packages:

nfs-utils-1.0.8.rc2-5.FC5.i386.rpm
libgssapi-0.7-2.1.i386.rpm
nfs-utils-lib-1.0.8-3.1.i386.rpm

...made the problem go away. I'm opening this as an nfs-utils bug, but it may
actually be a problem with one of the other library packages.
Comment 1 Jeff Layton 2006-07-06 16:01:52 EDT
Sorry, I need to clarify. AUTH_UNIX seems to work fine, but with these updated
packages on the server, mounting with AUTH_GSSAPI consistently fails:

If I export with this on the server:

/export/testfs          *(rw,fsid=0,insecure,no_subtree_check,sync)

...and then mount like this on the client:

mount -t nfs4 -o rsize=32768,wsize=32768,noatime xenguest:/ /mnt/test

...it mounts correctly. But if I mount using sec=krb5:

mount -t nfs4 -o sec=krb5,rsize=32768,wsize=32768,noatime xenguest:/ /mnt/test

then I get:

mount: block device xenguest:/ is write-protected, mounting read-only
mount: cannot mount block device xenguest:/ read-only

strace shows:

mount("xenguest:/", "/mnt/test", "nfs4", MS_MGC_VAL|MS_NOATIME, "\1") = -1
EACCES (Permission denied)
mount("xenguest:/", "/mnt/test", "nfs4", MS_MGC_VAL|MS_RDONLY|MS_NOATIME, "\1")
= -1 EACCES (Permission denied)

I'll see if I can get some wire captures as well...

Comment 2 Jeff Layton 2006-07-06 16:13:47 EDT
Actually need to clarify again, I'm exporting this way:

/export/testfs          gss/krb5(rw,fsid=0,insecure,no_subtree_check,sync)
*(rw,fsid=0,insecure,no_subtree_check,sync)
Comment 4 Jeff Layton 2006-07-06 20:36:44 EDT
Created attachment 132033 [details]
temporary patch to fix problem

This patch was posted to the nfs4 mailing list 3 days ago. It seems to correct
the problem. It was posted as a temporary fix, but I think the permanent fix
may be similar (though perhaps with different uid/gid hardcoded values).
Comment 5 Jeff Layton 2006-07-06 21:06:26 EDT
Created attachment 132035 [details]
corrected patch

A patch was posted to the nfs4 list today to correct the values in the first
patch:

http://linux-nfs.org/pipermail/nfsv4/2006-July/004660.html

though there seems to have been an intermediate patch between the first one I
posted and that one that I've been unable to locate. In any case, I'm fairly
sure that this patch should reflect the current state of this part of get_ids.

It fixes the problem on my test rig as well.
Comment 6 Jeff Layton 2006-07-07 08:00:38 EDT
changing to devel since problem exists in that package as well
Comment 7 Jeff Layton 2006-07-15 08:37:03 EDT
Looks like this patch is incorporated in 1.0.9, so rebasing on that might be a
better way to go.
Comment 8 Kostas Georgiou 2006-08-08 06:24:27 EDT
In my home FC5 machines the problem wemt away by building a 1.0.9 rpm. 
Comment 9 Steve Dickson 2006-08-08 09:50:41 EDT
fixed in nfs-utils-1.0.9-3