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 nobody.
I didn't say because it didn't seem like it'd be a useful piece of
information, but it's in the macro VOPXID_MAP_CR in
usr/src/uts/common/fs/vnode.c, used in quite a number of file-oriented
operations. It uses a dummy "nobody" credential when the file system in
question doesn't advertise support for SIDs and the process credential has
a SID.
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'd like to add the
feature of allowing Windows users to log in - but there's a bunch of issues
and it just hasn't made it to the top of the stack.
Note that if you're careful you can configure your system to use your AD
server as its UNIX LDAP server, which brings you closer to being able to
support these users without manually creating UNIX users.
With that explained, what about NFS (I use that too)? To summarize the
tests I ran (when there is no Unix account "myuser"):
1. A file created remotely via CIFS (as myu...@example.com) ends up
owned by myu...@example.com (good, as supported)
Yes.
2. A file created locally (after su - myu...@example.com) ends up owned by
nobody
(unsupported scenario; caused by the code path mentioned by Jordan; but
creating a Unix account myuser makes the file owned by myuser)
Yes, this is what we've been discussing.
3. A file created remotely via NFSv4 (by a Kerberized NFS client authenticated
as
myu...@example.com) ends up owned by nobody instead of
myu...@example.com (but creating a Unix account myuser makes the file
owned by myuser)
What explains #3? Is this a supported scenario? I assume not, given that
the same workaround (creating a Unix account myuser) is required to
prevent files owned by nobody.
Is example.com your AD domain?
If so, I believe this is intended to work, but I can't say that it's been
exercised as much as one might like.
Also: if your NFSv4 domain has the same name as your AD domain, there's a
conflict of sorts. Names in that domain will be interpreted as UNIX names
(rather than as AD names) and so if they don't exist in the UNIX namespace
it's an error and they turn into "nobody".
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
