| Summary: | Unable to mount nfs4 krb5p shares exported by a fedora16 server | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas Sailer <fedora> | ||||||
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 16 | CC: | bfields, jlayton, steved | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-03-22 19:32:31 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
Thomas Sailer
2011-11-16 19:56:40 UTC
I assume the same happens with sec=krb5? How do you see the init_sec context exchange end on the wire? (A packet trace--tcpdump -s0 -wtmp.pcap, try the mount, then attach tmp.pcap--might help.) Yes, the same happens with sec=krb5. Created attachment 534080 [details]
packet dump
> No key table entry found for CLIENT.XXXXX.COM$@XXXXX.COM while getting keytab
I thinking this is the problem... gssd is not find a key tab entry....
(In reply to comment #4) > > No key table entry found for CLIENT.XXXXX.COM$@XXXXX.COM while getting keytab > I thinking this is the problem... gssd is not find a key tab entry.... Well, but a couple lines down there's: keytab entry for 'root/client.xxxxx.com' Success getting keytab entry for 'nfs/client.xxxxx.com' So I think it was just searching for one and it had to search a little farther. Looking at trace.... server is returning GSS_S_NO_CONTEXT error, along with a perfectly good context. Maybe a mismatch between what svcgssd thinks is supported and what the kernel can do? Is svcgssd's downcall to give the context to the kernel failing? You could find that out by strace'ing svcgssd. Created attachment 534103 [details]
strace of rpc.svcgssd
you are correct, the write to /proc/net/rpc/auth.rpcsec.context/channel fails with EOPNOTSUPP
Seems like rpcsec_gss_krb5 does not get autoloaded. modprobe rpcsec_gss_krb5 makes the mount work. OK, that will be fixed in the kernel by upstream 058c5c99999609e3de7e15b49049665f02d06577 "rpc: allow autoloading of gss mechanisms". In the mean time, we should be loading rpcsec_gss_krb5 by hand before starting rpc.svcgssd. It looks like that got lost in the migration to systemd. Steved? rpc.svcgssd's handling of errors is also a little odd: in the null init_sec_context response it's returning an error correctly, but also returning a context, which seems fairly pointless. Something went wrong with the update (preupgrade seems to consistently fail to upgrade the bootloader), so I'm apparently still using the old kernel. That might explain why the autoload failed, as your patch seems to be present in fc16 kernels. Oh, OK, that explains it. I think we should probably still do a manual modprobe of rpcsec_gss_krb5 for another fedora cycle or so, just in case--people might want to try old kernels for debugging purposes, etc. So this is actually a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=737731 But yes, modprobing rpcsec_gss_krb5 for another release seems like a good idea to me (In reply to comment #8) > OK, that will be fixed in the kernel by upstream > 058c5c99999609e3de7e15b49049665f02d06577 "rpc: allow autoloading of gss > mechanisms". > > In the mean time, we should be loading rpcsec_gss_krb5 by hand before starting > rpc.svcgssd. It looks like that got lost in the migration to systemd. Steved? > I'll look into seeing if I can get the systemd script to do the modprob for the short term... (In reply to comment #8) > OK, that will be fixed in the kernel by upstream > 058c5c99999609e3de7e15b49049665f02d06577 "rpc: allow autoloading of gss > mechanisms". This fix is in the kernel-3.1.1-1.fc16 kernel which is the latest F16 kernel. So at this point all that's needed is a yum upgrade kernel |