Browsing the slurpd errors I found tha the call lib/smbldap.c|smbldap_make_mod() adds the values in some odd way, the slurpd says "Type or value exists" because an "add" is performed when an pwdCanChange exists, so fails. I found this behavior in: 1. the logs (WS passwd negot. I think): [2003/08/13 11:25:27, 1] passdb/pdb_ldap.c:ldapsam_modify_entry(1218) failed to modify user dn= uid=E46$,o=smb,dc=unav,dc=es with: No such attribute modify/delete: pwdCanChange: no such value 2. with the smbpasswd command: bin/smbpasswd 111111-1 cti1 -D 256 ------------------------------------- Netbios name list:- my_netbios_names[0]="PDC7" ... element 19: CHANGED smbldap_open: already connected to the LDAP server rebindproc_connect_with_state: Rebinding as "cn=smbAdmin,dc=unav,dc=es" failed to modify user dn= uid=111111-1,o=smb,dc=unav,dc=es with: No such attribute modify/delete: pwdCanChange: no such value failed to modify user with uid = 111111-1, error: modify/delete: pwdCanChange: no such value (Unknown error) Failed to modify entry for user 111111-1. Failed to modify password entry for user 111111-1 ------ I can't catch the conditions, but the replica log shows that the first mods are as "replace" and runs, and the wrong ones tries an "add" but one pwdCanChange: more ../replica/slurpd.replog ------------------------------ replica: albus.cti.unav.es replica: boromir.cti.unav.es time: 1061047482 dn: uid=111111-1,o=smb,dc=unav,dc=es changetype: modify replace: pwdLastSet pwdLastSet: 1061046350 - replace: pwdCanChange pwdCanChange: 1061046350 - replace: pwdMustChange pwdMustChange: 1062860750 - replace: entryCSN entryCSN: 2003081615:24:42Z#0x0001#0#0000 - replace: modifiersName modifiersName: cn=smbAdmin,dc=unav,dc=es - replace: modifyTimestamp modifyTimestamp: 20030816152442Z - replica: albus.cti.unav.es replica: boromir.cti.unav.es time: 1061052015 dn: uid=111111-1,o=smb,dc=unav,dc=es changetype: modify add: pwdCanChange pwdCanChange: 1061052014 - delete: pwdCanChange pwdCanChange: 1061046350 - add: pwdMustChange pwdMustChange: 1062866414 - delete: pwdMustChange pwdMustChange: 1062860750 ---------------------- so in the server\:0.rej file: ------------------------ ERROR: Type or value exists replica: albus.cti.unav.es:0 time: 1061052015.0 dn: uid=111111-1,o=smb,dc=unav,dc=es changetype: modify add: pwdCanChange pwdCanChange: 1061052014 - delete: pwdCanChange pwdCanChange: 1061046350 -----------------
I repeated the tests, and found that the bin/smbpasswd fails in the atomic replacement of pwdCanChange value if the command is repeated so fast and the old value is fetched from the slave server *before* the master process the replica. So I think, that this should be marked as fixed, because nobody can change the passwd so fast... I think that the "atomic" replacement is the correct way.
Thanks for the update. Not our bug.
originally reported against one of the 3.0.0rc[1-4] releases. Cleaning up non-production versions.