Bug 727629
| Summary: | nfs-utils-1.2.3-7 breaks nfs4 mounting with krb5 security | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jonathan Underwood <jonathan.underwood> |
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> |
| Status: | CLOSED DUPLICATE | QA Contact: | yanfu,wang <yanwang> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.1 | CC: | austinf, tomek |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-08-16 11:48:37 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jonathan Underwood
2011-08-02 16:29:42 UTC
The pertinent part in the failing case seems to be: Aug 2 16:19:58 burroughs rpc.gssd[3390]: ERROR: GSS-API: error in gss_set_allowable_enctypes(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - Unknown error Extra info - the server is running rhel 6.0 This seems to be bug #719776 already reported on Fedora. I can confirm this issue on Scientific Linux where both client and server are on 6.1. It may well be related to bug #719776, but actually the error message is different. Also, I don't actually see anything in the server logs (despite passing -vvv to rpcsvcgssd), suggesting the client doesn't get as far as contacting the server. Do you see anything in the server log, Tomasz? Now when you mentioned it I see the difference. I have on the client: Aug 2 20:59:04 vesemir rpc.gssd[2481]: ERROR: GSS-API: error in gss_set_allowable_enctypes(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - Unknown error and nothing related on the server (unless I screwed up ntp). I also see one difference in relation to bug #719776: vesemir:~> sudo klist -ekt Keytab name: WRFILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 03/19/11 10:34:22 host/vesemir.jot23.org (aes256-cts-hmac-sha1-96) 2 03/19/11 10:34:22 host/vesemir.jot23.org (aes128-cts-hmac-sha1-96) 2 03/19/11 10:34:23 host/vesemir.jot23.org (des3-cbc-sha1) 2 03/19/11 10:34:23 host/vesemir.jot23.org (arcfour-hmac) 2 03/19/11 10:34:23 host/vesemir.jot23.org (des-hmac-sha1) 2 03/19/11 10:34:23 host/vesemir.jot23.org (des-cbc-md5) : 2 04/22/11 23:21:04 nfs/vesemir.jot23.org (aes256-cts-hmac-sha1-96) 2 04/22/11 23:21:04 nfs/vesemir.jot23.org (arcfour-hmac) 2 04/22/11 23:21:05 nfs/vesemir.jot23.org (aes128-cts-hmac-sha1-96) 2 04/22/11 23:21:05 nfs/vesemir.jot23.org (des3-cbc-sha1) 2 04/22/11 23:21:05 nfs/vesemir.jot23.org (des-hmac-sha1) 2 04/22/11 23:21:05 nfs/vesemir.jot23.org (des-cbc-md5) I have des encryption types... Everything broke when I upgraded both client and server to SL6.1, I cannot say which part is responsible. I actually wonder if this is caused by BZ #722616 as I also see that bug on the same system. I still have one SL 6.0 client left with nfs-utils-1.2.2-7.el6.x86_64. I've tried to mount home with sec=krb5p. I haven't seen a thing in /var/log/messages but on the server I see the following three entries: Aug 3 19:19:10 triss rpc.svcgssd[5888]: ERROR: GSS-API: error in gss_export_lucid_sec_context(): GSS_S_NO_CONTEXT (No context has been established) - (0xbf9c1e08) Aug 3 19:19:10 triss rpc.svcgssd[5888]: ERROR: failed serializing krb5 context for kernel Aug 3 19:19:10 triss rpc.svcgssd[5888]: WARNING: handle_nullreq: serialize_context_for_kernel failed I believe it is related to the server bug #720479 with the same version. Looks like if you rebuild the nfs-utils-1.2.3 rpm from source, some libraries get linked in the wrong order. I can confirm, the fix for bug #720479, reordering the way libgssglue is linked in does eliminate the GSS_S_NO_CONTEXT error seen in Comment 7 *** This bug has been marked as a duplicate of bug 720479 *** |