Have an NTFS volume being shared out via NFSV3. SVM is part of AD and NIS.
When an NIS-joined client lists directories under the export, everything seems to be mapped to UID 65534. I'm able to validate this:
::*> vserver security file-directory show -vserver file_ntfs -path /setup-staging/raytest_windows
Vserver: file_ntfs File Path: /setup-staging/raytest_windows File Inode Number: 1317151 Security Style: ntfs Effective Style: ntfs DOS Attributes: 10 DOS Attributes in Text: ----D--- Expanded Dos Attributes: - UNIX User Id: 65534 UNIX Group Id: 65534 UNIX Mode Bits: 777 UNIX Mode Bits in Text: rwxrwxrwx ACLs: NTFS Security Descriptor Control:0x8004 Owner:DOMAIN\rvandolson Group:DOMAIN\Domain Users DACL - ACEs ALLOW-Everyone-0x1f01ff-(Inherited) ALLOW-Everyone-0x10000000-OI|CI|IO (Inherited)
However, the following makes me think the filer knows how to map AD usernames to Unix (NIS) usernames just fine:
::*> diag secd name-mapping show -vserver file_ntfs -direction win-unix -name DOMAIN\rvandolson -node red-str-napcl-p03-02
ATTENTION: Mapping of Data ONTAP "admin" users to UNIX user "root" is enabled, but the following information does not reflect this mapping.
'DOMAIN\rvandolson' maps to 'rvandolson'
::*> diag secd authentication translate -node red-str-napcl-p03-02 -vserver file_ntfs -unix-user-name rvandolson 580345
I don't have a default-win-user set:
::*> vserver nfs show -vserver file_ntfs -fields default-win-user vserver default-win-user --------- ---------------- file_ntfs
(but I think the default is 65534).
Shouldn't cDOT be returning 580345 for the UNIX User Id rather than 65534? Seems to be the case on 7-mode...
Thanks! Ray
Been a while, but I think your svm may be set up to check nis first, then ad. Since it finds the user in nis, it uses that.
I can't tell you the commands offhand, but you may want to check your name service resolution....
On Tue, Feb 14, 2017 at 6:59 PM Ray Van Dolson rvandolson@esri.com wrote:
Have an NTFS volume being shared out via NFSV3. SVM is part of AD and NIS.
When an NIS-joined client lists directories under the export, everything seems to be mapped to UID 65534. I'm able to validate this:
::*> vserver security file-directory show -vserver file_ntfs -path /setup-staging/raytest_windows
Vserver: file_ntfs File Path: /setup-staging/raytest_windows File Inode Number: 1317151 Security Style: ntfs Effective Style: ntfs DOS Attributes: 10DOS Attributes in Text: ----D--- Expanded Dos Attributes: - UNIX User Id: 65534 UNIX Group Id: 65534 UNIX Mode Bits: 777 UNIX Mode Bits in Text: rwxrwxrwx ACLs: NTFS Security Descriptor Control:0x8004 Owner:DOMAIN\rvandolson Group:DOMAIN\Domain Users DACL - ACEs ALLOW-Everyone-0x1f01ff-(Inherited) ALLOW-Everyone-0x10000000-OI|CI|IO (Inherited)
However, the following makes me think the filer knows how to map AD usernames to Unix (NIS) usernames just fine:
::*> diag secd name-mapping show -vserver file_ntfs -direction win-unix -name DOMAIN\rvandolson -node red-str-napcl-p03-02
ATTENTION: Mapping of Data ONTAP "admin" users to UNIX user "root" is enabled, but the following information does not reflect this mapping.
'DOMAIN\rvandolson' maps to 'rvandolson'
::*> diag secd authentication translate -node red-str-napcl-p03-02 -vserver file_ntfs -unix-user-name rvandolson 580345
I don't have a default-win-user set:
::*> vserver nfs show -vserver file_ntfs -fields default-win-user vserver default-win-user
file_ntfs
(but I think the default is 65534).
Shouldn't cDOT be returning 580345 for the UNIX User Id rather than 65534? Seems to be the case on 7-mode...
Thanks! Ray _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
On Wed, Feb 15, 2017 at 12:04:07AM +0000, tmac wrote:
Been a while, but I think your svm may be set up to check nis first, then ad. Since it finds the user in nis, it uses that.
I can't tell you the commands offhand, but you may want to check your name service resolution....
Thanks, I'll see if I can find something on that. Via the GUI (I'm a cDOT newb), I can see under the SVM Services tab that order preference is files and then nis for 'passwd'. So perhaps AD's role in all this is defined elsewhere...
Ray
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?
What does "diag secd authentication show-creds -list-id true -list-name true" give for that user?
You could try enabling secd tracing to see what exactly happens during the requests, as well. (diag secd trace set -trace-all yes)
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Ray Van Dolson Sent: Tuesday, February 14, 2017 3:56 PM To: toasters@teaparty.net Subject: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534
Have an NTFS volume being shared out via NFSV3. SVM is part of AD and NIS.
When an NIS-joined client lists directories under the export, everything seems to be mapped to UID 65534. I'm able to validate this:
::*> vserver security file-directory show -vserver file_ntfs -path /setup-staging/raytest_windows
Vserver: file_ntfs File Path: /setup-staging/raytest_windows File Inode Number: 1317151 Security Style: ntfs Effective Style: ntfs DOS Attributes: 10 DOS Attributes in Text: ----D--- Expanded Dos Attributes: - UNIX User Id: 65534 UNIX Group Id: 65534 UNIX Mode Bits: 777 UNIX Mode Bits in Text: rwxrwxrwx ACLs: NTFS Security Descriptor Control:0x8004 Owner:DOMAIN\rvandolson Group:DOMAIN\Domain Users DACL - ACEs ALLOW-Everyone-0x1f01ff-(Inherited) ALLOW-Everyone-0x10000000-OI|CI|IO (Inherited)
However, the following makes me think the filer knows how to map AD usernames to Unix (NIS) usernames just fine:
::*> diag secd name-mapping show -vserver file_ntfs -direction win-unix -name DOMAIN\rvandolson -node red-str-napcl-p03-02
ATTENTION: Mapping of Data ONTAP "admin" users to UNIX user "root" is enabled, but the following information does not reflect this mapping.
'DOMAIN\rvandolson' maps to 'rvandolson'
::*> diag secd authentication translate -node red-str-napcl-p03-02 -vserver file_ntfs -unix-user-name rvandolson 580345
I don't have a default-win-user set:
::*> vserver nfs show -vserver file_ntfs -fields default-win-user vserver default-win-user --------- ---------------- file_ntfs
(but I think the default is 65534).
Shouldn't cDOT be returning 580345 for the UNIX User Id rather than 65534? Seems to be the case on 7-mode...
Thanks! Ray _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
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
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
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
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
(Apologies for the URL mangling below -- darn Corporate email)
So, have found a workaround for this. By explicitly changing the AD owner on the file(s) in question (well, not really changing -- I just re-set the owner explicitly to the owner which was already set), something jogged in the NetApp's brain and it can now properly map the owner to a valid UID. As mentioned, this is bizarre, since the owner is EXACTLY the same as it was originally and a comparison of the vserver security file-directory show output before and after shows no notable differences other than the expected Unix UID/GID's now displayed.
So, these files were initially populated via a robocopy copy from Windows. I suspect something with the original syntax resulted in the ACL being "off" enough to confuse cDOT. I'll need to do some additional testing on that, but have confirmed that if I use the /MIR /SEC /COPY:DATO arguments to robocopy, the owner is preserved in such a way that cDOT is able to properly map that owner to a Unix UID/GID.
Ray
On Wed, Feb 15, 2017 at 07:07:15PM +0000, Parisi, Justin wrote:
I cover the fsecurity equivalent a bit here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__whyistheinternetbroken....
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
Well, you might have also fixed something or a cache flushed between the last time you ran it and now. :)
On 2/17/17, 10:59 AM, "Ray Van Dolson" rvandolson@esri.com wrote:
(Apologies for the URL mangling below -- darn Corporate email)
So, have found a workaround for this. By explicitly changing the AD owner on the file(s) in question (well, not really changing -- I just re-set the owner explicitly to the owner which was already set), something jogged in the NetApp's brain and it can now properly map the owner to a valid UID. As mentioned, this is bizarre, since the owner is EXACTLY the same as it was originally and a comparison of the vserver security file-directory show output before and after shows no notable differences other than the expected Unix UID/GID's now displayed.
So, these files were initially populated via a robocopy copy from Windows. I suspect something with the original syntax resulted in the ACL being "off" enough to confuse cDOT. I'll need to do some additional testing on that, but have confirmed that if I use the /MIR /SEC /COPY:DATO arguments to robocopy, the owner is preserved in such a way that cDOT is able to properly map that owner to a Unix UID/GID.
Ray
On Wed, Feb 15, 2017 at 07:07:15PM +0000, Parisi, Justin wrote:
I cover the fsecurity equivalent a bit here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__whyistheinternetbrok en.wordpress.com_2017_01_24_mixed-2Dperceptions-2Dmultiprotocol-2Dnas_&d= DwIFAg&c=n6-cguzQvX_tUIrZOS_4Og&r=WoGou9bjN14EvLKS6DHxfMEG6f2_bRhXNpedbbF oYDk&m=s4PaKdj-_NUkc_ec1eveH2WdRjGE_m333D0Y2iD_vG0&s=1JMEtwOhwsYwPLMLM1Zx _syN-6uq68TcuLgLbIVtUEc&e=
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
-
Parisi, Justin -
Ray Van Dolson -
tmac