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

Anantha Raghava raghav at exzatechconsulting.com
Sun Apr 29 04:33:22 UTC 2018


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 

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 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 = {
>          "",
>          "",
>          "",
>          ""
> }
> 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

More information about the samba mailing list