gss_s_bad_qop when mounting nfs

[Podrigal, Aron]

Per this wiki page it is based off RHEL6
https://pve.proxmox.com/wiki/Proxmox_VE_Kernel

On Mon, Jun 22, 2015 at 11:14 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:

> On Mon, 22 Jun 2015, Podrigal, Aron wrote:
>
> > Hi, I am a bit lost and tired on this issue I'm having. I was able to
> setup
> > kerberos with nfs on multiple servers all running Debian wheezy with
> kernel
> > version 3.2.0-4-amd64. But, one server (actually the one I want the nfs
> > exports to reside on) which is running a RHEL kernel 2.6.32-29-pve I'm
> > having problems mounting its exports.
> >
> > It took me some time to figure out where the problem is happening, I've
> now
> >  tracked down where what the issue is.
> >
> >
> > Here is the log messages for rpc.svcgssd.
> >
> >
> > *svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with 7
> > enctypes from the kernel*
> > *WARNING: gss_accept_sec_context failed*
> > *ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context():
> > GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more
> > information) - Invalid argument*
> > *sending null reply*
> > *writing message: \x
> >
> \x6082028406092a864886f71201020201006e8202733082026fa003020105a10302010ea20703050020000000a38201726182016e3082016aa003020105a10e1b0c4d4f4e474f5042582e4e4554a2263024a003020103a11d301b1b036e66731b146d666c2d7673312e6d6f6e676f7062782e6e6574a382012930820125a003020112a103020105a28201170482011390df922f6a3f13cc1d4e7b6009b5ce1e721f69a3c1614cd8a5658fedb56af849f10e1f7da68e38ee8b052d5071ce843f46e75c5201cc532ded197e6015741c83ae9fa5d4718b32b1138fc56961a708afd26132069329774d810c23ab12578619a88cd38f5daa04ffaa70ab47c3055f6728b21b6d8ea617df0610b4e78ae2238e96d95e72de9898c42d65f039a2e57090c3fb752b800a1fbd384996be02825a1658bac60343054ec5a235e2786e47b35b62c8abf7cabede9d3e25b759886d19ad9bc89a7491e21ea6100527f985eb893df8a1dcab197e27080a3613cd5c34f55f30eccf40d90e70450d83dbc1a374965d5eb24778e44d2a5f1efd5d796ce6869928c79125ef95cee2d9e92753597b4bf28947a9a481e33081e0a003020112a281d80481d598f3043ec9c62eef9a3d14936db04f9d02b646b81867f5daf70efde3280042e3ff525b514f6e90dede10e650c3f037f10d517687cd2881d46ec2d!
> >
> 0d2f8930ec3fc1a0455d83a668a297d196572cc644787750e9f4bdf9b77d96510150618d7d9633f64614b12913d50cc52a75073d2327b015bbf44e97b81e32d31571d2cd636c170ae5d3e15b5d8b6c4c4c886e2482eb95b821f1b02c0fb6c1ab34f2a9ee19e19db568531da4eb4286526a374b07eb1915665aba93839206a7d82e0ef374da34e042424e1bd99fca55c2049df1a680f1c6fae3a3f
> > 1434954497 851968 22 \x \x *
> > *finished handling null request*
> > *entering poll*
>
> The GSS concept of QOP is quite thoroughlly deprecated at this point, so
> it's quite surprising to see the GSS_S_BAD_QOP return value; that return
> value is never generated from the current MIT krb5 tree (which is not
> especially relevant for the in-kernel NFS/GSSRPC code, but is perhaps
> illustrative).  What RHEL version does that 2.6.32-29-pve kernel come from
> (so that we can consider what versions of the other packages are in
> place)?  IIRC, the actual gss_accept_sec_context call occurs in gssd.
>
> -Ben Kaduk
>



-- 
Aron Podrigal
-
//Be happy :-)