Believe it or not....a typo in the NIS files could cause this. I ran into before. Hard to figure out without lots of troubleshooting.
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at TMACsRack https://tmacsrack.wordpress.com/*
[image: FlexPod Design Badge] https://www.youracclaim.com/badges/58cf082d-acd8-4529-821a-bb7eb93a296c/public_url[image: NCIE SAN Badge] https://www.youracclaim.com/badges/162b629e-b4f1-48af-a8f9-d2a9517ec100/public_url[image: NCSIE Badge] https://www.youracclaim.com/badges/367c462d-d58b-4cbf-9e8d-a5068b247cd6/public_url[image: NCSE Badge] https://www.youracclaim.com/badges/618b30bf-7acc-473d-8b06-827062653565/public_url[image: NAHSE Badge] https://www.youracclaim.com/badges/aa9be0e4-2eac-45eb-85e0-0e11035b62a5/public_url[image: SME Badge] https://www.youracclaim.com/badges/6eb5d0cd-acf4-40ac-a50c-73f1c0c009e9/public_url[image: NCDA Badge] https://www.youracclaim.com/badges/b41a5941-6885-4181-b984-21df36bc27a8/public_url[image: NCIE Data Protection Badge] https://www.youracclaim.com/badges/51e81930-cad0-4e1f-b54d-dde7f181516c/public_url[image: FlexPod Impl & Admin Badge] https://www.youracclaim.com/badges/53a73b2a-ca83-43b8-895e-3299735dd406/public_url
On Fri, Mar 9, 2018 at 5:09 PM, Ehrenwald, Ian Ian.Ehrenwald@hbgusa.com wrote:
Hello everyone I'm having a problem where users with more than 16 group memberships are unable to perform operations on files or directories that live on NFS volumes and are owned by groups that they are members of. This seems to be the classic and documented RPC spec limit as blogged about at http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/ and discussed in various forum posts when doing web searches for the old 7-mode option "nfs.authsys.extended_groups_ns.enable" and "nfs.max_num_aux_groups".
I've found the cDOT options "auth-sys-extended-groups" and "extended-groups-limit" within the "vserver nfs" tree, and have adjusted them to "enabled" and "64" (my test user is a member of 29 groups). However, the problem I am observing still remains. I tried unmounting and remounting my test volume on my test host (RHEL7.3 x86_64) with no observable change in behavior.
My SVMs are talking LDAP to Active Directory in a Windows 2008R2 forest level. My SVM LDAP client schema is a copy of AD-IDMU with a single change, uid-attribute is set to sAMAccountName.
If I go into diag mode and issue "getxxbyyy getgrlist -vserver MySvm -username MyTestUser -node MyNode", I get back this: pw_name: MyTestUser Groups: 1154000513
While still in diag mode I issue "secd authentication show-creds -node MyNode -vserver MySvm -unix-user-name MyTestUser" and get back: UNIX UID: MyTestUser <> Windows User: MyDomain\MyTestUser (Windows Domain User)
GID: Domain Users Supplementary GIDs: Domain Users
Windows Membership: *(A list of 29 other groups as defined in Active Directory)* BUILTIN\Users (Windows Alias) User is also a member of Everyone, Authenticated Users, and Network Users
So it looks like getxxbyyy is either only getting back the users' primary group, or its not enumerating the supplementary group memberships?
Based on some suggestions from Support, I tried changing the LDAP client configuration to use port 3268 (global catalog) instead of 389 (ldap) but that actually resulted in no user information being returned. I also tried setting a preferred DC within the LDAP client configuration (option "preferred-ad-servers") with no change in returned data. I tried setting a preferred DC with the ldap server port back at 389 too, no difference.
Our DNs do have commas in them. Example taken from within AD: CN=Lastname, Firstname,OU=SomeDivision,OU=SomeCompany,DC=SomeDomain,DC=SomeBigOrg,DC=com . Could this cause problems? I did see some brief mention of an old hidden 7-mode option "ldap.skip_cn_unescape.enable" but can't find a cDOT equivalent. Does anyone have experience with this problem and can provide some hints? Thanks!
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters