== The state of supporting many groups over NFS v3 in various Unixes

One of the long standing limits with NFSv3 is that [[the protocol
only uses 16 groups ../unix/GroupLimitState]]; although you can be
in lots of groups on both the client and the server, the protocol
itself only allows the client to tell the server about 16 of them.
This is a real problem for places (like us) who have users who want
or need to be in lots of groups for [[access restriction reasons
../sysadmin/NoACLTemptation]].

For a long time the only thing you could was shrug and work around
this by adding and removing users from groups as their needs changed.
Fortunately this has been slowly changing, partly because people
have long seen this as an issue. Because the NFS v3 protocol is
fixed, everyone's workaround is fundamentally the same: rather than
taking the list of groups from the NFS request itself, the NFS
server looks up what groups the user is in on the server.

(In theory you could merge the local group list with the request's
group list, but I don't think anyone does that; they just entirely
overwrite the request.)

As far as I know, the current state of affairs for various Unixes
that we care about runs like this:

* Linux has long supported an option to _rpc.mountd_ to do this,
  the _-g_ aka _--manage-gids_ option. See eg Kyle Anderson's
  [[Solving the NFS 16-Group Limit Problem
  http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/]]
  for more details. I have to optimistically assume that it's
  problem free by now, but I've never tried it out.

* Illumos and thus OmniOS gained support for this relatively recently.
  There is some minor system configuration required, which I've
  covered in [[Allowing people to be in more than 16 groups with
  an OmniOS NFS server ../solaris/OmniOSNFSManyGroups]]. We have
  tested this but not yet run it in production.

* FreeBSD has apparently supported this only since 10.3. To enable
  it, you run _nfsuserd_ with the new _-manage-gids_ flag, per
  [[the 10.3 _nfsuserd_ manpage
  https://www.freebsd.org/cgi/man.cgi?query=nfsuserd&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE&arch=default&format=html]].
  I suspect that you need to be using what FreeBSD calls the new
  NFS server with v4 support, not the old one; see [[the _nfsd_ manpage
  https://www.freebsd.org/cgi/man.cgi?query=nfsd&sektion=8&apropos=0&manpath=FreeBSD+10.3-RELEASE]].

* Oracle Solaris 11.1 apparently supports this, as reported by [[David
  Magda http://www.magda.ca/]] in a comment [[here GroupLimitState]].
  See [[Joerg Moellenkamp's blog entry on this
  http://www.c0t0d0s0.org/archives/7634-Less-known-Solaris-11.1-features-A-user-in-1024-groups-and-a-workaround-for-a-25-year-old-problem.html]].

I care about how widespread the support for this is because we've
finally reached a point where [[our fileservers
../solaris/ZFSFileserverSetupII]] all support this and so we could
start putting people in more than 16 groups, something that various
parties are very much looking forward to. So I wanted to know whether
officially adding support for this would still leave us with plenty
of options for what OS to run on future fileservers, or whether
this would instead be a situation more like [[ACLs over NFS
../sysadmin/NoACLTemptation]]. Clearly the answer is good news; basically
anything we'd want to use as a fileserver OS supports this, even
the unlikely candidate of Oracle Solaris.

(I haven't bothered checking out the state of support for this on
the other *BSDs because we're not likely to use any of them for an
NFS fileserver. Nor have I looked at the state of support for this
on dedicated NFS fileserver appliances, because I don't think we'll
ever have the kind of budget or need that would make any of them
attractive. Sorry, NetApp, you were cool once upon a time.)