Julien LutranandClaude Opus 5
9468f30f92
Finished downloads stopped appearing in Jellyfin after the 2026-08-30 storage move, and everything looked healthy: the file was on nas, visible through NFS inside the container, and /media/downloads is a configured library. The cause is that Jellyfin watches libraries with inotify, which only reports changes made through the local mount — transmission now writes on nas while jellyfin-server reads over NFS on nuc, so no event ever reaches it. EnableRealtimeMonitor is true and SupportsLibraryMonitor reports true, which is why it looks fine. Previously both shared one local dataset on nuc and it worked. transmission now calls Jellyfin's /Library/Refresh via script-torrent-done. The hook always exits 0 and never blocks (transmission runs it synchronously; a hanging hook stalls the daemon), and both the success and missing-key paths are tested. nuc is usually powered off, so a failed request is expected and logged rather than treated as an error — the scheduled scan catches up. Also records that nuc's mount is read-only, so reorganising downloads into movies/tv-shows must now happen on nas, and the ordered checklist for "my download is not in Jellyfin" — the first three checks all passed when this was hit, which is what made it confusing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Storage: nas
Storage + backup host on the LAN, added 2026-08.
- Always-on host. nuc is now an on-demand media box (see nuc/README.md), so everything that must stay up — LAN DNS, the HTTP proxy, torrents — lives here.
- Debian 13, Supermicro A1SAi-2750F / Intel Atom C2750 (8 c, 20 W, ECC DDR3) — build procedure: nas-install.md
- SSH:
ssh -i id_rsa_claude root@192.168.0.4 - No iGPU (Avoton is headless; video is the AST2400 BMC). Anything needing hardware transcoding stays on nuc.
- Pools:
incus— ZFS mirror across the last partition of both 120 GB SSDs; holds this host's container roots. OS itself is on mdraid RAID1 + ext4 across the same disks (rationale in nas-install.md §2).tank— the 4 TB WD Red, on direct SATA. This is the whole point of the box: the disk used to hang off a JMicron USB bridge on nuc that suspended the pool 61 times in 30 days (nuc/usb4t-dropouts.md). Single vdev, accepted — nothing on it is irreplaceable.
tank/media→/export/media: the media library. Exported read-only over NFSv4 to nuc, wherejellyfin-serverreads it; written locally only bytransmission-bt.- Backups: nuc ↔ nas cross-replication (each host's instances live on the other), plus the ks4 pull leg — nas-install.md §9, ks2/nas-seed.md.
Instances
| Name | IP | Doc | Features |
|---|---|---|---|
| blocky | 192.168.0.254 | — | unprivileged, autostart; DNS ad-blocker for the LAN. Moved from nuc 2026-08-30 so it survives nuc being powered off |
| privoxy | 192.168.0.11 | — | unprivileged, autostart; filtering HTTP proxy, listens on :3128 (not privoxy's default 8118); static config in /etc/systemd/network/eth0.network, DNS=192.168.0.254. Moved from nuc 2026-08-30 |
| transmission-bt | 192.168.0.7 | ✅ | unprivileged, autostart; always-on WireGuard full tunnel → ks4 (egress = 193.70.35.17, kill switch: no default route); /export/media disk device (shift=true), downloads to /media/downloads; web UI :9091 (LAN only). Moved from nuc 2026-08-30 |
Backup pools hosted here
| incus pool | dataset | receives |
|---|---|---|
nucbackup |
tank/backup/nuc |
nuc's instances (pushed nightly, 03:30) |
ks4backup |
tank/backup/ks4 |
ks4's instances (pulled over WG, 05:00 — after FTTH) |
nasbackup |
tank/backup/nas |
nas's own instances (local copy, 04:00) |
nas's own instances are replicated locally rather than to nuc: nuc is
an on-demand box and usually powered off, so it is not a usable backup
target. nasbackup lives on tank, a different pool from the incus
SSD mirror the instances run on.