[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
HI,
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 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
>
More information about the samba
mailing list