389 Directory Server Disk Monitoring: Low Disk Space Protection

Disk exhaustion can cause failed writes, abnormal shutdown, replication interruption, and possible database damage. Low disk space protection watches the filesystems Directory Server depends on, reduces log growth when space runs low, optionally switches backends to read-only mode, and shuts the instance down gracefully before storage is exhausted.

By default, Directory Server monitors the filesystems that contain its configuration, transaction-log storage where applicable, and database directories. Log filesystems also participate in shutdown monitoring when nsslapd-disk-monitoring-logging-critical=on.

This guide covers threshold sizing, enabling protection with dsconf, optional read-only and log-preservation settings, external alerting, safe testing on disposable storage, and recovery after a shutdown.

Before you start:

Install 389 Directory Server — running instance (ldap1 on dc=example,dc=com in this lab)
dsconf commands — online configuration

Tested on: Rocky Linux 10.2; 389 Directory Server 3.2.0.

How 389 Directory Server responds to low disk space

A monitoring thread checks approximately every ten seconds. The monitored filesystem with the least available free space triggers the response.

text


Available disk space falls
        |
        v
Configured threshold is reached
        |
        +--> Disable verbose and nonessential logging
        +--> Disable access and audit logging when logs are not critical
        +--> Optionally place databases in read-only mode
        +--> Remove rotated logs if free space continues falling
        |
        v
Free space falls below half the threshold
        |
        v
Start the configured shutdown grace period
        |
        +--> Free space rises above the full configured threshold:
        |         abort shutdown and restore disabled logging
        |
        └--> Space remains low: shut down Directory Server

When free space drops below 4 KiB, Directory Server shuts down immediately without waiting for the grace period:

text


Available space below 4 KiB
        |
        v
Immediate Directory Server shutdown

The active error log stays enabled through these stages so you can see why logging stopped, read-only mode engaged, or shutdown began.

With a 6 GiB threshold (6442450944 bytes), the stages look like this:

text


Configured threshold: 6 GiB

At approximately 6 GiB free:
Protective log-reduction actions begin

Below approximately 3 GiB free:
Shutdown grace period begins

Below 4 KiB free:
Immediate shutdown

To cancel a pending shutdown, free space must rise above the full configured threshold—not merely above half of it—before the grace period expires.

Understand settings and calculate a safe threshold

Setting	Purpose
`nsslapd-disk-monitoring`	Enables or disables disk monitoring
`nsslapd-disk-monitoring-threshold`	Free-space threshold in bytes
`nsslapd-disk-monitoring-grace-period`	Minutes allowed to recover space before shutdown
`nsslapd-disk-monitoring-logging-critical`	Preserves logging and includes log storage in critical monitoring
`nsslapd-disk-monitoring-readonly-on-threshold`	Enables read-only protection during low-space handling

Values observed on the tested 389 DS 3.2.0 instance:

Setting	Value
Disk monitoring	`off`
Threshold	`2097152` bytes (2 MiB)
Grace period	`60` minutes
Preserve critical logging	`off`
Read-only protection	`off`

WARNING

On this release the configured threshold was 2 MiB. Product documentation for other versions describes the default as 2 MB without guaranteeing the same byte value. Query your instance and size production thresholds from database growth, logging rate, and operator response time—not from the software default.

nsslapd-disk-monitoring-grace-period is measured in minutes. A value of 60 means roughly 60 minutes, not 60 seconds. The Red Hat command-line procedure currently describes its example as 60 seconds in some releases, while the web console procedure and upstream attribute definition specify minutes. Treat the attribute as minutes and verify the active value on your installed release.

Read the current attributes before you change anything:

bash

dsconf ldap1 config get nsslapd-disk-monitoring nsslapd-disk-monitoring-threshold nsslapd-disk-monitoring-grace-period nsslapd-disk-monitoring-logging-critical nsslapd-disk-monitoring-readonly-on-threshold

output

