adding user accounts with pdbedit using tdbsam backend does not stick to RID = 2*UID+1000. this causes problems, as RIDs can get odd numbers and cannot be distinguished from groups. right now I added a test user which got a RID of 1029 (UID = 1204, so it should get 3408). deleting this user and re-adding it ends up with a RID of 1030 repeating this procedure subsequently increased the assigned RID by 1. 1029, 1030, 1031, 1032, 1033 and so forth. when using smbpasswd the rid gets assigned as expected ! as a consequence of this bug, exporting to a different backend fails for users with an odd ridd. example: test_user with UID 1204 and wrong RID of 1033 pdbedit -e smbpasswd:/samba-users.backup --> Importing accout for test_user...failed manually changing the RID to its correct value with 'pdbedit -U' throws an error: pdbedit -r -u test_user -U 'S-1-5-21-XXXXX-YYYYY-ZZZZZ-3408' Unable to modify TDB passwd ! Error: Record does not exist occured while storing the RID index (RID_00000d50) Unable to modify entry! the correct RID is set though.
This is by design. Please read the releases for the 3.0.23 series.
a bug by design ? it's a) inconsistent between pdbedit and smbpasswd (tdbsam passwd backend) b) smbpasswd throws an error with rid values you claim to be correct as of 3.0.23 when exporting the database c) if for some reason a groupmapping already exists with e.g. a rid of 3002 (now possible without group rid=2*uid+1001) smbpasswd will happily assign this rid already used for a group to a newly added user with a uid of 1001 ! (this double assignment does not occur with pdbedit, which seems to be aware of already used group rids).