When I went in and edited the /etc/group file so parents were GID 101
and kids were GID 102, OSOL happlily reported the ACL as:
It's better to use the group (add, mod etc) and smbadm commands to ensure
consistency. If you edit configuraiton files directly, don't be surprised if
things
don't align.
So as I mention at the top, I gave up and just did "chmod -R ..."
Editing the files seems like the workaround. Using chmod seems like an
approrpaite way to reset your ACLs and establish a baseline given the
background here.
It was still a real pain to do it that way because ZFS won't allow you to
remove the last non-inherited ACL from a file or folder. Meanwhile,
ZFS will happily let Windows do just that if you are setting the permissions
from there... frustrating.
I don't follow these comments. ZFS won't let you set a null or empty ACL
(regardless of whether that's attempted locally or from Windows) but it will
let
you use A= to replace any ACL. You can do most things from Windows or
using chmod, although it can be convenient to use the Windows GUI.
Alan
----- Original Message -----
From: "Owen Davies" <[email protected]>
To: <[email protected]>
Sent: Saturday, September 12, 2009 8:28 PM
Subject: Re: [cifs-discuss] [zfs-discuss] ZFS Export, Import = Windows sees
wrong g
Note: I don't need the answer to this anymore as I worked around it (see
below).
Nevertheless, I'm still curious if there are Best Practices for importing a
pool with ACLs that reference CIFS users and groups after rebuilding a
machine. Is there any reliable way to hook the newly (re)created CIFS users
and groups back up to the correct SIDs stored in the ZFS ACLs?
How are the parent and kids defined in the /etc/passwd file?
These two are parents (names changed) :
Dad:x:101:10:Dad:/export/home/Dad:/bin/bash
Mom:x:102:1::/home/Mom:/bin/sh
and these are the kids:
Kid_a:x:103:1::/home/Kid_a:/bin/sh
Kid_b:x:104:1::/home/Kid_b:/bin/sh
Kid_c:x:105:1::/home/Kid_c:/bin/sh
You didn't ask, but here is what the groups look like in the /etc/group
file:
kids::101:
parents::102:
family::103:
What do the ACLs look like?
The ACL for my music folder, for example, is:
dr-xr-xr-x+246 root root 246 Aug 26 00:16 music
everyone@:r-x---a-R-c--s:fd-----:allow
group:kids:rwxpdDaARWcCos:fd-----:allow
When I went in and edited the /etc/group file so parents were GID 101 and
kids were GID 102, OSOL happlily reported the ACL as:
dr-xr-xr-x+246 root root 246 Aug 26 00:16 music
everyone@:r-x---a-R-c--s:fd-----:allow
group:parents:rwxpdDaARWcCos:fd-----:allow
but Windows continued to report that the kids had permissions. Having read a
bit more I know ZFS stores the full ACL with SID. This must then get mapped,
somehow, to UNIX UIDs and GIDs and mapped a second time to CIFS users or
groups. The experiment above shows that the two mappings seem to be
independant; the name Windows determines for a SID does not rely at all on
UNIX GIDs or SIDs.
Issues with the CIFS server are best served by asking on
cifs-discuss at opensolaris dot org
So I guess what this leads me to is that you are right, I'm not really
asking about ZFS or the actual ACLs and SIDs but rather how and where the
mapping from ZFS SID to CIFS user/group name happens. This is obviously a
topic for CIFS-Discuss.
So as I mention at the top, I gave up and just did "chmod -R ..." to set the
permissions back how I wanted them as I didn't really have any different
permissions set lower down the heirarchy. It was still a real pain to do it
that way because ZFS won't allow you to remove the last non-inherited ACL
from a file or folder. Meanwhile, ZFS will happily let Windows do just that
if you are setting the permissions from there... frustrating.
Thanks,
Owen Davies
--
This message posted from opensolaris.org
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