nsslapd-disk-monitoring: off
nsslapd-disk-monitoring-threshold: 2097152
nsslapd-disk-monitoring-grace-period: 60
nsslapd-disk-monitoring-logging-critical: off
nsslapd-disk-monitoring-readonly-on-threshold: off

The same values are visible over the instance LDAPI socket:

Directory queries in this section use the ldapsearch command.

bash

ldapsearch -Y EXTERNAL -H ldapi://%2Frun%2Fslapd-ldap1.socket -b "cn=config" -s base nsslapd-disk-monitoring nsslapd-disk-monitoring-threshold nsslapd-disk-monitoring-grace-period

output

SASL/EXTERNAL authentication started
...
nsslapd-disk-monitoring: off
nsslapd-disk-monitoring-threshold: 2097152
nsslapd-disk-monitoring-grace-period: 60

Record baseline disk usage with df and du alongside configuration:Record baseline disk usage alongside configuration:

bash

du -sh /var/lib/dirsrv/slapd-ldap1 /var/log/dirsrv/slapd-ldap1

output

5.8M	/var/lib/dirsrv/slapd-ldap1
22M	/var/log/dirsrv/slapd-ldap1

Base the threshold on how fast storage can grow during normal operations and emergencies:

text


Disk monitoring threshold =
peak hourly growth
× maximum response time
+ emergency operating reserve

Example for a busy supplier:

text


Peak storage growth:       500 MiB per hour
Maximum response time:       4 hours
Required growth reserve:     2 GiB   (500 MiB/hour × 4 hours)
Emergency operating reserve: 4 GiB

Selected threshold:          6 GiB   (2 GiB + 4 GiB)

Measure growth from monitoring metrics or by sampling free bytes on the database path at a known interval:

bash

date

bash

df -B1 --output=avail /var/lib/dirsrv/slapd-ldap1/db

Run the df command again after a known interval, or derive the rate from your monitoring platform. Use the highest observed growth rate during imports, reindexing, replication recovery, backup creation, and unusually verbose logging—not an idle lab instance alone.

Set external monitoring thresholds above the Directory Server value so operators receive warnings first:

text


Operations warning:    12 GiB free
Operations critical:    9 GiB free
Directory Server action: 6 GiB free
Shutdown condition:     3 GiB free (half of 6 GiB)

Factor in LMDB map growth, index builds, replication changelog volume, backup files, and LDIF import/export activity when you estimate peak hourly growth.

Identify the filesystems Directory Server uses

First resolve the configuration and database paths that Directory Server monitors. Check the log path as well for host-level alerting; it becomes part of Directory Server critical disk monitoring when nsslapd-disk-monitoring-logging-critical=on.

On the tested LMDB 3.2 instance, database files are stored under /var/lib/dirsrv/slapd-ldap1/db. LMDB does not use the separate Berkeley DB transaction-log directory represented by nsslapd-db-logdirectory. The exact monitored paths therefore depend on the database backend and installed Directory Server version.

Resolve each path to its mount point and collapse duplicates:

bash

for path in /etc/dirsrv/slapd-ldap1 /var/lib/dirsrv/slapd-ldap1/db /var/log/dirsrv/slapd-ldap1; do findmnt -no TARGET,SOURCE,FSTYPE -T "$path"; done | sort -u

output

/ /dev/mapper/rlm-root ext4

All three paths map to the root filesystem in this lab. sort -u collapses identical mount rows when several paths share one volume.

Check human-readable free space on monitored paths and on the log directory for host alerting:

bash

df -h /etc/dirsrv/slapd-ldap1 /var/lib/dirsrv/slapd-ldap1/db /var/log/dirsrv/slapd-ldap1

output

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/rlm-root   14G   10G  3.0G  78% /
/dev/mapper/rlm-root   14G   10G  3.0G  78% /
/dev/mapper/rlm-root   14G   10G  3.0G  78% /

df repeats the same filesystem once per path argument. That is expected when configuration, database, and logs share /.

For threshold math, read exact byte counts:

bash

