Hi,

I am trying to enable more than the default 16 groups for NFS connection via SYS_AUTH to a NetApp filer, but not having any success. Can anyone shed some light?

The issue is present in our production environment, but to get to the bottom of it I have created a virtual appliance with 'NetApp Release 8.1.4 7-Mode', which matches Production. The appliance is set-up to use our Active Directory domain and on the appliance I can use 'wcc' to successfully query users and groups. I have set 'nfs.authsys.extended_groups_ns.enable on' and 'nfs.max_num_aux_groups 256'.

My NFS client is running recently patched RH Enterprise Linux 6.6 and I am testing with my own user account that is a member of more than 16 groups. To test the functionality I create one file for each of the groups I belong to and set the permissions so that write is only possible by a group (not user or other). Writing to each file is there by dependent on a different group. As I can use chrgp successfully to setup each of these files I think it proves that AD, the Linux Client and the NetApp are all in step regarding groups. However, when I try to write to each of these groups in turn I am successful only with the first 16, which is the same behaviour as if 'nfs.authsys.extended_groups_ns.enable' was set to 'off'. I have tried using NFS 3 and 4 without success.

To prove there is no issue on the Linux Client I used another Linux server to create an NFS export and set the '--manage-gids' option on rpc.mountd. After mounting that export on the client machine I repeated the test of creating the files, setting their permissions and attempting to write to each in turn. I could write to all the files, which proves that if the NFS server is configured to use '--manage-gids' correctly the client can support it.

If I understand correctly then by enabling 'nfs.authsys.extended_groups_ns.enable' group enumeration is shifted from the client request (the groups of which are ignored) to the NetApp, which picks up the additional task of going to AD to find out what groups the requesting account is a member of. Therefore it seems likely the netapp is not capable of enumerating an accounts groups, but when I check with wcc it seems that it is. I get data back that looks like this (names changed to protect the innocent):

wcc -u fred.bloggs
(NT - UNIX) account name(s): (MYDOMAIN\fred.bloggs - fred.bloggs)
***************
UNIX uid = 10225
user is a member of group MYGROUP (10042)

NT membership
MYDOMAIN\fred.bloggs

<snipped lots of other groups from here>

BUILTIN\Users
User is also a member of Everyone, Network Users,
Authenticated Users
***************

So, after all that the questions I have are:

1. Is anyone using a NetApp with 'nfs.authsys.extended_groups_ns.enable on' successfully with a RHEL5, 6 or 7 client?

2. Does anyone know of a required configuration setting I have may not have set?

3. Am I correct in assuming that the output of wcc is a good way of verifying the appliance's ability to enumerate a user's groups?

4. Are there any logs on the netapp that could provide a clue as to what is going wrong (there is nothing in the logs exposed through the WebUI)?

5. Am I correct in my assumption that 'nfs.authsys.extended_groups_ns.enable on' works in the same way as '--manage-gids' does for rpc.mountd?

Thanks in advance for any assistance.

Regards,
r0tty

Hi,

I believe that this issue is resolved in my environment and that the following is a complete list of factors involved in the solution:

1. NFSv4 cannot make use of 'nfs.authsys.extended_groups_ns.enable' - it is limited to 16 groups if you are using auth_sys. To make use of auth_sys extended groups you must use NFSv3.

2. For 'nfs.authsys.extended_groups_ns.enable' Unix group enumeration needs to be working. This is not the same thing as user mapping or group mapping (which is not done by the NetApp anyway).

3. The output of 'wcc -u user.name' includes a list of groups an account is a member of from a Unix perspective as well as an NT (AD/LDAP) perspective. A more concise command for testing Unix group enumeration, which is what 'nfs.authsys.extended_groups_ns.enable' depends on, is 'getXXbyYY getgrlist user.name'. You should see the GID of every group.

4. If when using 'getXXbyYY getgrlist' you do not see a full list of groups you can experiment with options on the NetApp to get it working. To get it working in my environment I had to 'set ldap.rfc2307bis.enable' to 'off' and populate the 'memberuid' field of the group. That was surprising to me as our AD schema is rfc2307biz and I expected group membership to come from other fields.

Regards,
R0tty

Hello r0tty,

sorry for upping an old topic, but you might have succeed to implement the exact configuration I am trying to do in my company. Please, get in touch with me! I forgot the idea of an heterogeneous share after so much work and research, but now I see your post!

We have a NetApp filer, Windows and Linux clients. I tried many different configurations to make shares accessible from both Windows and Linux, with Windows ACL applying to both systems. I came accross different solutions, but none were stable (including kerberos). "wcc -u name" returns that the Unix account does not exist, and "wcc -s name" returns any "name" value mapped to "pcuser". Where the filer is supposed to find those Unix accounts from?

I'd like to know: how did you manage to have the filer mapping all NT accounts to Unix accounts ? Did you make new local user on the NetApp for each Linux user ? Have you set Unix attributes on the Active Directory? Or how ??

My situation : NetApp filer, 7-Mode. Our AD is declared as LDAP server for CIFS. I can post more details tomorrow when at work. Our Linux clients are not integrated to the domain yet, but I have a working configuration (test stage) with winbind and with idmap backend = rid, from 10000000 to 39999999. Is that ok, or should I set Unix attributes in the AD and set the idmap backend to "ad"? Or should I forget this kind of integration?

I really have troubles when dealing with this NetApp, as I work here since only 6 months, and it is not my unique colleague who configured it (it's a sysadmin in an other country, who never have the time to help us, and he doesn't know either how to set name mapping).

Thank you so much if you contact me! Please, moderators, don't lock me out, neither this topic! Thanks!