samba - Apr 2018 - sysvol files - 'The data area passed to a system call is too small'

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:
> 
> me at dc2:~/download $
> sudo ./listxattr /usr/local/samba/var/locks/sysvol/
> mydomain.org/brokenfile.txt user.DOSATTRIB: 0x20
> system.posix_acl_access:
> 
> me at dc2:~/download $
> sudo ./listxattr /usr/local/samba/var/locks/sysvol/
> mydomain.org/workingfile.txt user.DOSATTRIB: 0x20
> system.posix_acl_access:
> security.NTACL:
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
> 
> This then led me to check what things look like from Windows, and to
> look at the NTACL from there, seeing as 'listxattr' wasn't
showing me
> much:
> 
> C:\Users\me>cacls
> \\dc2\sysvol\mydomain.org\brokenfile.txt /S
> \\dc2\sysvol\mydomain.org\brokenfile.txt
>
"D:(A;;FA;;;S-1-5-21-xxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-1234)(A;;0x1201bf;;;S-1-22-2-0)(A;;FA;;;SY)"
> [ The first SID is my admin user I am logged in as. Windows doesn't
> resolve S-1-22-2-0 when using Explorer, and instead shows 'Account
> Unknown(S-1-22-2-0)' ]
Yes, but surely the result you are getting here is the ACL for the file
'brokenfile.txt' not sysvol, try:

samba-tool ntacl get /usr/local/samba/var/locks/sysvol --as-sddl

Rowland

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

-- 
"If we knew what it was we were doing, it would not be called research,
would it?"
      - Albert Einstein

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
>

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

Hai, 
>From the github example.
I did see:     _extra = { "--numeric-ids" } 

Have you check if the id's are the same on all servers, not only the default
ones, but of the users/groups you need.

In multi DC setup,
- Run on all DC's servers net cache flush. 
-  Stop both dc's and copy : /var/lib/samba/private/idmap.ldb ( Debian
location)
for the DC with FSMO to the other DC. 
Not 100% sure its still needed but i does not harm if you do it. 

And now follow these steps. 
https://www.spinics.net/lists/samba/msg147788.html 

IF ... You need extra groups, for other things etc in sysvol. ( not advice,
create a new share for that )
Make sure that this group has a GID assigned, that makes sure the SID wil be the
same on both DC's.
Policies ant extra groups, make sure your COMPUTER/USERS are allowed. 

And test this from within windows and NOT linux, just because ..
The first time you set your rights, you MUST do this from withing windows. 
At least the works for me the best because what you see might not be what you
get,
in case of rights/acls, if you set it from within linux

Last, i you just applied GPO setttings, reboot the computer 2-3x, some policies
might need that ( often computer settings )
Why 2-3x reboot. 
Reboot 1, its sets the settings, 
Reboot 2, it applies settings, but some need a reboot first. 
Reboot 3, its now all applied. 

I hope this helps you guys a bit more. 

Greetz, 

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Jonathan Hunter via samba
> Verzonden: zondag 29 april 2018 1:43
> Aan: Rowland Penny
> CC: samba
> Onderwerp: Re: [Samba] sysvol files - 'The data area passed 
> to a system call is too small'
> 
> 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
> 
> -- 
> "If we knew what it was we were doing, it would not be called 
> research,
> would it?"
>       - Albert Einstein
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
> 
>