Português (Brasil): TROUBLESHOOTING.pt_BR.md
This page gives short hints for common problems. For root-cause analysis and step-by-step fixes, use the linked deep-dive docs. Operators (including consultants and customers who license the app) can use this to resolve connectivity, credential, and deployment issues before the next scan.
- Excel report — "Scan failures" sheet: Each failed target has Target, Reason (e.g.
unreachable,auth_failed,timeout), Details (exception message), and Suggested next step (a short hint from the application). Start here after a run. - Dashboard: The "Scan failures" count and recent sessions; download the report for the session to open the Scan failures sheet.
- Audit log:
audit_YYYYMMDD.log(path in config or under report output). Download via Reports → session → Download log or APIGET /logs/{session_id}. Contains connection and failure entries with target name and error text. - API responses:
POST /scan(also/startand/scan_database) returns 409 (Audit already in progress.) when this process already claimed the singleAuditEnginerun slot at request accept time, not when the background thread later starts. 429 is a separaterate_limitcap. Session/report endpoints return 404 with a clear message when the session or report is missing. HTTP 400 with an invalid/untrustedHostheader isTrustedHostMiddleware(api.trusted_hosts/api.host) — not a missing API key; add the name clients actually send and restart--web.
The application maps failure reasons to a Suggested next step in the report (e.g. "Target did not respond. Check network connectivity…"). If that is not enough, use the deep-dive docs below.
| Reason (in report) | What to check first | Deep-dive doc |
|---|---|---|
| unreachable | Network from audit host/container to target: DNS, routing, firewall, VPN. For Docker/Podman: see TROUBLESHOOTING_DOCKER_DEPLOYMENT.md. | Connectivity · Docker |
| auth_failed / authentication_failed | Credentials (user/pass, token, OAuth client_id/secret). Check unset *_from_env vars (--validate-config WARN). Avoid sending the same credential in both header and body. |
Credentials and auth |
| permission_denied | Scanner needs read access to the resource (share path, DB, API). Run as a user/service account that has access, or adjust permissions. | Connectivity |
| timeout | Target slow or unreachable; timeout value too low. Increase timeout in config (per target or global); retry during off-peak. | Connectivity |
| error (generic) | See Details in the report. Often config (missing host, port, URL) or missing optional dependency (e.g. .[shares] for SMB). |
Connectivity · Credentials |
error with #1977 in Details |
REST credential host allowlist: env secrets (token_from_env, ${VAR}, or REST pass_from_env) need auth.allowed_hosts; REST *_from_env names need prefix API_ / REST_API_ / DATA_BOAR_ (SQL/share names do not). Hostname must match base_url / auth.token_url exactly (no wildcard). Not a remote 401. |
USAGE.md (Targets: APIs) · Credentials |
error with #2007 in Details |
Power BI / Dataverse token URL is not https://login.microsoftonline.com (or includes userinfo). Connector refuses the client-secret POST. Not a remote 401. |
TECH_GUIDE.md (Power BI) · Credentials |
| missing_optional_dependency | Optional extra absent from the venv (nosql for Mongo/Redis, shares for SMB/WebDAV). Not a TCP outage. Install with uv pip install -e ".[<extra>]" (or uv sync --extra <extra>). RC sentinel treats this as fail, not SKIP. |
TECH_GUIDE.md (Databases) · LAB_COMPLETAO_RUNBOOK.md |
| redis_value_not_sampled | Redis TYPE was not string/hash/list/set/zset/stream (counts in JSON Details). Not a TCP failure. Name scan still ran. Increase coverage by converting those types or accepting the gap. |
USAGE.md (Redis) · TECH_GUIDE.md |
Filesystem scans always use path and filename. Body text for the .doc extension uses the optional mammoth library (install the legacy-doc extra: pip install -e ".[legacy-doc]" or uv sync --extra legacy-doc).
What you get: Mammoth reads Office Open XML packaged as a ZIP (the same container family as .docx). That covers some real-world .doc files that are actually OOXML, or were renamed.
Limitation: Classic Word 97-2003 binary .doc (OLE compound file) is not a ZIP; mammoth typically cannot open it, so content sample stays empty and only the name/path contributes to findings.
Data Boar will not implement native body extraction for OLE2/CFBF (Compound File Binary Format) .doc files via LibreOffice shell-out or a similar heavyweight converter. This is an explicit, permanent scope decision, not a temporary gap.
Rationale:
| Concern | Detail |
|---|---|
| Dependency weight | LibreOffice installs ~400 MB of binaries and fonts into the scan environment; unacceptable for a lightweight data-scanning container. |
| Attack surface / RCE vectors | Shelling out to an office suite to parse untrusted binary documents is a well-known RCE risk class. Parsing malformed OLE binaries with LibreOffice exposes the host to its full vulnerability surface. |
| Memory and isolation | LibreOffice is not designed for high-concurrency headless invocations; process leaks and OOM crashes have been observed in production scanning environments. |
| Format prevalence | Classic Word 97-2003 binary .doc files represent a shrinking fraction of enterprise corpora; most modern document management systems already normalize to .docx or PDF on ingestion. |
What to do instead:
- Convert upstream: Run
libreoffice --headless --convert-to docx your.doc(or a managed document-conversion service) on the files before scanning. Data Boar then reads the resulting.docxnatively. - Use
.docxoutput from your DMS: Configure your Document Management System to export in.docx/PDF when feeding Data Boar. - Filename path already scanned: Even without body content, Data Boar still flags the file via its path and filename if PII is present there (e.g.
CPF_000000000-00_contract.doc).
This decision is tracked at GitHub issue #671. No ADR is required — this is a won't-fix scope boundary, not an architectural trade-off.
Many deployments use the Docker image (or the same image under Podman). The container must be able to reach your databases, file shares (NFS/SMB), and APIs.
- Remote databases: Use the host IP or FQDN of the DB server in config (not
localhostunless the DB runs in the same container). From the host, test withpsql,mysql, or similar; from the container, ensure the container network can reach that host. On Docker Desktop,host.docker.internaloften works; on Podman, preferhost.containers.internal(see TROUBLESHOOTING_DOCKER_DEPLOYMENT.md §6). - NFS / SMB from container: Two common approaches: (1) Mount the share on the host and bind-mount that path into the container (e.g.
-v /mnt/nfs-share:/data/shares), then point a filesystem target at/data/shares; (2) Use NFS/SMB targets in config and ensure the container network can reach the NFS/SMB server (install.[shares]in the image, open firewall for NFS/SMB ports). For step-by-step and pitfalls, see TROUBLESHOOTING_DOCKER_DEPLOYMENT.md. - Container status
unhealthy: The image/Composeprobe isGET http://127.0.0.1:8088/healthinside the container (Pythonurllib, nocurl). Keep--webon in-container port 8088. See TROUBLESHOOTING_DOCKER_DEPLOYMENT.md §7. - DNS: If config uses hostnames, the container must resolve them (same DNS as host or
--dns). See TROUBLESHOOTING_DOCKER_DEPLOYMENT.md.
On Debian/Ubuntu, Fedora, and RHEL/Alma/Rocky/Oracle 10, the default pipx install data-boar path is currently frictionless when the host already resolves Python >=3.12.
For other Linux paths, use the split below (no overclaim):
These hosts can still resolve default python3 below the package floor and fail with:
ERROR: Ignored ... Requires-Python >=3.12ERROR: No matching distribution found for data-boar
Use Python 3.12 explicitly:
sudo dnf install -y python3.12
pipx install --python python3.12 data-boar- Void-glibc: currently passes in the default path (
pipx install data-boar) because PyPI publishes a compatiblecp314wheel. - Void-musl: upstream publishes no
scikit-learnmusllinux wheel on any CPython tag. Step 1 below still needs a local wheel folder (or a direct.whlURL — not a GitHub release page). Step 2 is required for the ML stack; on x86-64-v1 CPUs step 2 is also required to replace PyPI numpy (see x86-64-v1 / wheelhouse install).
In this path, scikit-learn can fall back to source build on musl. Without build tools, pipx install data-boar may fail with metadata-generation-failed.
A local toolchain build (apk add build-base gfortran openblas-dev) fixes musl gaps but does not fix x86-64-v1 CPUs — PyPI numpy/scipy wheels still SIGILL there. For pre-2011 x86 hardware, use the wheelhouse path instead of assuming a successful compile equals a working binary stack.
If no wheelhouse is available and the CPU is modern, install prerequisites first:
apk add build-base gfortran openblas-dev
pipx install data-boarSee #929 and #1182 for wheelhouse evolution.
Use this when any of the following apply:
- musl (Alpine, Void-musl) and you need the full ML stack without a local Fortran toolchain.
- Pre-2011 x86 CPUs where
import numpydies withIllegal instruction(Intel Core 2 / Celeron / Pentium class —ssse3only, no SSE4.2/POPCNT). The floor isx86-64-v1, not merely “no AVX”: PyPI wheels targetx86-64-v2or higher; environment variables (NPY_DISABLE_CPU_FEATURES,OPENBLAS_CORETYPE) do not help because the crash is in compiled baseline code, not runtime dispatch (#929).import core.engineno longer dies here: the detector's CPU preflight (core.cpu_preflight) checks those CPU flags before importing numpy; if the flags are missing, it runs a probe of the installed stack in a child process. If the probe succeeds (e.g. a wheelhouse x86-64-v1 build), ML/DL is enabled. If the probe fails (killed by a signal such as SIGILL, a timeout, a non-zero exit, or a start error), ML/DL is skipped, a warning is logged with the specific cause, and regex CPF/CNPJ continues. To restore working ML on this CPU, use this wheelhouse (product path[noavx], not a PyPI extra) — the two-step--no-index --find-linksinstall below. Distro numpy (apk add py3-numpy/apt install python3-numpy) or a source build with-Dcpu-baseline=minare fallbacks, not the verified stack. - Air-gapped or egress-restricted installs that must resolve offline.
Hosted release (verified): wheelhouse-x86-64-v1-2026-07-29 on DataBoar/data-boar-site — 54 .whl assets, SHA256SUMS attached. Full install/verification prose also ships in the release README.md asset.
boar_fast_filter is not on PyPI. The published data-boar wheel is py3-none-any with zero compiled extensions — every PyPI-only install uses the pure-Python pre-filter fallback. The wheelhouse is today the only distribution channel for the Rust accelerator (cp38-abi3, one wheel per libc).
A PEP 503 simple/ index for the hosted wheelhouse ships from DataBoar/data-boar-site (PR #21; product tracking #1445). Canonical URL:
https://databoar.com.br/simple/
(https://databoar.github.io/data-boar-site/simple/ redirects to the same apex path.)
# Resolve a wheelhouse package by normalized name (example: Rust accelerator)
pip install --extra-index-url https://databoar.com.br/simple/ boar-fast-filter
# After pipx installed data-boar — inject from the remote index
pipx runpip data-boar install --extra-index-url https://databoar.com.br/simple/ boar-fast-filterTie-breaker: --extra-index-url merges candidates with PyPI; it does not prefer the wheelhouse. When both publish the same version and platform tag (e.g. numpy 2.5.1 manylinux/musllinux), pip may still install the PyPI wheel (x86-64-v2+ / SIGILL on min-spec hosts). For the ML stack on musl or x86-64-v1, keep the two-step --force-reinstall / --no-index contract in the next subsection (local folder or downloaded wheels). PEP 440 local versions (+x86v1) remain a separate #1182 remainder — the index alone does not close that gap.
Regenerate the HTML tree in the site repo (scripts/build-wheelhouse-index.py) after each wheelhouse release. The product tree does not host a duplicate builder.
Filenames match PyPI (numpy-2.5.1-cp312-cp312-musllinux_1_2_x86_64.whl, etc.), so pip can still pick the upstream wheel on step 1. The install is two forced steps after download (plus accelerator inject):
--find-linksaccepts a local directory, a direct URL to a.whl, or an HTML page of links — not a GitHub release page. With ~50 wheels, download to a folder first (or use the remote index for name resolution, then still force-reinstall the ML stack as below).
TAG=wheelhouse-x86-64-v1-2026-07-29
mkdir -p ~/wheelhouse-v1
gh release download "$TAG" --repo DataBoar/data-boar-site \
--pattern '*musllinux*' --pattern '*-none-any.whl' --dir ~/wheelhouse-v1
# glibc hosts: swap *musllinux* for *manylinux*
# without gh: download the same assets from the release page (browser or curl -LO)
# tmpfs trap — see below before any pip step that may compile
export TMPDIR="${TMPDIR:-/var/tmp/data-boar-build}"
mkdir -p "$TMPDIR"
pipx install data-boar --pip-args="--find-links $HOME/wheelhouse-v1"
pipx runpip data-boar install --no-index --find-links $HOME/wheelhouse-v1 \
--force-reinstall numpy scipy scikit-learn pandas
pipx inject data-boar boar_fast_filter --pip-args="--no-index --find-links $HOME/wheelhouse-v1"Single-wheel --find-links (one missing musllinux cell only) can unblock step 1 but does not replace PyPI numpy on v1 CPUs — you still need the offline --force-reinstall step.
If install fails with [Errno 28] No space left on device while root disk has free space, check whether /tmp is a small tmpfs (default: half of RAM). A scikit-learn source build may not fit even on hosts with hundreds of GB on disk. Point pip scratch space at real storage before step 1:
export TMPDIR=/var/tmp/data-boar-build && mkdir -p "$TMPDIR"Interaction with --demo: demo report output goes to $TMPDIR/data_boar_demo. If you set TMPDIR for install, look for the report there — not only under /tmp.
python -c "from core import detector; print(detector._ML_AVAILABLE)" # must print True
python -c "
import glob, os, numpy
so = glob.glob(os.path.join(numpy.__path__[0], '_core', '_multiarray_umath*.so'))[0]
print(os.path.getsize(so), 'bytes')
"
# this wheelhouse: ~5–5.3 MB; PyPI numpy on same tag: ~10.8 MB (SIGILL on v1)
objdump -d "$(python -c 'import glob,os,numpy;print(glob.glob(os.path.join(numpy.__path__[0],"_core","_multiarray_umath*.so"))[0])')" \
| grep -c popcnt # must print 0Field parity (1.7.4.post10, --demo): 26 findings, _ML_AVAILABLE=True — same count as Debian/Fedora/Alma glibc paths when the harness waits for the report (see matrix doc). On metal: Intel Celeron 900, Alpine/musl, offline wheelhouse path.
data-boar --demodoes not exit after the scan — it starts the API on127.0.0.1:8088and stays in LISTEN. Wait for the report under$TMPDIR/data_boar_demo, not for the process to return.- If you changed
TMPDIRfor install (tmpfs workaround), the demo report follows$TMPDIR— do not search only/tmp/data_boar_demo.
Do not assume a smooth default PyPI path. Use the x86-64-v1 wheelhouse install or Docker.
Treat native pipx install as unsupported for current builds (EOL repositories and unreachable Python floor). Use Docker.
- With a trained consultant: A consultant can install, configure, and tune Data Boar in your network; set credentials and targets; run scans and interpret reports. This is the lowest-risk way to get value when IT/compliance/DPO maturity is still growing.
- License only (self-service): You can run the app yourself: follow TECH_GUIDE, USAGE, and deploy/DEPLOY. Use this troubleshooting guide and the deep-dive docs when you hit connectivity or credential issues. For complex environments (many sources, strict firewall, SSO/OAuth), consultant support is still recommended.
- Docker: Most deployments use the container; connecting to remote DBs and to NFS/SMB is documented in the deploy and troubleshooting docs above.
| Topic | Description | English | Português (pt-BR) |
|---|---|---|---|
| Connectivity | Network, DNS, firewall, timeouts; DB/API/share unreachable; permission_denied | TROUBLESHOOTING_CONNECTIVITY.md | TROUBLESHOOTING_CONNECTIVITY.pt_BR.md |
| Credentials and auth | API key in header vs body; Basic/Bearer/OAuth; *_from_env unset; lockouts |
TROUBLESHOOTING_CREDENTIALS_AND_AUTH.md | TROUBLESHOOTING_CREDENTIALS_AND_AUTH.pt_BR.md |
| Docker / Podman | Running in container; NFS/SMB; remote DB; DNS; volumes; Podman hostnames | TROUBLESHOOTING_DOCKER_DEPLOYMENT.md | TROUBLESHOOTING_DOCKER_DEPLOYMENT.pt_BR.md |
Documentation index: README.md · README.pt_BR.md.