After upgrading from nfs-utils-1.2.3-11.fc15.x86_64 to nfs-utils-1.2.4-0.fc15.x86_64 on my NFSv4 servers and clients, my server logs are littered with errors such as the following and the clients are unable to mount any of the exported file systems: Jul 7 17:35:33 chicago rpc.svcgssd[1267]: libnfsidmap: using domain: messinet.com Jul 7 17:35:33 chicago rpc.svcgssd[1267]: libnfsidmap: Realms list: 'MESSINET.COM' Jul 7 17:35:33 chicago rpc.svcgssd[1267]: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch Jul 7 17:35:33 chicago rpc.svcgssd[1267]: entering poll Jul 7 17:36:10 chicago rpc.svcgssd[1267]: leaving poll Jul 7 17:36:10 chicago rpc.svcgssd[1267]: handling null request Jul 7 17:36:10 chicago rpc.svcgssd[1267]: WARNING: gss_accept_sec_context failed Jul 7 17:36:10 chicago rpc.svcgssd[1267]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - No supported encryption types (config file error?) Jul 7 17:36:10 chicago rpc.svcgssd[1267]: sending null reply Jul 7 17:36:10 chicago rpc.svcgssd[1267]: finished handling null request In addition, with the upgraded version, the server also reports tons of SELinux AVCs (in permissive and enforcing mode): SELinux is preventing /usr/sbin/rpc.svcgssd from search access on the directory /proc/fs/nfsd Downgrading to nfs-utils-1.2.3-11.fc15.x86_64 on the server (even with the clients keeping nfs-utils-1.2.4-0.fc15.x86_64) resolves all of the above issues. I realize the upgrade was to fix: Bug #716949 http://marc.info/?l=linux-nfs&m=130875695821953&w=2 Here is /etc/exports: /export *.messinet.com(fsid=0,sec=krb5p) /export/home *.messinet.com(rw,nohide,sec=krb5p)
That update brings in the code that reads fs/nfsd/supported_krb5_enctypes. So we probably just need a fix to the selinux policy to allow that . (Do your problems all go away on "setenforce 0"?) But svcgssd could be more helpful here: maybe it should fall back on old behavior on failure to open supported_krb5_enctypes, instead of failing completely?
(In reply to comment #1) > That update brings in the code that reads fs/nfsd/supported_krb5_enctypes. So > we probably just need a fix to the selinux policy to allow that . (Do your > problems all go away on "setenforce 0"?) Unfortunately, even with setenforce 0, the exported filesystems would not mount. If it were just the SELinux issue, I would have created a temporary fix (audit2allow). > But svcgssd could be more helpful here: maybe it should fall back on old > behavior on failure to open supported_krb5_enctypes, instead of failing > completely? Any advice on the non-SELinux component?
I was able to reproduce this problem on a freshly installed virtual system (i686). Also, downgrading nfs-utils on the virtual system as described above resolved the issue.
Are the same errors as above logged in the case SELinux is off, or is the log output different?
The SELinux errors are identical in permissive and enforcing mode. Running SELinux in permissive mode, however does not fix the issue of not being able to mount the filesystem. On the virtual install, I had SELinux disabled for the entire testing process (in fact, I have SELinux off on that vhost completely).
"The SELinux errors are identical in permissive and enforcing mode." Right, that's expected, I wondered about the other log output; "No supported encryption types" seemed like it could be a consequence of an SELinux denial. It'd be interesting to see a version of the above log fragment for the non-enforcing case, if it's different.
Can you tell me what, if any, options you use when starting svcgssd? Are there any more hints if "-vvv" is specified?
Thank you gentlemen for your quick feedback. I'll need to wait until tomorrow evening, however, to get you more detailed logs. I'll be sure to add -vvv to the rpc.svcgssd options.
Anthony, It might be helpful to also get a look at the output of a successful mount with the older version of svcgssd running with -vvv to compare vs. the new version. The output of running "sudo klist -ekt" would also be helpful. Bruce, The new code should already default the encryption types to DES if the proc file cannot be read. I'm wondering if that might be the problem. (AES is currently being used successfully and DES is disabled.) This might be the case with newer installations that never had to limit things to DES.
(In reply to comment #9) > Anthony, > It might be helpful to also get a look at the output of a successful mount with > the older version of svcgssd running with -vvv to compare vs. the new version. > > The output of running "sudo klist -ekt" would also be helpful. # klist -ekt Keytab name: WRFILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 07/07/11 20:09:15 host/f15-i686.virt.messinet.com (aes256-cts-hmac-sha1-96) 2 07/07/11 20:09:15 host/f15-i686.virt.messinet.com (aes128-cts-hmac-sha1-96) 2 07/07/11 20:09:16 host/f15-i686.virt.messinet.com (des3-cbc-sha1) 2 07/07/11 20:09:16 host/f15-i686.virt.messinet.com (arcfour-hmac) 2 07/07/11 20:09:19 nfs/f15-i686.virt.messinet.com (aes256-cts-hmac-sha1-96) 2 07/07/11 20:09:20 nfs/f15-i686.virt.messinet.com (aes128-cts-hmac-sha1-96) 2 07/07/11 20:09:20 nfs/f15-i686.virt.messinet.com (des3-cbc-sha1) 2 07/07/11 20:09:20 nfs/f15-i686.virt.messinet.com (arcfour-hmac) > Bruce, > The new code should already default the encryption types to DES if the proc > file cannot be read. I'm wondering if that might be the problem. (AES is > currently being used successfully and DES is disabled.) This might be the case > with newer installations that never had to limit things to DES.
(In reply to comment #6) > "The SELinux errors are identical in permissive and enforcing mode." > > Right, that's expected, I wondered about the other log output; "No supported > encryption types" seemed like it could be a consequence of an SELinux denial. > It'd be interesting to see a version of the above log fragment for the > non-enforcing case, if it's different. I've replicated this setup on a vhost so I can keep my other dependent systems up and running. Below is the output from rpc.svcgssd -vvv in non-enforcing (permissive) mode: Jul 8 20:37:37 f15-i686 rpc.svcgssd[1507]: libnfsidmap: using domain: messinet.com Jul 8 20:37:37 f15-i686 rpc.svcgssd[1507]: libnfsidmap: Realms list: 'MESSINET.COM' Jul 8 20:37:37 f15-i686 rpc.svcgssd[1507]: libnfsidmap: loaded plugin /lib/libnfsidmap/nsswitch.so for method nsswitch Jul 8 20:37:37 f15-i686 rpc.svcgssd[1507]: entering poll Jul 8 20:37:37 f15-i686 kernel: [ 2755.585919] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Jul 8 20:37:37 f15-i686 kernel: [ 2755.585949] NFSD: starting 90-second grace period Jul 8 20:37:37 f15-i686 rpc.mountd[1526]: Version 1.2.4 starting Jul 8 20:37:37 f15-i686 rpc.idmapd[1140]: ReOpening /proc/net/rpc/nfs4.nametoid/channel Jul 8 20:37:37 f15-i686 rpc.idmapd[1140]: ReOpening /proc/net/rpc/nfs4.idtoname/channel Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: leaving poll Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: handling null request Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: WARNING: gss_accept_sec_context failed Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: sending null reply Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: writing message: \x \x6082029006092a864886f71201020201006e82027f3082027ba003020105a10302010ea20703050020000000a382017b6182017730820173a003020105a10e1b0c4d455353494e45542e434f4da22c302aa003020103a12330211b036e66731b1a6631352d693638362e766972742e6d657373696e65742e636f6da382012c30820128a003020112a103020102a282011a0482011669c63bcf118f4e51942594589268202f4aa86083d79f7e8b7ce813e5d0dfafcf30bc96ef5aced0e18d6d59edc3043017cd1b61f0d1571dc134566a9e085f5c6bdaba36975b51e356c559ecfc933d4245b53800d7090bb2901004c7b15d6f1666f192a00a2260dce6b29399a8b2cdae2cc2804290a5945f982e349a977dcd58c6a9f323766afc951a9050b25d48f55dba673f9cfc26cac0fe8da6e61e2e953993444caa14748ecdf314fc444f79f8146b80c2feefca94a634d2b76bd493d3b617e9cba78b9f64fe3e25d125255d784ad0946371bde9ecc5be4a0ce90cd713013820934653ab34ce222e0a2f5db619d272afa0e6a47104ca60128a321cbde08ebf7fa74f540274bd5135897fa5d00b3ee9f8a1e788fd6ea481e63081e3a003020112a281db0481d8a360c12294ab9359550a0baf688d232a0897b8004d9c597bb73a0d4f9c817dad1cd728e4a50c00d111825f9d902ce686ebbf4c9ed515fc159f82dd6b0815ff0b9f9f0a062c3a055957b2a26e2c536ba8dab0773f3374996e29a3d77342d808a866dcad0a1c070509c43b0d3d7b704d0f0eae9efe3eb004557c4a3170c34b9c718f49db2ceacd86c4b86aec25e3c77f9ea336765da2778e0552059218c7b4556c2b3b639da11e472aadf6b5619696fb1c359a5672636f8a7f5450b26f400075866fc334f6c2ea9e4a036dedadb0a2165d0c96a40f4fdfdb39 1310175693 851968 2529639148 \x \x Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: finished handling null request Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: entering poll Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: leaving poll Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: handling null request Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: WARNING: gss_accept_sec_context failed Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: sending null reply Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: writing message: \x \x6082029006092a864886f71201020201006e82027f3082027ba003020105a10302010ea20703050020000000a382017b6182017730820173a003020105a10e1b0c4d455353494e45542e434f4da22c302aa003020103a12330211b036e66731b1a6631352d693638362e766972742e6d657373696e65742e636f6da382012c30820128a003020112a103020102a282011a0482011669c63bcf118f4e51942594589268202f4aa86083d79f7e8b7ce813e5d0dfafcf30bc96ef5aced0e18d6d59edc3043017cd1b61f0d1571dc134566a9e085f5c6bdaba36975b51e356c559ecfc933d4245b53800d7090bb2901004c7b15d6f1666f192a00a2260dce6b29399a8b2cdae2cc2804290a5945f982e349a977dcd58c6a9f323766afc951a9050b25d48f55dba673f9cfc26cac0fe8da6e61e2e953993444caa14748ecdf314fc444f79f8146b80c2feefca94a634d2b76bd493d3b617e9cba78b9f64fe3e25d125255d784ad0946371bde9ecc5be4a0ce90cd713013820934653ab34ce222e0a2f5db619d272afa0e6a47104ca60128a321cbde08ebf7fa74f540274bd5135897fa5d00b3ee9f8a1e788fd6ea481e63081e3a003020112a281db0481d8575f043e164cc0fd2e25a65b8a26d1f87a84cda5bdc89e37240374bae242783ece23e001e0e0a8904e4cb34be4ba63a3fea57ec10b5a3428165ed019563e5fd323b799e4479a1752a24affa31c54854376c868ba176069fc6eafa83103689069f770e0c87e79aad18c1fc51ef6086014b8430fa7c2bd40f98ffcfdd39b9bdd71710a625c10ed31011ad50b5137b023985b7bc8c1984b629802121faa115a285ed477ebc4fbc5229c204ce0d0cc3352d4ebc7b07a09a5e668d057a461383fd9b4953b48d42ec5ee302d9fbc91d7ca292975ae2ef1dd020cc1 1310175693 851968 2529639148 \x \x Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: finished handling null request Jul 8 20:40:33 f15-i686 rpc.svcgssd[1507]: entering poll
(In reply to comment #1) > That update brings in the code that reads fs/nfsd/supported_krb5_enctypes. So > we probably just need a fix to the selinux policy to allow that . (Do your > problems all go away on "setenforce 0"?) > > But svcgssd could be more helpful here: maybe it should fall back on old > behavior on failure to open supported_krb5_enctypes, instead of failing > completely? My server system doesn't seem to have that file 'supported_krb5_enctypes' which may be the problem: [root@f15-i686 nfsd]# ls -l /proc/fs/nfsd total 0 -r--r--r--. 1 root root 0 Jul 8 19:52 export_features -r--r--r--. 1 root root 0 Jul 8 19:52 exports -rw-------. 1 root root 0 Jul 8 19:52 filehandle -rw-r--r--. 1 root root 0 Jul 8 19:52 max_block_size -rw-------. 1 root root 0 Jul 8 19:52 nfsv4gracetime -rw-------. 1 root root 0 Jul 8 19:52 nfsv4leasetime -rw-------. 1 root root 0 Jul 8 19:52 nfsv4recoverydir -r--r--r--. 1 root root 0 Jul 8 19:52 pool_stats -rw-------. 1 root root 0 Jul 8 19:52 pool_threads -rw-r--r--. 1 root root 0 Jul 8 19:52 portlist -rw-------. 1 root root 0 Jul 8 19:52 threads -rw-------. 1 root root 0 Jul 8 19:52 unlock_filesystem -rw-------. 1 root root 0 Jul 8 19:52 unlock_ip -rw-------. 1 root root 0 Jul 8 19:52 versions
(In reply to comment #9) > Anthony, > It might be helpful to also get a look at the output of a successful mount with > the older version of svcgssd running with -vvv to compare vs. the new version. The following output is from my production system which I have downgraded to the previous version of nfs-utils. Aside from the hostname differences, compare with comment #11): Jul 8 20:46:05 chicago rpc.svcgssd[22563]: leaving poll Jul 8 20:46:05 chicago rpc.svcgssd[22563]: handling null request Jul 8 20:46:05 chicago rpc.svcgssd[22563]: sname = nfs/ws1.mobile.messinet.com Jul 8 20:46:05 chicago rpc.svcgssd[22563]: DEBUG: serialize_krb5_ctx: lucid version! Jul 8 20:46:05 chicago rpc.svcgssd[22563]: prepare_krb5_rfc4121_buffer: protocol 1 Jul 8 20:46:05 chicago rpc.svcgssd[22563]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 Jul 8 20:46:05 chicago rpc.svcgssd[22563]: doing downcall Jul 8 20:46:05 chicago rpc.svcgssd[22563]: mech: krb5, hndl len: 4, ctx len 52, timeout: 1310262035 (86070 from now), clnt: nfs.messinet.com, uid: -1, gid: -1, num aux grps: 0: Jul 8 20:46:05 chicago rpc.svcgssd[22563]: sending null reply Jul 8 20:46:05 chicago rpc.svcgssd[22563]: writing message: \x \x6082029706092a864886f71201020201006e82028630820282a003020105a10302010ea20703050020000000a38201826182017e3082017aa003020105a10e1b0c4d455353494e45542e434f4da21e301ca003020103a11530131b036e66731b0c6d657373696e65742e636f6da38201413082013da003020112a103020102a282012f0482012b23f440e7b31975a2446873093dddb164dca0887628d33610b5762554d03bea076f2ed286419a50e83cbe52f93abdda7854f78d34a44eae21d7af061b4446cd5688720e166400e8fe1f83461142614a22404003732460aa43ee71cee430b435c22a7154b354eaa1b691a7e8f65e7160e9523a7b5aa7b6e9b2e38ccc70c4f47e15e7051ee5030eb258c6648b1830a841ceb095b6b270d4d33ed094c8ce8dc5cdcca4bab5da682bb1be16930063b569a193bad44fe738e406cd2cb69dacfaeb14de51d598f04ef7759d10afb4833937a56ef5f7f319693f9a3152a12834ea4b2769f127796b529b0fb64cb51cff583e3781fd9b61c677d39a914aa8a58dfd78ff05eac056ae93f9ae4a1ee3740fac2d7252ab209046082cc2ed52d0c7b341ad7086521930ac9d53cf7af6b90da481e63081e3a003020112a281db0481d8726b20b0bb71db2e1197c59106b72324fc794a2c9f2b31941215cd0bc5fadf9e657e163b490c096b690407812f17ebf96319bf4c89cf584bb9b1b355fd25145ec64c7b13a78a5cd4aeff1ecfd7d961060aee41e32c5f39c1911685bb585b1974e96613c003ce6782c1e28d9cea5192981f852f6b9a5cdf2315ac33718ef2e3fab95913f61718e7455ed3e3ed73b8fd595d69fadde84bea2680b1cafa360948a8dd31aaa77e8bd719b1b0352d3d2e4d4610714337cca12d8efd1c077ef9cd982a61f624a135edaf7f01ac5d3ceba74f9fd739d47c1eea2209 1310176025 0 0 \x05000000 \x60819906092a864886f71201020202006f8189308186a003020105a10302010fa27a3078a003020112a271046fc5d974ff9b9f9d76a0ed977b23aeed7f85832a329260a8cedc25df1ebbdc3a5668ff76ba0de4976068d7b5a83cbf4864a2b584e69397470301f0ec3001fa1491ab0c030c40efe1dd666cc5395ceebcdfc9606f8f49779d81d4dde42d9c236a07b5ceade2bf15221aad236b267aeafa Jul 8 20:46:05 chicago rpc.svcgssd[22563]: finished handling null request Jul 8 20:46:05 chicago rpc.svcgssd[22563]: entering poll
OK, thanks. Your keytab doesn't have a DES key. Is your KDC a Windows AD, MIT, or Heimdal? Since we are unable to read the kernel supported enctypes, we assume only DES is supported by the kernel and limit the negotiation to DES. I assume that you do not have "allow_weak_crypto = true" in your /etc/krb5.conf file. I'll have to think about what to do in this case. Perhaps if we can't read the kernel's supported enctypes file we should just not limit the negotiation. This will result in errors when the kernel truly only supports DES and the Kerberos library asserts a sub-key of a different enctype.
(In reply to comment #14) > OK, thanks. Your keytab doesn't have a DES key. Is your KDC a Windows AD, > MIT, or Heimdal? MIT, stock setup from Fedora. > Since we are unable to read the kernel supported enctypes, we assume only DES > is supported by the kernel and limit the negotiation to DES. I assume that you > do not have "allow_weak_crypto = true" in your /etc/krb5.conf file. I know about this workaround. I had to use it for a bit during F14's reign, but after it was "fixed", I've removed all of those lines from clients and servers and re-issued keytabs with the standard enctypes exported as listed above. > I'll have to think about what to do in this case. Perhaps if we can't read the > kernel's supported enctypes file we should just not limit the negotiation. > This will result in errors when the kernel truly only supports DES and the > Kerberos library asserts a sub-key of a different enctype. Why do you think I am missing the /proc/fs/nfsd/supported_krb5_enctypes file?
Just a quick search, but does the 2.6.38.8-32.fc15 kernel have this issue: https://patchwork.kernel.org/patch/723971/
I believe the patch to add the /proc/fs/nfsd/supported_krb5_enctypes file went into 2.6.39. I don't know whether it might have been pulled into earlier Redhat kernels.
Ok, I just looked at the sources from fedpkg. The 2.6.38 Fedora Kernels do not include any patch for "supported_krb5_enctypes". The f15-2.6.39 git branch sources contain the original kernel patch for supported_krb5_enctypes, but that would only lead to the problem here: https://patchwork.kernel.org/patch/723971/ where it would not work as a loadable module. What happens now? Does the 2.6.38 Fedora kernel need the patch to allow it to work with secure nfs and the now "stable" nf-utils.
It looks like Fedora 15's 2.6.38 kernels might need: http://www.mail-archive.com/stable@linux.kernel.org/msg13158.html in order to work with the now released nfs-utils and kerberos/gssapi security.
"Does the 2.6.38 Fedora kernel need the patch to allow it to work with secure nfs and the now "stable" nf-utils." No, nfs-utils must be able to deal with older kernels--we need to make sure it falls back on previous behavior as a default.
(In reply to comment #20) > "Does the 2.6.38 Fedora kernel need the patch to allow it to work with secure > nfs and the now "stable" nf-utils." > > No, nfs-utils must be able to deal with older kernels--we need to make sure it > falls back on previous behavior as a default. Ok. Thanks for the update. I hope this doesn't mean I'll need to go *back* to allow_weak_crypto and re issue all those tickets. I appreciate the help on this.
(In reply to comment #20) > "Does the 2.6.38 Fedora kernel need the patch to allow it to work with secure > nfs and the now "stable" nf-utils." > > No, nfs-utils must be able to deal with older kernels--we need to make sure it > falls back on previous behavior as a default. If the supported_krb5_enctypes file cannot be read, the default enctypes to use will need to be kernel-specific. 2.6.37 (need to double-check that) and later should default to "all" of them, prior kernels should default to DES only. I'll attempt to do a patch this Wednesday. If someone wants to beat me to it, I won't be offended.
I think I'd prefer to make svcgssd_limit_krb5_enctypes() a no-op in the case where we can't find supported_krb5_enctypes, as you suggest in comment 14. That's not the ideal behavior, but it's at least guaranteed to keep existing systems working, since it's what we've always done before (if I understand correctly).
(In reply to comment #23) > I think I'd prefer to make svcgssd_limit_krb5_enctypes() a no-op in the case > where we can't find supported_krb5_enctypes, as you suggest in comment 14. > That's not the ideal behavior, but it's at least guaranteed to keep existing > systems working, since it's what we've always done before (if I understand > correctly). The reason this code was added was to fix the case where AES subkeys are asserted by Kerberos, but the kernel only supports DES. If we were going to do as you suggest, we could probably just remove these changes. I think a kernel version check is req'd.
After upgrade kerberos (version 1.9.1) and nfs-utils ( version 1.2.4), nfs shares not mount anymore. client mount: tango.atr.eti.br/home /home nfs4 sec=krb5 0 0 Kernel version: 2.6.38.8-35 and fc15 with all updates (12/07/2011) /var/log/messages: Jul 12 19:23:17 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - No supported encryption types (config file error?) Jul 12 19:23:18 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - No supported encryption types (config file error?) Jul 12 19:23:18 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - No supported encryption types (config file error?) Jul 12 19:23:19 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - No supported encryption types (config file error?) "allow_weak_crypto = true" only change error message: Jul 12 19:27:24 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted Jul 12 19:27:24 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted Jul 12 19:27:25 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted Jul 12 19:27:26 tango rpc.svcgssd[1433]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted What i do? Users are furious!
(In reply to comment #25) > After upgrade kerberos (version 1.9.1) and nfs-utils ( version 1.2.4), nfs > shares not mount anymore. > > What i do? Users are furious! You could downgrade to nfs-utils-1.2.3-11.fc15 while these gentlemen are working on the fix. That is what I have done.
I'm using nfs version 3
Really(In reply to comment #25) > After upgrade kerberos (version 1.9.1) and nfs-utils ( version 1.2.4), nfs > shares not mount anymore. > > > client mount: > tango.atr.eti.br/home /home nfs4 sec=krb5 0 0 It looks like NFSv4 to me.........^^^^.
Kevin, I can confirm your patch works: http://article.gmane.org/gmane.linux.nfs/41981 I have applied your patch and created RPMs which I will use until this hits the Fedora repos: http://messinet.com/koji/taskinfo?taskID=2517 Thank you very much for your work on this.
I've submitted the SELinux portion of the issue bug #722368
nfs-utils-1.2.4-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/nfs-utils-1.2.4-1.fc15
Package nfs-utils-1.2.4-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.4-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/nfs-utils-1.2.4-1.fc15 then log in and leave karma (feedback).
nfs-utils-1.2.4-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.