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 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 [email protected] to nobody. 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. 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 [email protected]) ends up owned by [email protected] (good, as supported) 2. A file created locally (after su - [email protected]) 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) 3. A file created remotely via NFSv4 (by a Kerberized NFS client authenticated as [email protected]) ends up owned by nobody instead of [email protected] (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. -- This message posted from opensolaris.org _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