df -B1 --output=target,size,used,avail,pcent /etc/dirsrv/slapd-ldap1 /var/lib/dirsrv/slapd-ldap1/db /var/log/dirsrv/slapd-ldap1

output

Mounted on   1B-blocks        Used      Avail Use%
/          14687412224 10720993280 3198025728  78%
/          14687412224 10720993280 3198025728  78%
/          14687412224 10720993280 3198025728  78%

Configuration, database, and log paths may share one root filesystem, sit on separate logical volumes, use bind mounts, or map to container persistent volumes. The monitored filesystem with the least available space triggers protective behavior. If you relocated nsslapd-directory or log paths, inspect those resolved mount points instead of assuming the default directories.

Enable low disk space monitoring

The lab example below uses a 6 GiB threshold and a 30-minute grace period. Confirm free space on every monitored filesystem is comfortably above half the threshold before you restart. With only about 3 GiB free, a 6 GiB threshold blocks startup.

Apply the settings online:

bash

dsconf ldap1 config replace nsslapd-disk-monitoring=on nsslapd-disk-monitoring-threshold=6442450944 nsslapd-disk-monitoring-grace-period=30

output

Successfully replaced value(s) for 'nsslapd-disk-monitoring': 'on'
Successfully replaced value(s) for 'nsslapd-disk-monitoring-threshold': '6442450944'
Successfully replaced value(s) for 'nsslapd-disk-monitoring-grace-period': '30'

Restart the instance after changing these attributes so the monitoring thread loads the new settings:

Offline instance work in this section uses dsctl commands.

bash

dsctl ldap1 restart

If free space is already below half the threshold, Directory Server exits during startup. The error log records:

output

[18/Jul/2026:04:37:19.168065758 +0530] - EMERG - main - Disk Monitoring is enabled and disk space on (/) is too far below the threshold(6442450944 bytes). Exiting now.

dsctl or systemd may additionally report that dirsrv@ldap1 failed to start. Inspect journalctl -u dirsrv@ldap1 for the full service error.

Lower the threshold offline in an emergency

Never edit dse.ldif while the instance is running. Treat lowering the threshold as temporary recovery, not a substitute for freeing or expanding storage.

Confirm the instance is stopped:

bash

dsctl ldap1 stop

Back up the configuration file:

bash

cp -a /etc/dirsrv/slapd-ldap1/dse.ldif /etc/dirsrv/slapd-ldap1/dse.ldif.pre-disk-recovery

Locate the disk-monitoring attributes:

bash

grep -nE '^nsslapd-disk-monitoring(-threshold)?:' /etc/dirsrv/slapd-ldap1/dse.ldif

output

1643:nsslapd-disk-monitoring: on
1644:nsslapd-disk-monitoring-threshold: 6442450944

Edit only the threshold value, preserve ownership and permissions, then start the instance:

bash

dsctl ldap1 start

After a successful restart, confirm the active values and restore an appropriate production threshold once storage is healthy:

bash

dsconf ldap1 config get nsslapd-disk-monitoring nsslapd-disk-monitoring-threshold nsslapd-disk-monitoring-grace-period

output

nsslapd-disk-monitoring: on
nsslapd-disk-monitoring-threshold: 536870912
nsslapd-disk-monitoring-grace-period: 30

The lab lowered the threshold to 512 MiB offline so the instance could start with about 3 GiB free on /.

Confirm the service is running:

bash

dsctl ldap1 status

output

Instance "ldap1" is running

Scan recent startup messages:

bash

journalctl -u dirsrv@ldap1 --since "10 minutes ago" --no-pager | tail -5

output

Jul 18 04:37:26 ldap1.example.com ns-slapd[63594]: [18/Jul/2026:04:37:26.969049933 +0530] - INFO - slapd_daemon - slapd started.  Listening on All Interfaces port 389 for LDAP requests
Jul 18 04:37:26 ldap1.example.com ns-slapd[63594]: [18/Jul/2026:04:37:26.977674361 +0530] - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests
Jul 18 04:37:26 ldap1.example.com ns-slapd[63594]: [18/Jul/2026:04:37:26.981692539 +0530] - INFO - slapd_daemon - Listening on /run/slapd-ldap1.socket for LDAPI requests

