[Samba] several offices: home dirs, local resources, ...

[Kees van Vloten]

On 22-11-2022 18:13, Michael Tokarev wrote:
> 22.11.2022 19:46, Kees van Vloten via samba wrote:
>
>>> 2. why samba4 offers SYSVOL *file* share when using it as a file 
>>> server is not
>>>  a good idea, why not use reglar non-dc samba server for it?
>>
>> SYSVOL is a special share which must be on the DC (and so is the 
>> netlogon share). You should take care of replications of the files 
>> yourself, the DC replication does not handle. The wiki describes 
>> multiple solutions to get it done (I am using the osync method with 
>> works well for my situation). Permissions on the SYSVOL share are 
>> very critical, if not exactly right Windows will not be able to pick 
>> up GPOs properly for example.
>>
>> samba-tool can reset the permissions in case they got messed up.
>
> Sometimes I don't understand which language we're using.
>
> I do know full well that the sysvol replication is not implemented and 
> should
> be done externally (got that yesterday when, after adding a new DC, users
> complained their usual drive letters wern't mapped because I forgot to 
> replicate
> GPO in sysvol).  I know what wiki describes, I corrected quite some 
> data there
> already and have other corrections too.  I know about permissions of 
> SYSVOL,
> and I know more: permissions of SYSVOL (actually ACLs) should match 
> *local*
> idmap.db file, which should be replicated too but it is not mentioned in
> the wiki.  I know well about sysvolreset and sysvolcheck too, -- found it
> the hard way, used them many times.
>
> But how it all is related to my question?
>
> I asked why, if a source4 fileserver is not operational, why it is 
> used for
> sysvol share instead of some other fileserver?  And if, despite all 
> the claims
> by you and Rowland in this thread (you both claimed using a fileserver in
> source4 is not a good idea), it is actually is good enough to serve 
> SYSVOL
> share, why it is ALSO not good enough to serve single read-only 
> MSDFS-root
> share with 2 files within?

Sysvol is a special case. Windows expects it on the DC, there are no 
other options and hence source4 contains enough functionality to serve it.

As for MSDFS-root, I have never used it and can't answer any questions.

>
> How all the sysvol permission and replication stuff answers to this 
> question?
>
> And now I really wonder: am I asking something fantastically stupid, 
> illogical,
> random, or maybe I'm phrasing my question in somehow difficult to 
> understand
> form, - why my question can't be understood, how *else* can I rephrase 
> it?
>
> And now, for fun side, once you mention sysvolcheck and sysvolreset 
> stuff,
> here's another twist:
>
> svdcp:/# samba-tool ntacl sysvolcheck
> svdcp:/# samba-tool ntacl sysvolreset
> svdcp:/# samba-tool ntacl sysvolcheck
> ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception 
> - ProvisioningError: DB ACL on GPO directory 
> /var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9} 
> O:LAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) 
> does not match expected value 
> O:DAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) 
> from GPO object
>   File "/usr/lib/python3/dist-packages/samba/netcmd/__init__.py", line 
> 186, in _run
>     return self.run(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/samba/netcmd/ntacl.py", line 
> 443, in run
>     provision.checksysvolacl(samdb, netlogon, sysvol,
>   File "/usr/lib/python3/dist-packages/samba/provision/__init__.py", 
> line 1876, in checksysvolacl
>     check_gpos_acl(sysvol, dnsdomain, domainsid, domaindn, samdb, lp,
>   File "/usr/lib/python3/dist-packages/samba/provision/__init__.py", 
> line 1826, in check_gpos_acl
>     check_dir_acl(policy_path, dsacl2fsacl(acl, domainsid), lp,
>   File "/usr/lib/python3/dist-packages/samba/provision/__init__.py", 
> line 1769, in check_dir_acl
>     raise ProvisioningError('%s ACL on GPO directory %s %s does not 
> match expected value %s from GPO object' % 
> (acl_type(direct_db_access), path, fsacl_sddl, acl))
>
> (This is a "second" DC).  So the permissions WERE okay after an rsync 
> from
> "primary" DC.  And sysvolcheck reported no errors. So one might thing
> sysvolreset will be a no-op - nope. After sysvolreset, sysvolcheck 
> reports
> errors, and no other sysvolreset fixes them. Only after another resync 
> from
> primary (which transfers ACLs too) sysvolcheck is quiet again. This is
> one more thing for me to debug, maybe it's idmap.tdb again (mentioned 
> above
> already), maybe something else, - it's not important by now.  Just 
> another
> fun data point in the new context you mentioned..
Permissions are stored in xattrs, did you add the right options to rsync 
to replicate those?
>
> Thanks,
>
> /mjt