Checking NFS, Samba, chrony, Unbound and Kea health from the command line: a checklist

Goal

Confirm, from a shell, that each infrastructure service covered in this series is actually running, reachable and in the state it should be — a five-minute check after a deploy, a reboot, or before escalating an outage report.

Prerequisites

Shell access to the server (and, for a couple of checks, a client that can reach it); the relevant client tools installed (rpcbind/nfs-utils, samba-common-bin, chrony, unbound, kea-*).

Steps

1. NFS: on a server that still offers NFSv3, showmount -e <server> from a client shows the NFS server's export list, and rpcinfo -p <server> can display a list of all registered RPC programs (nfs, mountd, nlockmgr). On an NFSv4-only server both fail by design (no MOUNT protocol, rpcbind often masked); check exportfs -v on the server and ss -tn state established '( sport = :2049 )' for connected clients instead.
2. Samba, on the server as root: smbstatus is a very simple program to list the current Samba connections — run it with no arguments for a live view of connected clients, open files and locks. An empty, error-free result on a server nobody is currently using is a correct result, not a problem.
3. Time, on the server and any client: chronyc tracking is the command that displays parameters about the system's clock performance — reference ID, stratum, offset. A System time offset growing over repeated checks, or a Leap status of Not synchronised, is worth investigating. On an NTP server, chronyc clients (as root) shows which hosts are polling it.
4. DNS resolution, on the resolver as root: unbound-control status displays the server status, exiting non-zero if the daemon is not listening on its control port — a fast way to distinguish "Unbound is down" from "Unbound is up but answering badly," the latter needing a dig test against it instead.
5. DHCP, on the server: check the lease file's modification time and tail its recent entries (this series' Kea article names the default location). kea-shell, which provides a REST client for the Kea servers, can additionally send commands such as status-get to the running daemon if an HTTP control endpoint is configured (the Control Agent, or on Kea 3.0 and later the daemon's own HTTP control socket); lease queries also need the lease_cmds hook.
6. Record the result of each check with a timestamp somewhere a second person can see it before concluding a service is healthy or unhealthy from a single run.

Expected result

Each command returns promptly with output matching the service's current, known state; a stopped daemon usually fails its local check at once (connection refused), while a check that hangs points more toward a firewall or routing problem.

Limits and test basis

A clean status from one of these tools confirms the daemon is alive and answering its own control interface, not that every client-facing path works — showmount -e, for instance, does not prove a real mount succeeds, only that the export list is being served. Run these checks from more than one vantage point (locally and from a client) when a report says a service is unreachable, since a server-local check can succeed while a firewall or routing problem still blocks real clients.