samba - Dec 2025 - SYSVOL replication (rsync/Unison): is samba-tool ntacl sysvolreset mandatory after each sync?

Hi all,

We run Samba AD DCs in a multi-DC environment and replicate SYSVOL (GPOs,
scripts, and related files) using a SysVol replication workaround. We?ve
used rsync, and we are also evaluating the bidirectional rsync/Unison
approach (I understand Unison still relies on the rsync delta algorithm for
efficient transfers).

While reading past discussions and the SambaWiki guidance, I noticed a
recurring pattern: after a SYSVOL sync, samba-tool ntacl sysvolcheck may
start reporting ACL mismatches; samba-tool ntacl sysvolreset fixes them,
but in some cases the next replication (or the next RSAT/GPO edit) makes
the errors come back. Several threads point to root causes like
inconsistent ID mapping between DCs (idmap.ldb / xidNumber) and/or changes
to SYSVOL/NETLOGON permissions from Windows, and the wiki seems to frame
sysvolreset mainly as an initial/repair step (e.g., after joining a new DC)
rather than something that must run after every replication.

With each SYSVOL replication (GPOs, files, etc.), is it actually
necessary/mandatory to run samba-tool ntacl sysvolreset to ?correct?
permissions?
-- 
Elias Pereira

You are probably not syncing ideal.ldb

http://samba.bigbird.es/doku.php?id=samba:sync-idmap.ldb

Let me know who you get on
On Dec 16, 2025 at 12:26 +0000, Elias Pereira via samba <samba at
lists.samba.org>, wrote:
> Hi all,
>
> We run Samba AD DCs in a multi-DC environment and replicate SYSVOL (GPOs,
> scripts, and related files) using a SysVol replication workaround. We?ve
> used rsync, and we are also evaluating the bidirectional rsync/Unison
> approach (I understand Unison still relies on the rsync delta algorithm for
> efficient transfers).
>
> While reading past discussions and the SambaWiki guidance, I noticed a
> recurring pattern: after a SYSVOL sync, samba-tool ntacl sysvolcheck may
> start reporting ACL mismatches; samba-tool ntacl sysvolreset fixes them,
> but in some cases the next replication (or the next RSAT/GPO edit) makes
> the errors come back. Several threads point to root causes like
> inconsistent ID mapping between DCs (idmap.ldb / xidNumber) and/or changes
> to SYSVOL/NETLOGON permissions from Windows, and the wiki seems to frame
> sysvolreset mainly as an initial/repair step (e.g., after joining a new DC)
> rather than something that must run after every replication.
>
> With each SYSVOL replication (GPOs, files, etc.), is it actually
> necessary/mandatory to run samba-tool ntacl sysvolreset to ?correct?
> permissions?
> --
> Elias Pereira
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba

On Tue, Dec 16, 2025 at 7:26?AM Elias Pereira via samba
<samba at lists.samba.org> wrote:
>
> With each SYSVOL replication (GPOs, files, etc.), is it actually
> necessary/mandatory to run samba-tool ntacl sysvolreset to ?correct?
> permissions?
Not sure about that case but I've found it necessary after editing
GPO's using RSAT.
No clue why but it's been that way for a long time. A bit surprising
that it's never been fixed, kinda like time sync and client update of
PTR records.