Solaris is the best operating system on the planet in my opinion. Nothing new ;) . But that doesn’t imply that there are no dark corners in it driving me really nuts. Of of them was the default of 16 for the NGROUPS setting. The variable controls, in how many auxiliary groups a user can be placed. There was a good reason to keep it at 16. The AUTH_SYS authentication mechanism of NFS just supported 16 groups. The maximum value was 32, but that broke AUTH_SYS. While doing projects with Samba this was really problem sometimes. It was really annoying in some customer projects, that the maximum limit was 32, even when there was no use for AUTH_SYS at all. I could really live with a broken AUTH_SYS when doing just CIFS or NFS with more sophisticated authentication mechanisms,
Casper Dik must have heard my wishes to the divine entity of the non-existent kind and made a PSARC case for increasing the maximum number of auxiliary groups.
This project proposes changing the maximum value for NGROUPS_MAX from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 to 1024.
The reasoning for choosing 1024 as a new upper limit is quite easy.
The maximum number of groups SIDS in Microsoft appears to be 1024, see http://support.microsoft.com/kb/328889; this is how we arrived at the new maximum limit of 1024.
Having more than 16 groups still breaks AUTH_SYS but the behaviour of NFS in such a situation will be changed as well due to this ARC case:
As part of this case, we're change the "AUTH_SYS" semantics for RPC; rather than failing for users in more than 16 groups, we'd prefer to copy the semantics of others: just drop the additional groups and perform the operation with a reduced set of groups.
You will finde more information in the PSARC case 2009/542.