Mailing List Archive

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: 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
>
--
Sent from Gmail Mobile.

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534 [ In reply to ]

Feb 14, 2017, 4:07 PM

Post #3 of 10 (2668 views)

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
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

RE: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534 [ In reply to ]

Feb 14, 2017, 4:26 PM

Post #4 of 10 (2667 views)

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

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534 [ In reply to ]

Feb 14, 2017, 4:42 PM

Post #5 of 10 (2667 views)

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
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

RE: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534 [ In reply to ]

Feb 14, 2017, 4:43 PM

Post #6 of 10 (2667 views)

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

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534 [ In reply to ]

Feb 14, 2017, 7:15 PM

Post #7 of 10 (2666 views)

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
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

RE: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534 [ In reply to ]

Feb 15, 2017, 11:07 AM

Post #8 of 10 (2644 views)

I cover the fsecurity equivalent a bit here:

https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-multiprotocol-nas/

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

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534 [ In reply to ]

Feb 17, 2017, 7:59 AM

Post #9 of 10 (2631 views)

(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.wordpress.com_2017_01_24_mixed-2Dperceptions-2Dmultiprotocol-2Dnas_&d=DwIFAg&c=n6-cguzQvX_tUIrZOS_4Og&r=WoGou9bjN14EvLKS6DHxfMEG6f2_bRhXNpedbbFoYDk&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
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534 [ In reply to ]

Feb 20, 2017, 6:15 AM

Post #10 of 10 (2613 views)