[Samba] several offices: home dirs, local resources, ...
mjt at tls.msk.ru
Tue Nov 22 17:13:28 UTC 2022
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?
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
does not match expected value
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,
(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..
More information about the samba