FreeBSD/ZFS/S3FS usage and development questions

Joe Maloney jmaloney at
Sun Mar 2 15:40:34 MST 2014

Awesome.  Thanks for the info and the patch.  I will use this information
to see what I can do to put together an modified port for testing with an
experimental S3FS + ZFS option to bypass the ACL checks.

I do see now where the FreeBSD port already has the options to build
modules like vfs_zfsacl as an experimental module and this is not installed
by default.  Perhaps that was something I was overlooking also as I was
just adding vfs objects = zfsacl to my shares without having the module
compiled.  Now this is starting to clear it up for me.  Thanks again.

Joe Maloney

On Sun, Mar 2, 2014 at 2:27 PM, Andrew Bartlett <abartlet at> wrote:

> On Sun, 2014-03-02 at 13:12 -0600, Joe Maloney wrote:
> > After cranking up the debuglevel to 10 and trying to create GPO's by
> hand I
> > see that is also failing at setting the acl.  It creates a
> directory
> > under sysvol but never creates the objects.  It just seems to give up
> > creating additional folders and files for the GPO maybe because it can't
> > set the ACL's?  It also appears sysvolrest is doing more than I thought
> and
> > sysvolcheck appears to be working more than I thought as well.
> >
> > It would seem the following are actually broken with ZFS.
> >
> > domain provision
> > samba-tool gpo
> > samba-tool ntacl
> >
> > I see another common warning among all of these tools.  That's in
> > line 175. is where things seem to start to break down.  At
> > least after commenting some of those things out I notice some of the
> python
> > warnings go away.  I'm wondering if that's actually where the posix
> > hardcoding begins?  Is there maybe something specific I can grep each
> > source file for and remove to clear the posix check to see where things
> > stand?
> I do apologise, I have allowed you to become mislead as to the extend of
> the 'hard coding' of support only for POSIX ACLs.  The attached patch
> removes the only deliberate hard coding from git master (I had assumed
> this much would be obvious).
> Any issues beyond that are either:
>  - due to a failure to load the vfsacl module.  At the moment the
> default vfs ACL list is set at source3/param/loadparm.c:3358.  This can
> be overridden by setting it either on each share or by changing this
> line.
>  - due to other bugs
> The second is why this has been 'hard coded' into provision, that is
> that no testing in the AD DC context has been done of a system using
> NFSv4 ACLs, and so we simply do not know what the other issues may be.
> We do have tests for NFSv4 ACLs in a normal file server, using the
> nfs4acl_xattr vfs module, and a ZFS for the AD DC patch would have to
> also include tests that run on linux using this emulation, to ensure its
> continued operation is validated in 'make test'.
> I hope this clarifies things,
> Andrew Bartlett
> --
> Andrew Bartlett
> Authentication Developer, Samba Team
> Samba Developer, Catalyst IT

More information about the samba-technical mailing list