View source for IDs range conflict within the cluster

<div>In a clustered environment connected to an Active Directory (AD) server, user IDs (UIDs) and group IDs (GIDs) must remain consistent across all nodes. However, using the autorid backend for mapping IDs can create problems during failover. When one node fails and another takes over, autorid may map user IDs differently, causing users to lose access to shared files and folders.</div><div>If the system detects that different ID ranges are assigned to the same AD domain across cluster nodes, it will display the warning: '''"ID range conflict within the cluster."'''</div>
== Steps to resolve the problem ==
<div>Follow these steps to resolve the issue and ensure consistent ID mappings across the cluster:</div>
#'''Identify the node with correct mapping''':<br/>Log in to the node where user access is working correctly and user IDs are mapped as expected.
#'''Change the ID mapping backend''':<br/>Update the ID mapping backend from autorid to rid+tdb. The rid+tdb backend assigns IDs based on the relative identifier (RID) from the AD, ensuring the same IDs are used across all cluster nodes, while also allowing for dynamic ID assignment through the tdb backend for greater flexibility. <u>'''Don't change the tdb backend ranges to keep the UID/GIDs ranges assigned to domains so far'''</u>.
#'''Synchronize settings across nodes''':<br/>After switching the backend, the ID settings from the updated node will automatically synchronize with the other node in the cluster.
#'''Verify and check configuration''':<br/>Check that users can still access their files and folders. Perform a failover test to confirm that permissions remain correct when a node takes over.

== Why use the rid+tdb backend? ==
<div>Switching to the rid+tdb backend provides a reliable and predictable way to map IDs across nodes, avoiding conflicts caused by the dynamic ID assignment of autorid. It is a proven solution for maintaining stable user ID mappings in clustered environments.</div>