On Thu, Feb 06, 2014 at 01:52:16PM -0500, Norman Elton wrote: > > And they have that same group membership on the server side? > > Yes, both the NFS server and NFS client point to the same active > directory for ldap / kerberos. > > I have tried running rpc.svcgssd with debugging, as well as with > strace as you suggested. I get plenty of output when a "good" user > logs in. No debugging information for user who fails. The error > (failed to create krb5 context...) appears on the client, maybe before > it connects to the server? OK, must be. You could also confirm this by looking at network traffic, e.g. with wireshark. Might also be worth looking at the client<->KDC traffic to see if the client is getting as far as asking for a ticket and if so what error the KDC is returning. --b. > > Thanks, > > Norman > > On Thu, Feb 6, 2014 at 1:36 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Thu, Feb 06, 2014 at 01:19:19PM -0500, Norman Elton wrote: > >> Just a follow-up to my previous post. In debugging rpc.gssd on the > >> client, here's where things are dying: > >> > >> creating tcp client for server filertest.safety.net.wm.edu > >> creating context with server nfs@xxxxxxxxxxxxxxxxxxxxxxxxxxx > >> WARNING: Failed to create krb5 context for user with uid 30487 for > >> server filertest.safety.net.wm.edu > >> > >> But other users seem fine. I still think it's something to do with > >> excessive group membership. > > > > And they have that same group membership on the server side? > > > > In that case there might be some problem with rpc.svcgssd's handling of > > large group lists--some debugging of rpc.svcgssd on the server might be > > interesting. > > > > In particular, output from: > > > > strace -p $(pidof rpc.svcgssd) -s65536 -e trace=open,close,read,write > > > > might be interesting. > > > > --b. > > > >> > >> Any suggestions are appreciated, thanks! > >> > >> Norman Elton > >> College of William & Mary > >> > >> On Mon, Feb 3, 2014 at 4:13 PM, Norman Elton <normelton@xxxxxxxxx> wrote: > >> > I've read stories about users having too many group memberships. We > >> > seem to experience similar symptoms, though the usual tricks don't > >> > seem to work. > >> > > >> > In our case, there is a RHEL6 NFS server feeding multiple RHEL6 NFS > >> > clients. This is all NFSv4 with Kerberos. Most users can login fine, > >> > but domain admins get a "permission denied" when accessing their > >> > NFS-mounted home directory. The most notable commonality is their high > >> > number of group memberships. > >> > > >> > I've tried inflating my group count to greater than 16, my account > >> > continues to work fine. > >> > > >> > We've tried adding "--manage-gids" to rpc.mountd, no luck. Although > >> > it's unclear whether this really does anything in a kerberized > >> > environment. > >> > > >> > Any other suggestions? Other debugging tricks? > >> > > >> > Thanks > >> > > >> > Norman Elton > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
