I'm not sure what your problem is, but I can verify that internally here at NetApp we use DU 4.0D (rev 878) extensively on several Alpha machines against multiple filers with no issues. We have also run with 4.0E. What version of the filer software are you running?
Mark Muhlestein -- mmm@netapp.com
-----Original Message----- From: sirbruce@ix.netcom.com [mailto:sirbruce@ix.netcom.com] Sent: Monday, April 26, 1999 6:39 PM To: jgaski@WPI.EDU; toasters@mathworks.com Subject: Re: Digital UNIX clients -- no non-root access
On 04/26/99 21:11:27 you wrote:
I have an open call with Network Appliance, but they have said that there must be something strange in Compaq's implementation of the NFS client. The same error occurs on Digital UNIX 4.0D pl3, 4.0E pl1, and 5.0 beta. It occurs whether the mount is soft or hard, udp or tcp, nfsv3 or nfsv2.
It seems like such a large, ubiquitous error that I can't believe noone would have seen it before. I thought that Digital UNIX support was standard, and I can't imagine how all of our Alpha clients could be non-standard in such a way.
You'd be surprised. Lots of vendors have little quirks in their implementation that, while they happen to work okay with one server, are really out of spec and may not work with another.
However, I know that Digital Unix *used* to work, but the last I ever saw personally work was 4.0C. So either they've changed something, or something in the new Netapp release fixed/broke something.
Bruce
Muhlestein, Mark writes:
I'm not sure what your problem is, but I can verify that internally here at NetApp we use DU 4.0D (rev 878) extensively on several Alpha machines against multiple filers with no issues. We have also run with 4.0E. What version of the filer software are you running?
Data OnTap 5.2.1. (Although I would like to go to 5.3.) Have you tested with patched DU systems?
I should have mentioned in my first email:
- I can mount the area from a Solaris 2.6 system and access things without a problem. - The mount point is 755 before the mount, 777 afterward. - Network connection is currently 100tx.
Also, rerunning setup lists
Firmware rev: 1.15.2
but the NOW website lists 5.2.1 as needing 2.1_a2. This system shipped with 5.2.1 / 1.15.2, so I had expected compatibility. I suppose I need to update that?
However, it looks like DEC has found the source of the problem, because indeed the target user was in 20 groups, and the problem was not present for a user in fewer groups.
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 contrib
At 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.
Many Tru64 customers use NetApp boxes, and we ran into no problems testing against them at this year's Connectathon. (http://www.connectathon.org/)
I'll pass on Ultrix.
Including tcpdump data when reporting NFS problems is very important. See the Digital UNIX FAQ for details. (However, tcpdump doesn't decode the authentication data, so it would take a hex display to verify my diagnosis.)
-Ric Werme
-- Eric (Ric) Werme | werme@zk3.dec.com Compaq Computer Corp. | http://www.cyberportal.net/werme
from Joanna Gaski jgaski@WPI.EDU's first message "NFS3 RFS3_ACCESS failed for server toaster : RPC: Server can't decode arguments /mnt: I/O error
The exports file has the share exported with
-ro,access=hostname,root=hostname
where hostname is a FQDN."
and it is mounted with At 9:52 AM -0400 4/27/99, Joanna Gaski wrote: "The mount point is 755 before the mount, 777 afterward."
There could be some confusion in the protocol. exported readonly and mounted with world write permission?
Maybe it is just an incorrect error message.
}}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov (925) 422-4018 Page: 423-7705x57152
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 contrib
At 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"....)
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
One of these days, I hope to get Ethereal:
Did I say "ethereal.zing.net"? That was really stupid of me. It's
(I probably was thinking of the registrant for the "zing.org" domain, "Our Net Has Zing".)
-
guy＠netapp.com -
Jim Harm -
Joanna Gaski -
Muhlestein, Mark