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 myu...@example.com 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 myu...@example.com) ends up owned by myu...@example.com (good, as supported) 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) 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. -- This message posted from opensolaris.org _______________________________________________ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