Configure read-only protection

When nsslapd-disk-monitoring-readonly-on-threshold=on, upstream design documentation places writable backends in read-only mode at the initial threshold—not at the half-threshold shutdown stage. Searches and binds can continue; add, modify, delete, and rename operations are rejected, which slows database growth while you restore free space.

Enable read-only protection:

bash

dsconf ldap1 config replace nsslapd-disk-monitoring-readonly-on-threshold=on

output

Successfully replaced value(s) for 'nsslapd-disk-monitoring-readonly-on-threshold': 'on'

Restart the instance:

bash

dsctl ldap1 restart

The tested dsctl restart command returned no output, so verify that the instance is running before beginning the low-space test:

bash

dsctl ldap1 status

output

Instance "ldap1" is running

Before you reduce free space on a disposable test host, create a throwaway entry and confirm a baseline write succeeds:

bash


ldapadd -Y EXTERNAL -H ldapi://%2Frun%2Fslapd-ldap1.socket <<'EOF'
dn: ou=disk-test,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: disk-test
description: writable baseline
EOF

output

adding new entry "ou=disk-test,dc=example,dc=com"

Run one successful modification while free space is still above the threshold:

Entry updates in this section use the ldapmodify command.

bash


ldapmodify -Y EXTERNAL -H ldapi://%2Frun%2Fslapd-ldap1.socket <<'EOF'
dn: ou=disk-test,dc=example,dc=com
changetype: modify
replace: description
description: writable baseline confirmed
EOF

output

modifying entry "ou=disk-test,dc=example,dc=com"

During disposable testing, keep a search running to confirm read availability:

bash

ldapsearch -LLL -Y EXTERNAL -H ldapi://%2Frun%2Fslapd-ldap1.socket -b "dc=example,dc=com" -s base dn

output

dn: dc=example,dc=com

After free space crosses the threshold with read-only protection enabled, repeat the same modification against ou=disk-test,dc=example,dc=com:

bash


ldapmodify -Y EXTERNAL -H ldapi://%2Frun%2Fslapd-ldap1.socket <<'EOF'
dn: ou=disk-test,dc=example,dc=com
changetype: modify
replace: description
description: read-only disk-monitoring test
EOF

When read-only protection is active at the threshold, ldapmodify typically returns ldap_modify: Server is unwilling to perform (53). Confirm the exact wording on your release during disposable testing. Search success shows the backend remains readable; result code 53 shows the server rejected the write. Do not modify a production identity simply to demonstrate read-only mode.

For manual read-only backends outside disk monitoring, see read-only database mode.

Preserve logs and tune rotation before space runs low

By default, Directory Server reclaims space by disabling access and other nonessential logging, lowering verbose error-log levels, and removing rotated archives on later monitoring passes if space continues to fall. The active error log continues.

When audit or security logs must not be disabled or deleted locally:

bash

dsconf ldap1 config replace nsslapd-disk-monitoring-logging-critical=on

output

Successfully replaced value(s) for 'nsslapd-disk-monitoring-logging-critical': 'on'

Restart and verify:

bash

dsctl ldap1 restart

bash

dsconf ldap1 config get nsslapd-disk-monitoring-logging-critical

output

nsslapd-disk-monitoring-logging-critical: on

Revert to off when the compliance requirement does not apply.

Setting	Behavior
`off`	Directory Server can disable logs and remove archives to recover space
`on`	Logs remain enabled and rotated archives are retained; shutdown can occur sooner if log growth continues or the log filesystem is the limiting monitored filesystem

Enable critical logging only when compliance outweighs automatic log reclamation. Forwarding logs to external storage is usually safer than retaining large local archives during a space emergency.

Log rotation is normal capacity management; disk monitoring is an emergency backstop. Review current log consumption:

bash

