Problem:
Network drives cannot be connected. The shares are located on a member server.
smbstatus on the member server shows:
smbstatus
Samba version 4.21.1-Univention
PID Username Group Machine Protocol Version Encryption Signing
[…]
3492289 frank sun 10.200.170.67 (ipv4:10.200.170.67:64909) SMB3_11 - partial(AES-128-CMAC)
3493394 (auth in progress) 10.0.201.51 (ipv4:10.200.201.51:50526) SMB3_11 - -
3492284 erna moon 10.200.200.49 (ipv4:10.200.200.49:54234) SMB3_11 - partial(AES-128-CMAC)
3493462 (auth in progress) 10.200.200.34 (ipv4:10.200.200.34:58076) SMB3_11 - -
3492299 wilhelm mars 10.200.191.36 (ipv4:10.200.191.36:51638) SMB3_11 - partial(AES-128-CMAC)
auth in progress shows that the memberserver cannot authenticate the user.
On primary and Backup:
[kernel] oom-kill:constraint=CONSTRAINT_NONE,global_oom,task=drepl[master],pid=[PID]
[kernel] Out of memory: Killed process [PID] (drepl[master]) total-vm:[...] anon-rss:9488948kB
[kernel] ntpd: SIGND: can not receive length: Interrupted system call
[kernel] CPU: 1 PID: [PID] Comm: alertmanager ... order=0, oom_score_adj=0
The Linux kernel’s Out-Of-Memory (OOM) killer terminated the samba: task[drepl] process, leading to a failure in directory replication services. The termination caused extreme system instability, characterized by high I/O Wait (wa) and interrupted system calls in unrelated services, such as ntpd.
Cause
The root cause was the uncontrolled expansion of the memory footprint of the drepl (Directory Replication) process. Monitoring data indicated that the Resident Set Size (RSS) grew from approximately 55 MB in April to over 9 GB by late June. This massive increase eventually exhausted all available physical RAM and the entire Swap partition. The system entered a “thrashing” state, where the CPU was primarily occupied with moving data between the RAM and the saturated Swap space, eventually triggering the OOM killer to protect kernel integrity.
Solution:
/etc/init.d/samba restart
on primary and backup the samba service ran out of memory.
How can I check the replication service:
Monitoring Samba Active Directory Replication (DRS) via Multiple Methods
The following is an overview of the available methods for monitoring Samba Active Directory Replication (DRS).
1. Automated Monitoring via the Dashboard
How does it work?
UCS performs an automatic check every 5 minutes, querying the replication status directly from the local Samba-DC. The result is sent as a metric to Prometheus and displayed as a critical alert in the UCS dashboard in case of an error.
What is checked?
- Whether the local DC can establish a connection to its replication partners
- Whether consecutive synchronization errors (consecutive sync failures) occur
- Whether the monitoring metric is present at all (missing metric = also an alert)
2. UMC Diagnostic Module (Portal)
Manually, the UCS portal provides a dedicated plugin under System → Diagnostics that checks replication in greater detail than the automated monitoring:
- Inbound: Does the DC receive changes from other DCs correctly?
- Outbound: Does the DC send changes to other DCs correctly?
Note: The automated monitoring checks only the Outbound direction. The diagnostic module checks both directions and is therefore more informative for targeted troubleshooting.
4. Manual Check via the Command Line
Manually, the replication status can be queried at any time directly on the Samba-DC (as root):
samba-tool drs showrepl