Web lists-archives.com

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


We have done something similar using inotify. On the DC1. we watch the "/usr/local/samba/var/locks/sysvol" folder and if there is any change, (add, modify or delete), we run "samba-tool ntacl sysvolreset" and we push those changes to other DCs using rsync. We have created a shell script that is put in rc.local so that this starts even if the server reboots.

We chose to run "samba-tool ntacl sysvolreset" as we find that whenever there is a change in GPO, the acls change resulting GPO errors. We never had this problem in 4.6.x version but starting 4.7, (even in 4.8) this problem is persistent. Why actually this happens, is what we are wondering. We are still unable to figure it out. Also, we find that in a large network, many a times, we find that GPO (particularly Computer Policies) do not get applied on many Members. Each time, this happens, we find that sysvol acls are changed and there is an error. Surprising part is, without changing anything on the Domain Controllers or resetting acls on sysvols, for the same user, on a different workstation, the Policies gets applied.

Any pointers to get this working properly is welcome.


Thanks & Regards,

Anantha Raghava

Do not print this e-mail unless required. Save Paper & trees.

On 29/04/18 5:12 AM, Jonathan Hunter via samba wrote:
Hi Rowland

On 28 April 2018 at 09:17, Rowland Penny via samba <samba@xxxxxxxxxxxxxxx>

On Fri, 27 Apr 2018 22:40:41 +0100
Jonathan Hunter via samba <samba@xxxxxxxxxxxxxxx> 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
settings {
         statusFile = "/run/lsyncd-status.log",
         statusInterval = 10

targetList = {

for _, server in ipairs(targetList) do
         sync {
                 source    = "/usr/local/samba/var/locks/sysvol/",
                 target    = server .. "::_sysvol_/",
                 rsync     = {
                         acls = true,
                         xattrs = true,
                         perms = true,
                         owner = true,
                         compress = true,
                         _extra = { "--numeric-ids" }

To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba