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

Fri Apr 27 21:40:41 UTC 2018

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:

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)' ]

C:\Users\me>cacls \\dc2\sysvol\mydomain.org\workingfile.txt /S
\\dc2\sysvol\mydomain.org\workingfile.txt
"D:AI(A;ID;FA;;;BA)(A;ID;0x1200a9;;;SO)(A;ID;FA;;;SY)(A;ID;0x1200a9;;;AU)"

So.. I don't quite understand *why* (or when) these permissions become
different - I don't consciously touch them at all - but at least I can now
see that there *is* some kind of difference.

Finally, I then went back to the DC and used samba-tool to view the NTACL:

root at dc1:/usr/local/samba/var/locks/sysvol/mydomain.org# samba-tool ntacl
get --as-sddl brokenfile.txt
O:S-1-5-21-xxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-1234G:S-1-22-2-0D:(A;;0x001f019f;;;S-1-5-21-
xxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-1234
)(A;;;;;S-1-22-2-0)(A;;0x001f019f;;;SY)(A;;0x00120089;;;SO)(A;;0x00120089;;;AU)(A;;0x001f019f;;;BA)(A;;0x001f019f;;;SY)(A;;0x00120089;;;SO)(A;;0x00120089;;;AU)(A;;0x001f019f;;;BA)(A;;0x001f019f;;;S-1-22-1-0)(A;;;;;WD)

root at dc1:/usr/local/samba/var/locks/sysvol/mydomain.org# samba-tool ntacl
get --as-sddl workingfile.txt
O:BAG:DUD:(A;;0x001f01ff;;;BA)(A;;;;;DU)(A;;0x001f019f;;;SY)(A;;0x00120089;;;SO)(A;;0x00120089;;;AU)(A;;0x001f019f;;;BA)(A;;0x001f019f;;;SY)(A;;0x00120089;;;SO)(A;;0x00120089;;;AU)(A;;0x001f019f;;;BA)(A;;0x001f019f;;;S-1-22-1-0)(A;;;;;WD)

I don't know how to feed the output of "samba-tool ntacl get" into
"samba-tool ntacl set" (or indeed if that is even possible)

In the meantime I have tried re-flowing permissions back down from the top
of sysvol, via the Windows GUI.. that hasn't been 100% successful, either :(

I am really confused as to why the NTACLs sometimes seem to be wrong, on my
system - I don't know what would cause that.

Another oddity I have just noticed (might not be related): I started up a
cmd.exe on a Windows domain member as 'Local System', so that I could check
what the machine account can see. I can get a directory listing of
"\\dc1\sysvol", which shows me the "mydomain.org" subdirectory.. but if I
try to run 'dir \\dc1\sysvol\mydomain.org' then I just get File Not Found -
despite the domain member's machine account being a member of 'Domain
Users', and 'Domain Users' having read & execute access to the directory..

There's something going on but I'm not quite sure what :(

Cheers

Jonathan

On 27 April 2018 at 21:23, Jonathan Hunter <jmhunter1 at gmail.com> wrote:

> Hi,
>
> I have been having problems with GPOs, sysvol, etc. for some time now, and
> have found a workaround but I wondered if any of the samba devs were
> interested in investigating this.
>
> Basically, the problems manifest themselves as access errors, along the
> lines of unable to read files, error messages such as 'The data area passed
> to a system call is too small' and so on - which means that GPOs don't
> work; files that are meant to be copied from sysvol can't be accessed; etc.
>
> When I get these issues, I seem to be able to work around them by
> following Louis's tips (Thanks, Louis!) as per
> https://www.spinics.net/lists/samba/msg147788.html. In summary, I do the
> following:
> - zip up the contents of sysvol (from a Linux machine, as I can't read all
> files from Windows)
> - remove the contents of sysvol
> - unzip the file created in step 1 back above into sysvol, from a Windows
> machine
> - re-apply permissions via the Group Policy snap-in on Windows (it offers
> to re-set permissions when you click on each GPO)
> - not ever running 'samba-tool ntacl sysvolreset' :)
>
> I did raise a bug a while back (#12363) for what is probably related to
> this, but I don't think I have quite the level of knowledge of samba
> internals to investigate much further. The above bug was raised in relation
> to 'ntacl sysvolreset' but I suspect it may be the same underlying issue
> here.
>
> I don't think my setup is particularly unusual - I have a few 4.7.7 DCs
> running on Debian / Raspbian with ext4 filesystem. The only non-standard
> part is probably my rsync setup to synchronise sysvol across machines (I
> use lsyncd on each DC, to allow multi-master replication) - but I can't see
> that causing these issues.
>
> The strange thing is, if I compare a 'working' file or directory, to a
> 'broken' file or directory - the permissions seem to be exactly the
> same. Whether I look at the POSIX permissions via 'ls -l' or if I look at
> 'getfacl dir1' / 'getfacl dir2', there is no difference whatsoever.
> I can't view the permissions via Windows, Explorer just gives me the error
> 'The requested security information is either unavailable or can't be
> displayed' - which would make sense given the error message in the subject
> line.
>
> Are ACLs stored anywhere else, that I could view? I have found a sample C
> program here, which I might compile and try... :
> http://man7.org/linux/man-pages/man2/listxattr.2.html
>
> FWIW, the sysvol entry in my smb.conf looks like this:
> [sysvol]
>         path = /usr/local/samba/var/locks/sysvol
>         read only = No
>         acl_xattr:ignore system acls = yes
>
> Any tips on anything else I could investigate?
>
> I can work around this reasonably reliably via the steps above; but of
> course
> a) it's a PITA to have to keep doing that, and
> b) I have no idea what causes things to break in the first place!
>
> I'll try and leave one or two GPOs in their broken state for now in order
> to use them for investigation, but I need to get the rest working, so will
> delete & recreate those directories in the meantime.
>
> Cheers
>
> Jonathan
>
> --
> "If we knew what it was we were doing, it would not be called research,
> would it?"
>       - Albert Einstein
>
>

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