NFS Anonymous Access

[Bob654]

Hi Folks!

We are having an issue with our NFS Exports on Data ONTAP. They appear to mount perfectly fine on various UNIX hosts, and are accessible as the "root" user, BUT, any other user (local accounts) get a "permission denied" when trying to access the mount.

This worked fine on our current 7-Mode system and not sure what I am missing here...

I have a generic Export policy assigned to this test mount that allows any host read/write access, which appears to be working, but how do I allow Anonymous user access?

When I added one of the local users to the "SVM Settings > Host Users and Groups" (to the 'root' group 0 I may add) they could then access the share! I'm not sure how this works.... Help!

If you need any outputs just ask.

Cheers!

[DJ-Potsdam]

Hi,

How are you?

what values do you have for "User ID To Which Anonymous Users Are Mapped" in your export-policy rule?

Default is 65534 to avoid root access by anonymous users. DO you want root access by anonymous users?

Thanks 

[Bob654]

Hi DJ-Potsdam,

Thanks for the reply. 🙂

Default user is currently 'pcuser' which is the ID you mention. I don't necessarily want Anon users to have root access but read access would be great. 🙂 This appears to work alreayd in our 7-Mode setup.

If giving them root is the only way I may just cave on that as I'm a bit fed up with investigating this (and other!) issues. 🙂

Cheers!

[DJ-Potsdam]

Hi,

Did you get a chance to read this:

https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.cdot-famg-nfs%2FGUID-E8B1E134-C9D4-4674-8911-D32F0B3D9BAE.html

Sorry if you have already gone through the examples there. Hope you can solve this ASAP

Cheers

[Bob654]

Thanks for the reply DJ-Potsdam, very useful link there. 🙂

I verified and adjusted my NFS Export Policies so that the Read Only (-ronly) variable was set to 'any' but this hasn't done anything. I also performed a 'check-access' on the volume:

nasw::vserver export-policy*> check-access -vserver NAS01w -volume intranet -client-ip 172.30.41.27 -authentication-method none -protocol nfs3 -access-type read
                                         Policy    Policy       Rule
Path                          Policy     Owner     Owner Type  Index Access
----------------------------- ---------- --------- ---------- ------ ----------
/                             transition_readonly 
                                         NAS01w_root 
                                                   volume          1 read
/intranet                     transition_export_policy_19 
                                         intranet  volume          1 read
2 entries were displayed.

Seems all good there!

So local 'root' has access to the shares... and if I add one of the local users to the OnCommand > SVM Settings > Host Users and Groups > UNIX, and add it to the 'root' group (EDIT: Scratch that, simply adding to 'pcuser' group is fine...) - BAM - they get access... oh me this is frustrating and no doubt a simple fix.

It seems like it's struggling to map UNIX (local) to UNIX (filer) accounts.... We have Windows Name Mapping active (so a UNIX account maps to an AD account, and vice-versa).

Thanks for everyone's help so far. 🙂

[Bob654 · Accepted solution]

Just an update folks:

I've given up for now and resorting to adding UNIX users to the filer - I've found out that the filer doesn't care about the Username all it cares about is the UID - my worry was that we can have many local UNIX users with the same Username but differing UIDs, so this can be worked around.

See how it goes with that for now but it's not my ideal solution...

Thanks again for everyones help thus far.

[ccdhb_ict]

Hi

Just checking that when you created the volume that you selected "UNIX" as the Security Style?  It's possible to create as NTFS or Mixed and you can get some weird permission problems from that. Happy to discuss over the phone if that helps. I can be reached on 64-4-8062200 direct or 64-21-809299

Cheers

Nick Wykes

3DHB, Wellington NZ

[Bob654]

Hi Nick,

Thanks for the reply.

The volumes have been migrated from our 7-Mode and have inherited the permissions. Most are UNIX, some are NTFS and some are mixed. Access problem occurs on all of them.

As mentioned these work fine on our current 7-Mode setup - fairly confident there isn't a default root permission for anon access on that - tried comparing as much settings as possible! (For example default UNIX user is still pcuser on old system)

Cheers