All files on ZFS *always* have ACL. What you see as traditional Unix
permission is just a mapping of the underlying ACL to make life a
bit easier for Unix users.
The thing that becomes confusing when Windows comes to picture is that
ZFS tries to be POSIX compliant when it comes to ACL inheritance and
the fact that default ACLs on ZFS don't have any inheritance flags
set which causes confusion when objects are created from Windows because
Windows is not POSIX and if there's no inheritable ACE in an ACL the
default ACL will be set, which is what Michael is seeing and he thinks
is bogus while it is NOT.
I don't have any comment about your warning suggestion at this point :)
Afshin
[email protected] wrote:
Now that's not a bad idea. The core concept that needs understanding is
that the CIFS service has to use ACL style permissions, there's just no
other way to accurately map windows permissions, but these don't
necessarily interact well with the old 755 style permissions. Once you
understand that, it all works pretty well.
However, while I like the idea, I'm not sure how it could be
implemented. Checking the entire filesystem might be a bit tricky, but I
wonder if the permissions on the root folder of the share could be
checked as you enable CIFS, and generate a warning if no ACL's have been
set? At least with permissions set on the root, windows users will be
able to set ownership, and change permissions from that point down if
needed.
Could the CIFS guys who read this comment on whether it might be
feasible to have the initial 'svcadm enable smb/server' command, or the
'zfs set sharesmb=on' command pop up an informational message if
permissions haven't been set on the root of a share?
Ross
On Apr 9, 2009 10:46pm, Michael Herf <[email protected]> wrote:
> I hadn't realized that I *must* set an ACL on a folder if I want
Windows to behave properly.
>
>
>
> If I set permissions for a folder as "chmod 755" with no ACL, and add
files via CIFS, then new files created from Windows come out as "000+"
with an ACL giving the owner full control, and specifying a numbered
group (2147483648) that doesn't seem to make sense to either Windows or
UNIX. (The group behavior looks buggy to me - I'm using snv101b, in case
there are any changes in later builds.)
>
>
>
> On the other hand, if I create an ACL for the folder before adding
the file, then things work as I expect. I guess I simply expect a 755
folder to allow files I write there to be read by others, or I at least
want a setting in CIFS to determine the default ACL. In this case, even
if the group mapping is bad, I think "everyone" should have read access
to this file. In effect, I expect a better mapping of UNIX permissions
to Windows, and I think CIFS should work in a mixed environment. It
seems like the "no ACL" mode (with a mixture of no-ACL and ACL
permissions) is very hard to understand.
>
>
>
> Once all my directories have an ACL, some of my problems with
read-only files seem to be less of an issue - the read-only bugs I'm
seeing are with pure "no ACL" standard UNIX permissions, and how they're
inherited. But I will again say that upgrading from an existing system
(perhaps via tar) would appear to confuse a bunch of people.
>
>
>
> Is there a simple fix for this, like maybe enabling directory-level
ACLs (or throwing a warning) when sharesmb is enabled?
>
> --
>
> 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
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
