[Samba] sysvol files - 'The data area passed to a system call is too small'

[Rowland Penny]

On Sun, 29 Apr 2018 00:42:47 +0100
Jonathan Hunter <jmhunter1 at gmail.com> wrote:

> Hi Rowland
> 
> On 28 April 2018 at 09:17, Rowland Penny via samba
> <samba at lists.samba.org> wrote:
> 
> > On Fri, 27 Apr 2018 22:40:41 +0100
> > Jonathan Hunter via samba <samba at lists.samba.org> wrote:
> >
> > > OK - some more detail I have found in the meantime.
> > >
> > > I have compiled & ran listxattr, and I can now see a difference
> > > between a working and a broken file:
> 
> [...]
> 
> Are you sure your sync method is working ?
> > I ask this because the sysvol ACLs are stored in 'security.NTACL'
> > and you don't have this on the non working DC
> >
> 
> Thank you for the pointer, Rowland! Sometimes, what one person thinks
> is 'obvious' and 'clearly it can't be the fault of X'... turns out to
> not quite be so obvious after all, and it really might be X at
> fault :)
> 
> I don't want to be too excited, because I have only just reconfigured
> things and tried it once.. but with a sample size of one, it does
> seem to work now!
> 
> I have given up on my multi-master replication using lsyncd.. and
> instead I am running lsyncd only on DC1 (lsyncd uses inotify hooks to
> detect and then push out any changes to sysvol via rsync to the other
> DCs). This means that any sysvol / GPO changes need to be directed
> only against DC1 - which is not ideal - but I would much rather have
> GPOs working than not :)
> 
> For what it's worth, my lsyncd.conf looks something like this below;
> there is a pretty standard rsyncd.conf on the other end.
> 
> Rowland - do you think it's worth me writing up the lsyncd part for
> the wiki? I'd be happy to put some text & guidance around it, it
> works well for me as an inotify-driven rsync trigger (with of course
> the caveat that I now don't think it works in a multi-master
> configuration)
> 
> 
> -- automation from
> https://gist.github.com/oscarssama/8bc223c8100890f71a07a5a6dc16a7f6
> settings {
>         statusFile = "/run/lsyncd-status.log",
>         statusInterval = 10
> }
> 
> targetList = {
>         "1.1.1.1",
>         "1.1.1.2",
>         "1.1.1.3",
>         "1.1.1.4"
> }
> 
> for _, server in ipairs(targetList) do
>         sync {
>                 default.rsync,
>                 source    = "/usr/local/samba/var/locks/sysvol/",
>                 target    = server .. "::_sysvol_/",
>                 rsync     = {
>                         acls = true,
>                         xattrs = true,
>                         perms = true,
>                         owner = true,
>                         compress = true,
>                         _extra = { "--numeric-ids" }
>                 }
>         }
> end
> 

Well, this is Linux and as is well known, there are usually multiple
ways of doing the same thing, so one more way of syncing sysvol isn't
going to harm anything ;-)

I feel I should point out that there is work ongoing to make all the
different ways of syncing sysvol obsolete, DSFR is coming to Samba AD.

Rowland