We have been aware of the "too many groups" problem and we check for that occassionally, but we still get the "cannot encode" or "decode arguments" error from time to time. I'm hoping someone with more time will find out why and thought this a possibility. (TCPDUMP is not enabled in any of our systems by security policy, thus the time to isolate a machine, build a packet filtering kernel, test, ...)
Is there any possibility that NetApp will support the "non-standard" (but adopted by several) more than 16 groups?
At 4:17 PM -0700 4/30/99, Guy Harris wrote:
There could be some confusion in the protocol. exported readonly and mounted with world write permission?
Maybe it is just an incorrect error message.
I think Eric Werme got it right (not surprising, as he's one of the engineers working on Digital^H^H^H^H^H^H^HTru64 UNIX's NFS at Digital^H^H^H^H^H^H^HCompaq), as quoted in Ms. Gaski's most recent mail:
From: Eric Werme USG werme@zk3.dec.com To: "Dr. Tom Blinn, 603-884-0646" tpb@doctor.zk3.dec.com, Joanna Gaski jgaski@WPI.EDU Subject: Re: This is an interesting NFS interop problem.. Date: Tue, 27 Apr 1999 09:25:48 -0400
There is a very good chance that the client user is in more than 16 groups. You can check this with the groups command:
% groups staff mem contribAt one point Sun sent us new ONC_NFS code with the group limit raised to 32. This overflows some data structures and the size of the RPC authentication area, but it seems too late to retract that, though perhaps we should. Sun did - they received a customer complaint that 32 groups wasn't enough (that change made it into Solaris too), and Sun reduced the group size back to 16. Never heard what the customer said about that.
The secondary group set size in ONTAP is 16, so you can be in at most 17 groups (assuming your client OS doesn't add your primary group to the secondary group set; if it does, the limit is 16 groups).
He's also right when he says:
Including tcpdump data when reporting NFS problems is very important. See the Digital UNIX FAQ for details.
Network traces are very very very very very very very very very useful when diagnosing a whole bunch of problems.
(However, tcpdump doesn't decode the authentication data, so it would take a hex display to verify my diagnosis.)
One of these days, I hope to get Ethereal:
to handle ONC RPC and at least some protocols that run atop it, e.g. NFS (although there's a bunch of infrastructure stuff I need to put in first); at that point, Ric can use it instead, and I'll make damn sure it can decode authentication data.... ("tcpdump" is better than a poke in the eye with a sharp stick when it comes to analyzing NFS packet traces, but it's nowhere near as good as "snoop"....)
}}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov (925) 422-4018 Page: 423-7705x57152