We're running an F740 currently running ONTAP 6.1.3R2 (though this has been a problem for as long as we've had a filer).
We run our main filesystem with UNIX-style file permissions, and have both NFS and CIFS running.
The problem we have is that if a user is in more than 16 groups, the filer will ignore the 17th and higher groups, as if that user is not a member. This is only a problem on the CIFS/Windows side.
As far as I know, this is not an inherent Windows limitation, but a NetApp problem.
Does anyone else run into this... how do you work around the issue (we've got a lot of engineers in many project groups, so we've got to juggle them around in the groups file to minimize the problem)?
thanks
johnS
On Wed, May 05, 2004 at 01:22:48PM -0500, Stewart, John wrote:
We run our main filesystem with UNIX-style file permissions, and have both NFS and CIFS running.
The problem we have is that if a user is in more than 16 groups, the filer will ignore the 17th and higher groups, as if that user is not a member. This is only a problem on the CIFS/Windows side.
NFS itself has a limit of 16 groups for user credentials.
With UNIX-style file permissions there shouldn't be an influence caused by CIFS groups. Ontap will ignore these and base file access permissions on the UNIX uid and UNIX gids (as defined in the group file or NIS) for that uid.
Greetings,
We're running an F740 currently running ONTAP 6.1.3R2 (though this has been a problem for as long as we've had a filer).
We run our main filesystem with UNIX-style file permissions, and have both NFS and CIFS running.
The problem we have is that if a user is in more than 16 groups, the filer will ignore the 17th and higher groups, as if that user is not a member. This is only a problem on the CIFS/Windows side.
As far as I know, this is not an inherent Windows limitation, but a NetApp problem.
Does anyone else run into this... how do you work around the issue (we've got a lot of engineers in many project groups, so we've got to juggle them around in the groups file to minimize the problem)?
Both NFS and CIFS have limits on the number of groups you can belong to. Being stateless, each NFS packet contains your primary group and a list of other groups that you belong to. These are group id numbers (gids) so they don't take up a lot of space, but I believe that the size of this list is fixed in NFS at 16 or 32. The NFS client determines your primary group and group membership list when you login to the NFS client. That is why it is important that user id numbers and group id numbers are consistent on the filer and NFS clients. NIS comes in very handy for this.
A Unix workaround is the "newgrp" command. You use this command to change your primary group to any group that you belong to, regardless of where it is listed in the group file. Since your primary group is a separate field in NFS packets than the group membership list, this effectively forces a "missing" group into your NFS credentials.
By the way, the "primary group" is just like any other group that you belong to except that when you create a new file or directory, it gets your primary group. This behavior can be overridden by enabling setgid on the parent directory. But I digress ...
When you use Unix-style permissions with CIFS, each CIFS user gets mapped to a Unix user who is either in /etc/passwd or a NIS map. You may be using /etc/passwd or a NIS map for authentication instead of a Windows domain controller, in which case the user maps directly to his Unix identity.
When the user logs in to CIFS the filer builds the group membership list from /etc/group on the filer or from a NIS map. Offhand, I don't know what the filer's limit on the group membership list is, but it sounds like you have discovered that it is 16. I do know that if you change /etc/group or the NIS map that the user must logout from CIFS and login again because the group membership list is only constructed once at login.
Perhaps a newer version of ONTAP has extended the group membership limitation for CIFS.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
-
Michael van Elst -
Steve Losen -
Stewart, John