samba - Sep 2025 - SID→UID mapping issue between Samba DC and member server after decommissioning an old DC

This situation highlights one of the main reasons why using a domain controller
as a file server is generally discouraged. A domain controller maintains its own
ID mapping, which cannot be reliably aligned with the ID mappings used on member
servers.


The simplest and most reliable way to handle ID mapping on a member server is to
use the RID ID mapping backend, which ensures a consistent translation of SIDs
to UNIX IDs.


That said, if you need to migrate data, the best approach is to reset the
ownership and permissions of the files on the member server from a Windows
machine. This way, permissions are reapplied using domain SIDs rather than
conflicting UNIX IDs.


Please note that if you have many users and complex permission structures, the
process can become time-consuming and challenging to manage.

More info here

samba.bigbird.es


On 2 Sep 2025 at 20:37 +0100, Gabin Gervais via samba <samba at
lists.samba.org>, wrote:
> Hello,
>
> I have a Samba AD domain (samba.lan). The old DC was also acting as a file
> server. I added a new DC (dc1), which correctly resolves users and groups,
> and then decommissioned the old DC. I reused that old machine as a domain
> member so it could continue serving files.
>
> The problem is that the ACLs stored on the Samba shares no longer match. On
> the new DC, the command wbinfo --sid-to-uid=S-1-5-21-xxx-1104 returns
> 3000021. However, on the member server, the very same command returns
> 1000000. As a result, the existing ACLs are no longer applied properly,
> because the SID?UID/GID mapping differs.
>
> Here?s what I have tried so far:
>
> Configured the member server with idmap config SAMBA : backend = ad and
> schema_mode = rfc2307.
>
> Checked for the uidNumber and gidNumber attributes in AD. By default, these
> attributes are not populated.
>
> If I add them manually in AD, the DC can see them via ldbsearch, but the
> member server doesn?t seem to actually use them.
>
> My goal is for the member server to use exactly the same SID?UID/GID
> mapping as the DC, in order to preserve the existing ACLs on the file
> shares.
>
> So my question is: What is the best approach to achieve this?
>
> Do I need to systematically populate the uidNumber/gidNumber attributes for
> all accounts (RFC2307), or is there a more ?native? way to reuse the
> mapping that was already in place on the old DC?
>
> Thanks a lot for your help !
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba

Thank you both for your detailed explanations ? this really helps me
understand what is happening under the hood with idmap.ldb, xidNumbers, and
why the mappings differ between a DC and a domain member.

In my case, the challenge is that I have more than 200 shares on this
server, all with existing ACLs. Re-applying permissions manually from
Windows would be extremely time-consuming and error-prone.

Could you please suggest what would be the fastest and most reliable way to
migrate this setup?

Should I invest the effort into fully populating uidNumber / gidNumber
attributes in AD (RFC2307), or

Would switching the member to the rid backend and then resetting ACLs from
Windows be more practical in the long run?

Any advice on a migration strategy that minimizes downtime and effort would
be greatly appreciated.