FreeBSD/ZFS/S3FS usage and development questions

Joe Maloney jmaloney at
Sun Mar 16 09:54:46 MDT 2014

I've already caught the FreeNAS dev's up to speed with this but I just
wanted to throw it out here for reference as well.

The samba tools being broken had nothing to do with ZFS.  I believe it may
be the fact that /var/db/samba4 is a symbolic link to
/mnt/storage/.system/samba4 as moving that symbolic link to a UFS volume
with ACL's makes no difference.  In combination they also use a special
smb4.conf that get's wiped out and regenerated with every start/restart of

Removing that smb4.conf and provisioning my own along with removing the
symbolic link and creating a real /var/db/samba4 seems to fix that issue.
 That's something I will have to continue researching in order to see if I
can make samba-tool sysvolreset work with the FreeNAS overlay.  For now
it's not a FreeBSD problem or a samba issue with ZFS the way I see it.

Secondly the issues with GPO's after FreeNAS that began with the
switch to S3FS were this parameter that gets created on every share by the
dynamic smb4.conf in the FreeNAS overlay:

nfs4:chown = yes

This had to be added to auxiliary parameters for the sysvol share which has
to be manually created in FreeNAS:

nfs4:chown = no

Joe Maloney

On Sun, Mar 2, 2014 at 4:40 PM, Joe Maloney <jmaloney at> wrote:

> 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