No problem, now its behaving as desired! It all came down the chmodding properly, and knowing that I can use the uid field coming from 'idmap dump' output, that solved my outcome - having 3 users with the expected control over the share. and I didn't have to do any local -> AD user mapping, which keeps my implementation simple.
One thing I do notice, is if I upload files that are executable, they seem to upload fine, but then a few seconds later I get a winpopup saying "Error: the operation completed successfully" and the file I just transmitted over the wire just dissapears. Gotta love that message, but has anyone noticed similar behavior on the shared zfs filesystem? -----Original Message----- From: Nicolas Williams [mailto:[EMAIL PROTECTED] Sent: Fri 3/21/2008 5:28 PM To: Andy Lubel Cc: Natalie Li; [email protected] Subject: Re: [storage-discuss] CIFS+AD+IDMAP question On Fri, Mar 21, 2008 at 05:17:11PM -0400, Andy Lubel wrote: > #chmod 777 /zpool/winshare > #chmod A=everyone@:rwxpdDaARWcCos:fd:deny /zpool/winshare > #chmod A+user:123456789:rwxpdDaARWcCos:fd:allow /zpool/winshare > #chmod A+user:123456790:rwxpdDaARWcCos:fd:allow /zpool/winshare > #chmod A+user:123456791:rwxpdDaARWcCos:fd:allow /zpool/winshare > > Any user that doesnt have that id map showing in 'idmap dump -n' > cannot even browse the share and the users that are explicitly added > afterwards are having complete control of it. I'm not sure what you mean here. When the system first starts "idmap dump"'s output should be empty. As users browse the share, mount it, and access it, idmapd should build up a cache of mappings and "idmap dump"'s output should grow. If that's not happening automatically then it sounds like there's a problem. Nico -- _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
