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!
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. 🙂
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
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)
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).
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...