I cover the fsecurity equivalent a bit here:
https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-mu...
It sounds like the issue might be UNIX -> Windows mapping rather than Windows -> UNIX.
Does this issue happen on files that get created from NFS only? Do the clients leverage LDAP/NIS?
SecD tracing should help us see who that user is coming in as and why it's mapping the way it is. It's more useful for authentication issues (like this) than authorization (permission) issues.
If you can unicast me the cluster SN so I can see the secd trace, I can have a look.
-----Original Message----- From: Ray Van Dolson [mailto:rvandolson@esri.com] Sent: Tuesday, February 14, 2017 7:16 PM To: Parisi, Justin Justin.Parisi@netapp.com Cc: toasters@teaparty.net Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534
Well, no joy yet. The secd tracing didn't help too much as I'm not really encountinger a permissions denied situation, just an enumeration issue.
It *seems* like the NetApp is not handling the NTFS owner correctly. What's weird is that if I go into a file from the Windows side and take ownership of the account using *my* AD account, then the AD username -> Unix UID works correctly and I see the expected username listed via NFS.
What I'm struggling with now is getting it to let me change the owners on all of the files to someone other than myself. I keep getting an error "You do not have the Restore privilege required". I've added my AD username to the BUILTIN\Administrators group on the SVM (I think!), but still no joy. Maybe I actually need to have a Domain Administrator account do this, or try via whatever the cDOT equivalent of fsecurity is (though my recollection is that that's kind of a PITA).
Ray
On Wed, Feb 15, 2017 at 12:43:42AM +0000, Parisi, Justin wrote:
Yea, if the GID lookup fails it can fall back to 65534 in some cases.
-----Original Message----- From: Ray Van Dolson [mailto:rvandolson@esri.com] Sent: Tuesday, February 14, 2017 4:42 PM To: Parisi, Justin Justin.Parisi@netapp.com Cc: toasters@teaparty.net Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534
On Wed, Feb 15, 2017 at 12:26:24AM +0000, Parisi, Justin wrote:
65534 is "pcuser" on a NetApp storage system. That's the user a Windows user gets mapped to when they write to a NTFS security style volume when they can't map to a specific user. It's the default UNIX user, not the default Windows user that's being leveraged.
Likely an issue with the name services. What does "name-service ns-switch show" give as the config?
::*> name-service ns-switch show -vserver file_ntfs (vserver services name-service ns-switch show) Source Vserver Database Order
file_ntfs hosts files, dns file_ntfs group files, nis file_ntfs passwd files, nis file_ntfs netgroup files file_ntfs namemap files 5 entries were displayed.
NOTE: I *just* changed group to include nis.
What does "diag secd authentication show-creds -list-id true -list-name true" give for that user?
::*> diag secd authentication show-creds -list-id true -list-name true -node red-str-napcl-p03-02 -vserver file_ntfs -win-name DOMAIN\step
UNIX UID: 1180 (step) <> Windows User: S-1-5-21-2050139532-2050374463-XXXXXXXXXX-2719 (DOMAIN\step (Windows Domain User))
GID: 129 (micro) Supplementary GIDs: 129 (micro) 8001 (logs) 0 (root) 55 (lxadmin) 14 (sysadmin)
Windows Membership:
<many groups listed>
User is also a member of Everyone, Authenticated Users, and Network Users
Privileges (0x2080): SeChangeNotifyPrivilege
I'll note here as well that the first time I ran this command, it complained about being unable to look up the Unix GID. This is when I added nis to the services list for group above.
You could try enabling secd tracing to see what exactly happens during the requests, as well. (diag secd trace set -trace-all yes)
I'll give this a try next.
Ray