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 "chown myu...@example.com /tmp/file" as root (which makes sense because a filesystem only sees 32-bit UIDs; it doesn't care if they are ephemeral). Even more puzzling: after creating a local Unix account 'myuser' matching the AD account name (so that idmap bidirectionally maps them), my commands end up with the file owned by 'nobody' on tmpfs but 'myuser' on zfs. Why does zfs behave differently when this local account exists? Actually, as a workaround, creating local accounts is fine for my needs. But I would definitely like an explanation of what is going on with these ephemeral IDs... I suspect Solaris has a code path that, sometimes but not always, intentionally maps them to nobody, when the right thing to do would be to not interfere with them (ie. pass them as is to the filesystem). -- This message posted from opensolaris.org _______________________________________________ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
