Troubleshooting

Every agent call returns 400 DisallowedHost

The agent and worker reach web at http://web:8000, which carries Host: web. Settings always appends REEF_INTERNAL_WEB_HOST (default web) to ALLOWED_HOSTS — if that’s missing or overridden, no agent ever checks in successfully. See Configuration.

Bare “Bad Request (400)” opening the UI on a LAN IP or hostname

Add that host to DJANGO_ALLOWED_HOSTS. Each concrete host listed there is then auto-added to CSRF_TRUSTED_ORIGINS (http+https, bare and :8000), so POST actions — login, acknowledge, run scan, mark-read — work without a second variable. Behind a TLS-terminating proxy, also set DJANGO_TRUST_PROXY=true.

A scan job hangs in running until it expires

Large results — Grype/syft output especially — can run to several MB. Results over ~500 KB should already post as a multipart file part (which doesn’t count against DATA_UPLOAD_MAX_MEMORY_SIZE). If a submission is still silently rejected with RequestDataTooBig, check REEF_RAW_OUTPUT_MAX_BYTES — it needs to sit well above a real result, since DATA_UPLOAD_MAX_MEMORY_SIZE is derived from it.

Lynis or OpenSCAP reports on the container instead of the host

Both need the nsenter trick to see the real host rather than the agent container:

• Lynis always uses it (falls back to a local audit only when REEF_SCAN_ROOT=/ or params.in_container is set).
• OpenSCAP prefers the host’s own oscap, then stages its own oscap into the host and runs it via nsenter. This needs the host’s glibc to be at least the agent image’s (Debian bookworm, ~2.36) — an older host falls back to probe-root mode, where file-based checks are the only trustworthy ones.

“database is locked”

SQLite runs in WAL mode with a 30-second busy timeout specifically to avoid this under normal concurrent read/write load from web/worker/beat. If it still happens, look for a long-running query or an unusually large batch write holding a write lock past the timeout.

A cancel doesn’t stop a running scan immediately

Expected — a canceled job reaches the agent on its next check-in, which happens every ~30 seconds during a scan (see Agents). The agent kills the running subprocess and discards the partial result on that check-in, not instantly.

False “agent offline” alert during a long scan

Shouldn’t happen: the agent’s 30-second keepalive check-in during a scan keeps last_seen fresh, and the offline reaper explicitly skips any agent with a claimed/running job. If you see this anyway, check whether the scan actually crashed the agent process (look at the agent container logs) rather than assuming it’s a false positive.

Where to look

• web / worker / beat container logs
• /agents/ health cards for check-in / offline state
• manage.py sysinfo for a quick environment summary
• A scan’s detail page → raw output, for parser-level issues