On Fri, Sep 2, 2011 at 4:12 AM, Marc Bevand wrote:
> On my domain controller, I created an AD user account plus a keytab file for
> this account using ktutil.exe, which was then copied to the Linux NFSv4
> client as /etc/krb5.keytab. This client has the standard Kerberos tools
> installed and i
On Mon, Aug 29, 2011 at 2:16 PM, Marc Bevand wrote:
> Nico wrote:
>> Given the name-based mapping rules that you give below, do you have a Unix
>> user account called "myuser"?
>
> In this test, no, I did not have a Unix account "myuser". Therefore it is not
> a bug in nss_ad.
>
> As Jordan conc
On Mon, Aug 29, 2011 at 6:58 PM, Jordan Brown wrote:
> On 08/29/11 12:16, Marc Bevand wrote:
>> I wish Oracle would
>> fix this. In the mean time I can live with having to create the local
>> Unix account to prevent files owned by nobody.
>
> As Nico said, we'd like to fix it too - or, rather, we'
On my domain controller, I created an AD user account plus a keytab file for
this account using ktutil.exe, which was then copied to the Linux NFSv4 client
as /etc/krb5.keytab. This client has the standard Kerberos tools installed and
is "seen" as being a Windows AD user by any Kerberized networ
On 09/01/11 11:51, Marc Bevand wrote:
Solaris 11 Express is snv_151a, and idmap does support the -V option.
I set the debug/mapping property to 2, refreshed idmap, (and
additionally ran "idmap flush"), unfortunately I see no trace in the log
when my NFSv4 client logs in and creates a file. I kno
Solaris 11 Express is snv_151a, and idmap does support the -V option.
I set the debug/mapping property to 2, refreshed idmap, (and additionally ran
"idmap flush"), unfortunately I see no trace in the log when my NFSv4 client
logs in and creates a file. I know the debugging options are correctly
On 08/30/11 14:50, Marc Bevand wrote:
It did not work.
No matter what nfsmapid_domain is set to (any-other-name.com or
example.com), files created on the ZFS file system by my Kerberized
NFSv4 client always end up owned by nobody. I even rebooted the Solaris
server and the client after each chan
It did not work.
No matter what nfsmapid_domain is set to (any-other-name.com or example.com),
files created on the ZFS file system by my Kerberized NFSv4 client always end
up owned by nobody. I even rebooted the Solaris server and the client after
each change to make sure I did not forget to r
On 08/29/11 21:28, Marc Bevand wrote:
So are you saying I should try after "sharectl set -p
nfsmapid_domain=any-other-name.com nfs" and ownership should be handled correctly? I
will try tomorrow.
That might work. What *wouldn't* work in that configuration was any user
that was only a UNIX u
Thank you so much for all these insightful explanations Jordan.
I might consider setting up LDAP eventually, but not now.
Jordan wrote:
> Is example.com your AD domain?
Yes. And my NFS client is Ubuntu 8.04 with the krb5-user and krb5-config
packages installed, a /etc/krb5.keytab file, and the
On 08/29/11 12:16, Marc Bevand wrote:
As Jordan concluded, not having a Unix account "myuser" is officially
unsupported, and my strange observation is explained by the fact there
_is_ a code path (affecting both tmpfs and ZFS, but Jordan did not say
where exactly) mapping myu...@example.com to no
On 08/29/11 11:54, Marc Bevand wrote:
This is correct.
When the Unix account myuser exists:
# id
uid=0(root) gid=0(root)
# su - myu...@example.com
su: No directory! Using home=/
$ id
uid=10111(myuser) gid=2147483691(Domain us...@example.com)
When it does _not_ exist:
$ id
uid=2147483650(myu..
Nico wrote:
> Given the name-based mapping rules that you give below, do you have a Unix
> user account called "myuser"?
In this test, no, I did not have a Unix account "myuser". Therefore it is not a
bug in nss_ad.
As Jordan concluded, not having a Unix account "myuser" is officially
unsuppor
This is correct.
When the Unix account myuser exists:
# id
uid=0(root) gid=0(root)
# su - myu...@example.com
su: No directory! Using home=/
$ id
uid=10111(myuser) gid=2147483691(Domain us...@example.com)
When it does _not_ exist:
$ id
uid=2147483650(myu...@example.com) gid=2147483691(Domain us.
On Wed, Aug 24, 2011 at 4:44 PM, Marc Bevand wrote:
> I run Solaris 11 Express, successfully joined an AD domain with "smbadm join"
> and with a proper Kerberos config like [1]. Can anybody tell me why files
> created by these users locally (on Solaris itself, not through CIFS!) end up
> with t
On 08/25/11 16:12, Jordan Brown wrote:
The ZFS behavior is easy to explain. If there's a mapping between the
Windows account and the UNIX account, we use the UNIX account in file
metadata.
In fact, I suspect (and verification is left as an exercise for the reader)
that in this case when you lo
On 08/24/11 20:06, Marc Bevand wrote:
Yes, I have "ad": $ grep -w ad /etc/nsswitch.conf passwd: files ad
group: files ad
My problem is not caused by tmpfs, because I observe the same behavior
with zfs.
Hmm. That's odd.
Something else that disproves your theory (sorry :D) is that tm
Yes, I have "ad":
$ grep -w ad /etc/nsswitch.conf
passwd: files ad
group: files ad
My problem is not caused by tmpfs, because I observe the same behavior with zfs.
Something else that disproves your theory (sorry :D) is that tmpfs is perfectly
capable of recording AD ownership: I can "
On 08/24/11 14:44, Marc Bevand wrote:
I run Solaris 11 Express, successfully joined an AD domain with "smbadm
join" and with a proper Kerberos config like [1]. Can anybody tell me
why files created by these users locally (on Solaris itself, not through
CIFS!) end up with the ownership of 'nobody'
I run Solaris 11 Express, successfully joined an AD domain with "smbadm join"
and with a proper Kerberos config like [1]. Can anybody tell me why files
created by these users locally (on Solaris itself, not through CIFS!) end up
with the ownership of 'nobody'?
# id
uid=0(root) gid=0(root)
# su
20 matches
Mail list logo
