[Samba] FreeBSD/ZFS/S3FS usage and development questions
jmaloney at pcbsd.org
Sun Mar 2 12:12:03 MST 2014
After cranking up the debuglevel to 10 and trying to create GPO's by hand I
see that gpo.py 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.
I see another common warning among all of these tools. That's in
__init__.py 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
I was thinking if I could just figure out how to ignore whatever this check
is that's breaking things I could write some code to detect the presence of
a .zfs directory on the root of whatever storage tank sysvol is stored in.
Then proceed running a different set of commands if that is detected. I'm
somewhat familiar with getfacl and setfacl commands as I have had to use
them to manage ACL's frequently. Would these by an adequate replacement
for checking and setting ACL's for sysvol on ZFS volumes? I'm assuming
something like this would have to be added to gpo.py as well for policy
creation to work with s3fs + ZFS?
On Sun, Mar 2, 2014 at 2:42 AM, Joe Maloney <jmaloney at pcbsd.org> wrote:
> I've discovered that ntacl sysvolreset not working is not what is stopping
> group policy from functioning on this setup I mentioned above. When
> creating a group policy I was getting the message "a device to attached to
> the system was not function in windows". Then I noticed the following in
> log.smbd. Does this message below mean anything to anyone?
> [2014/03/02 02:28:51.186668, 0] ../lib/util/talloc_stack.c:104(talloc_pop)
> Freed frame ../source3/smbd/process.c:3623, expected
> Joe Maloney
> On Thu, Feb 27, 2014 at 5:02 PM, Jeremy Allison <jra at samba.org> wrote:
>> On Tue, Feb 25, 2014 at 11:30:15PM -0600, Joe Maloney wrote:
>> > I've noticed that the samba-tool ntacl sysvolreset --use-s3fs command
>> > not work on a ZFS filesystem on FreeBSD. It does work if sysvol is
>> > to a volume that is able to be mounted with the acls flag.
>> > I will reference a ticket I started with FreeNAS here:
>> > https://bugs.freenas.org/issues/4351
>> > As of version 220.127.116.11 s3fs is now the default using the workaround known
>> > for FreeBSD.
>> > It seems to work well for the most part and things like smbstatus work.
>> > However I've noticed the inability to create any group policy objects.
>> > I started thinking about the sysvolreset command.
>> > Am I correct in thinking that as suggested early without running
>> > ntacl sysvolreset the conversion from ntvfs to s3fs after an initial
>> > provision with ntvfs would not be fully complete?
>> > I also suggested this as maybe a good starting point for fixing the
>> > reset command with ZFS. Is this the correct file?
>> Yes, that looks right.
>> > Is it possible to simply disable the hard requirements for POSIX acls or
>> > bypass the check in some way? Or are POSIX acls somehow essential to
>> > setting the permissions to begin with using the python scripts?
>> POSIX ACLs aren't required for this, it's just that
>> they are the tested environment most of the Team
>> is working within. ZFS ACLs should be an acceptable
>> (and easier) replacement.
More information about the samba