Symas OpenLDAP Knowledge Base

Solving Replication Problems by Result Codes and Error Messages

Result codes 13, 32, 49 and 50 are covered in the Basic Replication Troubleshooting page.

The slapd log file is where all events in slapd are logged. All items below are found in the slapd log file.

On Unix/Linux systems, slapd logs are logged to the local4 log facility by default and log messages are saved to /var/log/syslog, /var/log/messages or similar. slapd logs can be directed to their own log file by running the following command and restarting syslog:


    echo "local4.* /var/log/slapd.log

Result Code 53 - “Server is unwilling to perform / consumer state is newer than provider”

In this scenario a consumer connects to a provider for replication and finds the contextCSN for the consumer is newer than the contextCSN for the provider.

Cause #1: The provider was reloaded from an old backup ldif and the consumer contains updates not in the backup


  1. Create an ldif copy of the consumer’s directory using the slapcat utility
  2. Stop slapd on the provider
  3. Delete the backend database files
  4. Reload the provider with ldif from the consumer
  5. Start slapd on the provider

Cause #2: If using delta-syncrepl, the cn=accesslog backend was removed


  • Perform a MOD operation on the provider. This sets an initial change record/contextCSN in the cn=accesslog and makes contextCSN comparison between providers and consumers possible.

Result Code 53 - “consumer has state info but provider doesn’t”

Cause: A consumer has a contextCSN from a provider but the provider doesn’t have a contextCSN for itself.

Situations that are likely to trigger this error are: * A provider is reloaded with an ldif from a different provider that does not have a contextCSN for the provider being loaded

Resolution: * Perform a MOD operation or add/delete a dummy entry on the provider that’s missing the contextCSN.

“null_callback” Errors

In OpenLDAP, null_callback errors occur when syncrepl receives certain error messages from an operation against slapd.

The error message is logged as null_callback : error code 0x%x The %x is a two digit hex code that maps to an LDAP result code (see LDAP Result Codes).

Message: null_callback : error code 0x10

This error is equivalent to Result Code 16, “noSuchAttribute”.

Cause: syncrepl is trying to perform a MOD operation to an attribute that does not exist on the entry

This problem occurs when using delta-syncrepl. Encountering this error means the integrity of the entire consumer in doubt. Because of this, the error triggers a full refresh of the directory.

Resolution: Allow the consumer to perform a full refresh or reload the consumer from a fresh snapshot of the provider.

Message: null_callback : error code 0x13

This error is equivalent to Result Code 19, “constraintViolation”

Cause #1: Inconsistent slapo-constraint overlay configuration

The slapo-constraint overlay is an overlay that creates user-configurable constraints (size, regular expressions, etc.). The constraint configurations must be the same on all providers and replicas, otherwise updates may not be allowed when replicated.

Resolution: Compare the constraint configuration on all providers and consumers. Correct as needed.

Cause #2: Inconsistent schema definitions

If using custom schemas, make sure that the schema files are identical across all LDAP servers. An attribute definition on one server may be set to single-valued on one server, but is multi-valued on another.

Resolution: Compare the content of custom schema files using a checksum or diff utility. Correct as necessary.

Message: null_callback : error code 0x40

This error is equivalent to Result Code 64, “namingViolation”.

Cause: A syncrepl client is partially replicating a DIT and has “schemachecking/olcSchemaChecking” set to “on”

When only part of a DIT is being replicated, attributes normally required by an object’s schema may be excluded. If schemachecking is enabled, an object can only be updated when it complies with the requirements of the objectClass. Disabling schemachecking relaxes this requirement, allowing partial objects to be replicated.

Resolution: In the syncrepl configuration on the consumer, set “schemachecking/olcSchemaChecking” to “off”