du -sh /var/log/dirsrv/slapd-ldap1 /var/log/dirsrv/slapd-ldap1/*

output

22M	/var/log/dirsrv/slapd-ldap1
15M	/var/log/dirsrv/slapd-ldap1/access
5.4M	/var/log/dirsrv/slapd-ldap1/access.20260715-134249
408K	/var/log/dirsrv/slapd-ldap1/access.20260716-134318
...

Check access-log rotation limits:

bash

dsconf ldap1 config get | grep -E 'nsslapd-accesslog-(maxlogsize|maxlogsperdir|logexpirationtime|logmaxdiskspace)'

output

nsslapd-accesslog-logexpirationtime: 1
nsslapd-accesslog-logexpirationtimeunit: month
nsslapd-accesslog-logmaxdiskspace: 500
nsslapd-accesslog-maxlogsize: 100
nsslapd-accesslog-maxlogsperdir: 10

In this lab, maxlogsize and logmaxdiskspace are in megabytes. maxlogsperdir, expiration age, maximum size, and maximum disk space interact—reaching any applicable limit can remove older logs. Apply similar review to error, audit, audit-failure, and security logs so no single log type can consume the entire reserve you planned for disk monitoring.

Monitor, alert, and test disk monitoring safely

Poll free bytes on configuration and database paths, and on the log path when you alert at the host level or when critical logging is enabled:

bash

df -B1 --output=target,avail,pcent /etc/dirsrv/slapd-ldap1 /var/lib/dirsrv/slapd-ldap1/db /var/log/dirsrv/slapd-ldap1

output

Mounted on      Avail Use%
/          3198001152  78%
/          3198001152  78%
/          3198001152  78%

Track directory growth without crossing filesystem boundaries:

bash

du -sxh /var/lib/dirsrv/slapd-ldap1/db /var/log/dirsrv/slapd-ldap1

output

4.5M	/var/lib/dirsrv/slapd-ldap1/db
22M	/var/log/dirsrv/slapd-ldap1

Check inode availability on database and log paths:

bash

df -i /var/lib/dirsrv/slapd-ldap1/db /var/log/dirsrv/slapd-ldap1

output

Filesystem           Inodes  IUsed  IFree IUse% Mounted on
/dev/mapper/rlm-root 917504 263853 653651   29% /
/dev/mapper/rlm-root 917504 263853 653651   29% /

Free blocks can remain available while the filesystem has no free inodes, preventing new database or log files. Byte-based disk monitoring does not replace inode monitoring.

Search the error log for disk-monitoring events:

bash

grep -iE 'disk|space|threshold|readonly|shutdown' /var/log/dirsrv/slapd-ldap1/errors | tail -10

output

[18/Jul/2026:04:37:19.168065758 +0530] - EMERG - main - Disk Monitoring is enabled and disk space on (/) is too far below the threshold(6442450944 bytes). Exiting now.

No output means no matching messages were found in the current error log.

Integrate host or platform monitoring—systemd timers, Prometheus node exporter, Nagios, Icinga, Zabbix, or cloud volume metrics—and alert on available bytes, percentage used, and growth rate. Container runtime or Kubernetes eviction and ephemeral-storage limits can terminate a container before Directory Server reaches its internal threshold; monitor both mounted volume capacity and platform storage limits.

Alert well above the Directory Server threshold so operators can free or expand storage before log reduction or shutdown begins.

Safe testing on disposable storage

Never fill a production database or log filesystem to demonstrate disk monitoring. Use a disposable virtual machine, temporary instance, dedicated loopback filesystem, small logical volume, or container volume.

A practical sequence:

Create a test instance on a small dedicated filesystem.
Configure a low but safe monitoring threshold with a short grace period.
Open three terminals on the test host.
Grow disk usage gradually with a removable filler file.
Observe threshold messages in the error log.
Attempt an LDAP write when read-only protection is enabled.
Continue until the grace-period warning appears.
Remove enough filler data to raise available space above the full configured threshold, then confirm Directory Server aborts the pending shutdown.
Repeat and allow shutdown in a second controlled run.
Restore free space and restart the test instance.

Terminal 1. monitor bytes on the disposable mount:

bash

watch -n 2 'df -B1 --output=target,avail,pcent /mnt/ds-disk-test'

Terminal 2. follow Directory Server events:

bash

tail -F /var/log/dirsrv/slapd-ldap1/errors

Terminal 3. keep testing reads:

bash

while sleep 5; do ldapsearch -LLL -Y EXTERNAL -H ldapi://%2Frun%2Fslapd-ldap1.socket -b "dc=example,dc=com" -s base dn; done

Confirm the disposable mount is the same filesystem Directory Server monitors for the database before you create a filler file:

bash

findmnt -no TARGET,SOURCE -T /var/lib/dirsrv/slapd-ldap1/db

bash

findmnt -no TARGET,SOURCE -T /mnt/ds-disk-test

Both commands must identify the same filesystem. Otherwise, the filler file will not reduce the available space measured for the database path. Directory Server checks the mounts used by its configuration, transaction-log storage where applicable, and database paths; log mounts are additionally checked when critical logging is enabled.

Grow usage gradually rather than jumping straight to a filler size that crosses multiple stages. Each fallocate size below is the total resulting file size, not the amount added during that step. The delay gives the approximately ten-second monitoring thread time to evaluate each stage:

bash

for size in 64 128 192 256; do fallocate -l "${size}M" /mnt/ds-disk-test/filler.dat; sleep 15; done

Successful fallocate normally produces no output. Watch the error log for threshold, logging-reduction, read-only, half-threshold shutdown, and cancellation messages. Upstream design and historical test output include lines such as disabling access logging, deleting rotated logs, and waiting for disk cleanup before shutdown.

Remove filler data during recovery:

bash

rm -f /mnt/ds-disk-test/filler.dat

bash

df -B1 --output=target,avail,pcent /mnt/ds-disk-test

rm normally produces no output. Use df to confirm that available bytes have risen above the full configured threshold.

Never aim filler files at /, production database paths, log directories, or shared replication storage.

Recover after low disk space or shutdown

When free space rises above the full configured threshold before the grace period expires, Directory Server should abort the pending shutdown, re-enable logging it disabled, and return writable backends to normal. Verify with ldapsearch, a test ldapmodify, and a fresh error-log tail—not only dsctl status.

After an actual shutdown, identify the limiting filesystem on the paths Directory Server monitors:

bash

df -B1 --output=target,avail,pcent /etc/dirsrv/slapd-ldap1 /var/lib/dirsrv/slapd-ldap1/db

output

Mounted on      Avail Use%
/          3198001152  78%
/          3198001152  78%

When paths are not obvious, list mount relationships:

bash

for path in /etc/dirsrv/slapd-ldap1 /var/lib/dirsrv/slapd-ldap1/db; do findmnt -no TARGET,SOURCE -T "$path"; done | sort -u

output

/ /dev/mapper/rlm-root

Find large directories without crossing mount boundaries:

bash

du -xhd1 /var/lib/dirsrv | sort -h

output

204K	/var/lib/dirsrv/slapd-localhost
652K	/var/lib/dirsrv/slapd-ldap2
5.8M	/var/lib/dirsrv/slapd-ldap1
6.7M	/var/lib/dirsrv

bash

du -xhd1 /var/log/dirsrv | sort -h

output

136K	/var/log/dirsrv/slapd-localhost
768K	/var/log/dirsrv/slapd-ldap2
22M	/var/log/dirsrv/slapd-ldap1
23M	/var/log/dirsrv

Check inodes before you assume byte free space is the only problem:

bash

df -i /var/lib/dirsrv/slapd-ldap1/db /var/log/dirsrv/slapd-ldap1

Look for deleted files still held open by a running process:

bash

lsof +L1

No output means that lsof found no deleted files that are still open. When a deleted log or export remains open, its blocks do not return to the filesystem until the descriptor closes.

Potential cleanup candidates, after confirming ownership, retention requirements, and whether files are still open, include obsolete LDIF exports, expired external backups, test data, and archived logs where policy allows. Do not delete active LMDB database files, dse.ldif, current replication changelog data, or the active error log.

After freeing enough space:

bash

dsctl ldap1 start

output

Instance "ldap1" has been started

bash

dsctl ldap1 status

output

Instance "ldap1" is running

Review startup messages:

bash

tail -n 50 /var/log/dirsrv/slapd-ldap1/errors

output

[18/Jul/2026:04:51:11.598339276 +0530] - INFO - slapd_daemon - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[18/Jul/2026:04:51:11.605914769 +0530] - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests
[18/Jul/2026:04:51:11.610434051 +0530] - INFO - slapd_daemon - Listening on /run/slapd-ldap1.socket for LDAPI requests

Confirm LDAP bind, base search, and a test modification. When replication is configured, list suffixes and agreement status:

bash

dsconf ldap1 replication list

output

There are no replicated suffixes

On a replicated topology, list agreements and inspect each one by name:

bash

dsconf ldap1 repl-agmt list --suffix="dc=example,dc=com"

For every agreement returned, pass the agreement name to repl-agmt status:

bash

dsconf ldap1 repl-agmt status --suffix="dc=example,dc=com" AGREEMENT_NAME

Run your documented database verification workflow if the filesystem reached 100% capacity or the server terminated unexpectedly.

Each instance (ldap1, ldap2, and so on) has its own disk-monitoring threshold. When instances share /var or a database volume, one instance’s logs or changelog can consume space the others need. Plan per-instance alerting, separate database and log volumes where practical, and host-wide quotas when several instances coexist on one machine.

Troubleshoot low disk space protection

Symptom	Likely cause	Fix
No reaction at the expected threshold	Monitoring disabled, no restart after change, threshold in wrong unit, or wrong filesystem	Set `nsslapd-disk-monitoring=on`, restart, confirm threshold in bytes on the configuration or database mount
Shutdown starts later than expected	Grace period begins at half the threshold, not at the initial threshold	Plan external alerts above the Directory Server threshold; remember the half-threshold shutdown stage
Shutdown not cancelled after cleanup	Free space rose above half the threshold but not above the full threshold	Free or expand storage until available bytes exceed the full configured threshold
Grace period feels far too long	Unit is minutes	A value of `60` is ~60 minutes, not 60 seconds
Access logging stops unexpectedly	Normal protective behavior at the threshold when critical logging is off	Check the error log; enable `nsslapd-disk-monitoring-logging-critical=on` only if retention is mandatory
Archived logs disappear	Directory Server reclaimed rotated files on a later monitoring pass	Forward logs externally; enable critical logging only with acceptance of earlier shutdown risk
Server becomes read-only	`nsslapd-disk-monitoring-readonly-on-threshold=on` and low space	Free space on the triggering filesystem; retest writes
Server refuses to start	Free space below half the threshold with monitoring enabled	Free or expand storage, or lower the threshold offline in `dse.ldif` after backup
Shutdown continues after cleanup	Space recovered on a different mount than the one that triggered the event	Run `findmnt` and `df` on every monitored path
Shutdown because logs are full with critical logging on	Log filesystem included in critical monitoring	Free log volume or relax critical logging after risk review
Cannot create files despite free blocks	Inode exhaustion	Monitor `df -i`; byte-based disk monitoring does not cover inodes

What's next

After you complete this guide, continue with:

Tune LMDB, Entry Cache and DN Cache in 389 Directory Server — LMDB map size and cache planning
Back Up and Restore 389 Directory Server — backup retention and disk use
Configure LDAP Threads and Connections in 389 Directory Server — capacity planning under load
Benchmark 389 Directory Server Performance with ldclt and logconv — load tests that reveal disk bottlenecks
Configure LDAP Search Limits in 389 Directory Server — limits that reduce expensive scans

Summary

Map configuration and database paths with findmnt and df; alert on log paths at the host level, or include them in Directory Server monitoring when critical logging is enabled.
Calculate a byte threshold from peak growth rate, response time, and an emergency reserve—query the installed instance instead of assuming a cross-version default.
Enable nsslapd-disk-monitoring, set grace period in minutes, and restart; confirm free space exceeds half the threshold first.
Enable read-only protection and critical logging only when their trade-offs match your availability and compliance goals.
Tune log rotation for steady-state capacity; use disk monitoring as the last line of defense.
Alert externally above the Directory Server threshold; test only on disposable storage and cancel shutdown only after free space rises above the full threshold.
After an incident, free space on the triggering filesystem, verify reads and writes, check inodes and deleted-open files, and confirm replication when configured.

Operational recommendations: enable disk monitoring on every production instance, forward important logs off-host, monitor inodes and growth rate, document a tested recovery runbook, and never delete active database files to reclaim space.

References

Frequently Asked Questions

1. Which filesystems does 389 Directory Server monitor?

By default, Directory Server monitors filesystems that contain configuration, transaction-log storage where applicable, and database directories. Log filesystems also participate in shutdown monitoring when nsslapd-disk-monitoring-logging-critical=on. Inspect the paths your instance actually uses rather than assuming default directories.

2. What is the default nsslapd-disk-monitoring-threshold?

On the tested 389 Directory Server 3.2.0 instance, the configured default was 2097152 bytes (2 MiB) with disk monitoring disabled. Other product releases document the default as 2 MB, so query the installed instance with dsconf config get rather than assuming an exact byte value across versions.

3. When does 389 Directory Server shut down during low disk space?

At the threshold, Directory Server begins reducing log growth and may remove rotated logs on later monitoring passes. When free space falls below roughly half the configured threshold, a grace-period shutdown timer starts. Free space below 4 KiB triggers immediate shutdown. If free space rises above the full configured threshold before the grace period expires, the pending shutdown is aborted.

4. Is nsslapd-disk-monitoring-grace-period measured in seconds or minutes?

Minutes. A value of 60 means approximately 60 minutes before shutdown, not 60 seconds. Upstream attribute documentation and the Red Hat web console use minutes; some Red Hat command-line procedure text has described the same example as seconds—verify the value on your installed release.

5. Why will Directory Server not start after I enable disk monitoring?

At startup, Directory Server refuses to run when free space on a monitored filesystem is too far below the configured threshold—often when available space is already under half the threshold. Free or expand storage, or lower the threshold offline in dse.ldif after a backup, before restarting.

6. Should I enable nsslapd-disk-monitoring-logging-critical in production?

Only when compliance requires that local access, audit, or security logs must not be disabled or deleted during a space emergency. Logs remain enabled and rotated archives are retained; continued log growth can therefore bring the instance to shutdown sooner if the log filesystem is the limiting monitored volume.

How 389 Directory Server responds to low disk space

Understand settings and calculate a safe threshold

Identify the filesystems Directory Server uses

Enable low disk space monitoring

Lower the threshold offline in an emergency

Configure read-only protection

Preserve logs and tune rotation before space runs low

Monitor, alert, and test disk monitoring safely

Safe testing on disposable storage

Recover after low disk space or shutdown

Troubleshoot low disk space protection

What's next

Summary

References

Frequently Asked Questions

1. Which filesystems does 389 Directory Server monitor?

2. What is the default nsslapd-disk-monitoring-threshold?

3. When does 389 Directory Server shut down during low disk space?

4. Is nsslapd-disk-monitoring-grace-period measured in seconds or minutes?

5. Why will Directory Server not start after I enable disk monitoring?

6. Should I enable nsslapd-disk-monitoring-logging-critical in production?

Related Articles

Migrate OpenLDAP to 389 Directory Server

Migrate 389 Directory Server from Berkeley DB to LMDB

Migrate 389 Directory Server to a New Server

Search GoLinuxCloud