Downloads & folder layout (Holly /mnt/user/downloads)¶

How the download clients and the arr stack share the downloads share on Holly, and the intended folder structure* so the share stays legible if browsed manually.

The flow¶

flowchart LR
    P[Prowlarr<br/>indexers] --> R[Radarr / Sonarr]
    R -->|torrents| Q[qBittorrent]
    R -->|usenet| N[NZBGet]
    Q --> C[/downloads/complete/...]
    N --> C
    C -->|import: move/hardlink| M[/mnt/user/Media]
    R -.->|manages import| C

A grab goes to qBittorrent (torrent) or NZBGet (usenet); on completion it lands under downloads/complete/<category>/; Radarr/Sonarr import it into /mnt/user/Media (move or hardlink) for indexing. The copy left in downloads/ is staging — safe to remove once imported and (for torrents) no longer seeding.

Intended structure¶

/mnt/user/downloads/
├── incomplete/          # in-progress (qBittorrent temp + NZBGet InterDir) - never import from here
├── complete/            # finished, awaiting/after *arr import
│   ├── movies/          # Radarr category
│   ├── tv/              # Sonarr category
│   └── music/           # (if used)
└── watch/               # .nzb / .torrent drop dir

Who owns which path¶

Container /downloads == host /mnt/user/downloads (the linuxserver bind mount). The qbittorrent/nzbget MCP servers apply this map so a host path can be looked up directly.

Cleanup of the current mess¶

The share currently has loose top-level release folders (e.g. Interstellar 2014 2160p…) outside the category tree — old/manual grabs or items still seeding. Do not bulk-delete. Per item, cross-reference with the MCPs before touching:

• qbittorrent: find_torrent_by_path "<name>" → SEEDING - do not delete vs COMPLETE_STOPPED.
• nzbget: find_download "<name>" → whether NZBGet still tracks it.
• Confirm the title exists under /mnt/user/Media (imported) before removing the staging copy.

Only items that are imported into Media and not seeding are safe to remove; the rest either finish seeding first or get relocated into the category tree.

Live snapshot (2026-07-06, via the MCPs)¶

• qBittorrent: 56 torrents, all 56 actively seeding (47 tv-sonarr, 9 radarr); seed ratios median 2.60, max 83.93. All 56 sit at the top level of /downloads (tracker-named www.UIndex.org - … folders / loose release dirs) — none use a complete/<category>/ save-path. That is the whole "mess": not junk, but unorganised seeding data.
• NZBGet: queue 0, history 0 — the usenet side is clean; it contributes nothing.
• Nothing is safe to delete right now (everything is seeding). Reclaim path:
• Set a qBittorrent seeding limit (e.g. ratio 2.0 or 14 days → stop) so torrents auto-complete; enable Radarr/Sonarr "Remove Completed" so they clean up post-seed.
• Configure category save-paths (tv-sonarr → /downloads/complete/tv, radarr → /downloads/complete/movies) so future grabs self-organise. Existing seeding torrents are left in place (moving them breaks seeding); they migrate naturally as they finish and are re-grabbed.
• Flag: a torrent named Scream 7 (2026) [1080p] [WEBRip] [5.1].exe is seeding — a video file with an .exe extension is a classic fake/malware pattern; recommend removing it (with data) via delete_torrent. (This class of fake is now removed automatically — see the sweep below.)

Automated protection & reclaim (Jarvis neteng crons)¶

Since 2026-07-30 two Jarvis cron jobs police this share automatically — the only sanctioned auto-deletes, run under the SOUL.md "Reclaim and malware protocol":

• neteng-malware-sweep (daily 07:30) auto-removes fake video torrents — video category + an executable file extension + no real video file (capped at 5 per run). It prefers the Radarr/Sonarr queue delete with blocklist=true — the bad release is blocklisted and re-searched — and falls back to a direct qBittorrent delete only for orphans the *arrs don't track. Its first run removed three fakes (an Odyssey .exe and two House of the Dragon .scr) — exactly the pattern flagged in the snapshot above.
• neteng-reclaim-scan (Mon 09:00) automates the manual cross-referencing above: it compares *arr imported history against qBittorrent, writes workspace/reclaim-pending.tsv, and a Telegram reply (reclaim delete / list / cancel) acts on it. Nothing is deleted without that reply.

Space pressure is real: Holly's data disks sit at 90-96% used (disk4 96%, disk1 95%, disk6 93%, disk2 90%). A dedup pass on 2026-07-28 deleted 263.9 GB of byte-verified duplicates (146.5 GB of duplicated movie downloads among them), and Holly itself is fully recovered — its Docker daemon (the qBittorrent/NZBGet host) came back after a VM reboot on 2026-07-29, the 2026-07-25 boot-USB failure having corrupted docker.img.