OK, I think we’re getting closer. Got some excellent feedback (thanks!).

 

The real filer that I’m trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it’s added to our AD. But so far it’s only serving NFSv2 with auth_sys. Now I’m trying to enable the extended_groups magic and I’m guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.

 

Added this to the usermap.cfg file:

NTDOM\* == *

 

Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.

 

Another new clue, running “getXXbyYY getpwbyname_r whoever” at the shell on the filer returns “Could not get passwd entry for name = whoever.” Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I’m trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that’s running multiprotocol, the user resolves.

 

What step have I missed?

 

Randy in Sunny Seattle

 

 

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy
Sent: Wednesday, April 09, 2014 2:59 PM
To: toasters@teaparty.net
Subject: RE: nfs.authsys.extended_groups_ns.enable?

 

While we are using a netgroup file to allow access to the export, we’re not actually running NIS. We do it this way on other filers and I’m guessing it’s working as I can mount the volume just fine, the problem is when I su to a user and try to touch the file system.

 

Good idea on the cli tools, will try that…

 

From: Payne, Richard [mailto:richard.payne@amd.com]
Sent: Wednesday, April 09, 2014 9:15 AM
To: Rue, Randy; toasters@teaparty.net
Subject: RE: nfs.authsys.extended_groups_ns.enable?

 

“I used cifs setup to add the filer to our AD”

 

Hmmm….we’re using traditional NIS so I’m not sure what else might need to be setup there.

 

I know from diag mode you can use ‘getXXbyYY’ to see which groups the filer thinks the user(s) are in.

 

--rdp

 

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy
Sent: Wednesday, April 09, 2014 12:08 PM
To: toasters@teaparty.net
Subject: RE: nfs.authsys.extended_groups_ns.enable?

 

Had the feature enabled and the max_num at the default 32. Shouldn’t make much difference as in this test case the user is a member of 17 groups. Upped it to 256 anyway.

 

No luck. “id” shows the user is a member of the right group(s) but access is denied.

 

Have I missed some other more basic step in configuring the simulator from scratch? Can anyone think of anything obvious or anything that changed from 8.1 to 8.2?

 

Randy in Seattle

 

From: Payne, Richard [mailto:richard.payne@amd.com]
Sent: Thursday, April 03, 2014 10:01 AM
To: Rue, Randy; toasters@teaparty.net
Subject: RE: nfs.authsys.extended_groups_ns.enable?

 

Yes, we make extensive use of this feature, you need to set:

 

nfs.authsys.extended_groups_ns.enable on        

nfs.max_num_aux_groups       256       

 

--rdp

 

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy
Sent: Thursday, April 3, 2014 9:58 AM
To: toasters@teaparty.net
Subject: RE: nfs.authsys.extended_groups_ns.enable?

 

Is anyone using this feature to allow access to NFS  for users who are members of more than 16 groups? What setup was required?

 

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy
Sent: Wednesday, April 02, 2014 6:51 AM
To: toasters@teaparty.net
Subject: RE: nfs.authsys.extended_groups_ns.enable?

 

Hello Again All,

 

Phase 2 of this puzzle is making this new setting work.

 

I’ve mounted a test volume on the 8.2 simulator to our HPC cluster and am su’d to an account that is a member of 17 groups. “id” shows me all seventeen groups. “ls –l” shows me directories that the user ‘s individual group owns, and directories owned by groups he’s a member of, and all with the appropriate permissions. But he’s unable to cd into any of them, or to write anything to the pwd (which is owned by a group he’s a member of).

 

I used cifs setup to add the filer to our AD and that fact that “id” gets all his groups suggests his AD account is resolving correctly on the client. Did I miss a step in setting up the filer?

 

Hope to hear from you,

 

Randy in Seattle

 

From: Rue, Randy
Sent: Thursday, March 27, 2014 4:00 PM
To: toasters@teaparty.net
Subject: RE: nfs.authsys.extended_groups_ns.enable?

 

Figured this out with some help from you all.

 

We’re running 8.1 and this option is only supported 8.1.1 and onward for :  https://communities.netapp.com/thread/20549

 

Confirmed it on a 8.2 simulator. Still needed to use registry walk and set to even see/set the option but it is there. Once you’ve set it, even in non-privileged mode it appears if you run options nfs.

 

Thanks to all!

 

Randy

 

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy
Sent: Thursday, March 27, 2014 2:02 PM
To: toasters@teaparty.net
Subject: nfs.authsys.extended_groups_ns.enable?

 

Hello All,

 

Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a “hidden” option “nfs.authsys.extended_groups_ns.enable” that will effectively disable group lookups via auth_sys/RPC and instead look to the filer’s AD authentication for a user’s group memberships. This is similar in spirit to Isilon’s “mapuid” feature and “regular” NFS’s –manage-gid switch.

 

But I’ve tried in regular mode, priv set advanced and priv set diag, and I always get “No such option nfs.authsys.extended_groups_ns.enable” if I try to view or change the option.

 

Am I missing some step to make this hidden double-secret-probationary option available?

 

Randy