slapadd Command in Linux: Import LDIF into an OpenLDAP Database

Before loading a lab database, parse the exact LDIF and configuration without writing anything. This is the first import-style example to run.

sudo slapadd -u -F /etc/openldap/slapd.d -n 2 -l /root/ldap-data.ldif

On valid input, dry-run mode normally exits with no output and status 0. That means parsing reached the backend without writing entries; it is not a substitute for a full restore test. Still stop slapd before a real load.

When you build a fresh LDIF instead of restoring from slapcat, generate {SSHA} values with slappasswd rather than placing clear-text passwords in the file.

slappasswd -s 'testpass123'

Sample output:

{SSHA}nC4ifO46PORLqtfdGNtObRXcune8BDUQ

Paste the hash into userPassword in the LDIF, then dry-run the import with slapadd -u before loading offline.

Combine -u with -v when you want a line-by-line preview of the import order before touching the MDB files.

sudo slapadd -u -v -F /etc/openldap/slapd.d -n 2 -l /root/ldap-data.ldif

Sample output:

added: "dc=example,dc=com" (00000000)
added: "ou=people,dc=example,dc=com" (00000000)
added: "ou=groups,dc=example,dc=com" (00000000)
added: "cn=developers,ou=groups,dc=example,dc=com" (00000000)
added: "uid=jdoe,ou=people,dc=example,dc=com" (00000000)
added: "ou=service-accounts,dc=example,dc=com" (00000000)
added: "uid=replicator,ou=service-accounts,dc=example,dc=com" (00000000)
added: "uid=repltest1752462420,ou=people,dc=example,dc=com" (00000000)

Eight added: lines match the eight DNs in the lab export from slapcat; no data was written because -u was set.

Use this only after stopping slapd and clearing or creating a disposable database according to your lab procedure. Never point it at an active production database.

sudo slapadd -F /etc/openldap/slapd.d -n 2 -l /root/ldap-data.ldif

Successful imports are normally silent. The command adds entries and builds configured indexes, so start slapd only after ownership, slaptest, and your restore validation are complete.

Select the database by naming context when its index is different on another lab server.

sudo slapadd -F /etc/openldap/slapd.d -b 'dc=example,dc=com' -l /root/ldap-data.ldif

Successful imports are normally silent. Do not include -n in this command because -b and -n are mutually exclusive.

When a load fails midway, fix the LDIF and jump past the already-imported records. Use slapcat -v or grep -n '^dn:' to find the line number.

sudo slapadd -u -F /etc/openldap/slapd.d -n 2 -l /root/ldap-data.ldif -j 5

Dry-run mode with -j 5 skips the first four LDIF lines and parses the remainder without writing. Confirm the jump point on a disposable copy before repeating on the real backend.

The configuration backend is database 0. Use it only when rebuilding an offline lab configuration that already has the required config database on disk.

sudo slapadd -F /etc/openldap/slapd.d -n 0 -l /root/ldap-config.ldif

Successful imports are normally silent. A config restore can make slapd unable to start, so validate it with slaptest before starting the service.

Generic -o options adjust import behavior. schema-check=no is for special objects such as partial replicas — not routine lab restores.

sudo slapadd -u -o schema-check=no -F /etc/openldap/slapd.d -n 2 -l /root/ldap-data.ldif

On a normal data LDIF the dry run still succeeds silently. Reserve schema-check=no for documented replication edge cases, not to hide ordinary schema mistakes.

-q reduces checks and status output. It is suitable only for a repeatable lab load after a normal dry run and a known-good restore procedure.

sudo slapadd -q -F /etc/openldap/slapd.d -n 2 -l /root/ldap-data.ldif

The command may be silent on success. Avoid -q when diagnosing data problems: an interruption or malformed input can leave the resulting database unusable.

-w writes syncrepl context information after the load; -S sets the Server ID used in generated entryCSN values. Use both only in a replication-aware restore plan.

sudo slapadd -u -w -S 1 -F /etc/openldap/slapd.d -n 2 -l /root/ldap-data.ldif

Dry-run mode previews the path without updating contextCSN. On a real offline restore, document the Server ID you choose so it does not collide with an existing provider or consumer.

Use standard input when a tightly controlled pipeline produces the LDIF. Keep the source file and command log protected.

sudo slapadd -u -F /etc/openldap/slapd.d -n 2 < /root/ldap-data.ldif

Dry-run mode normally prints nothing on valid input. Keeping -u in this pipeline demonstrates the data path without modifying the backend.