Skip to content

Unraid (Holly)

Overview

  • Hostname: Holly
  • IP: 192.168.1.200 (SSH on port 22159)
  • URL: holly.mdhmedia.uk
  • Role: Primary NAS, media storage, Docker host
  • Platform: Unraid 7.2.5 — runs as VM 110 on pve2 (USB boot, PCI passthrough), not bare metal
  • Containers: managed via Unraid Docker UI / XML templates (Compose Manager plugin installed but unused)

Docker Containers

Inventory as of 2026-07-03 (all on the default bridge unless noted):

Container Version Port URL Purpose
NZBGet v26.2-ls250 6789 nzbget.mdhmedia.uk Usenet downloader
Prowlarr 2.4.0.5397 9696 prowlarr.mdhmedia.uk Indexer manager
Radarr 6.2.1.10461 7878 radarr.mdhmedia.uk Movie automation
Sonarr 4.0.19.2979 8989 sonarr.mdhmedia.uk TV automation
qBittorrent 5.2.1 8080 torrent.mdhmedia.uk Torrent client
Ombi v4.53.10 3579 ombi.mdhmedia.uk Media requests
Plex 1.43.2.10687 32400 — (route commented out) Media server — dedicated br0 IP 192.168.1.210
Speedtest Tracker v1.14.5 8084 speedtest.mdhmedia.uk Network speed tracking
Audiobookshelf 2.35.1 13378 abs.mdhmedia.uk Audiobook server
Libation dev 3001 libate.mdhmedia.uk Audible library backup
iperf3 — host net — Throughput testing

Not running: webtop (created, never started), abs-organiser (exited Apr 2026). Stale XML templates with no container behind them: GrafanaLoki, NginxProxyManager, cloudflared, cloudflareddns, jackett, netvisor-daemon.

Storage

Array 91% full (analysed 2026-07-06)

/mnt/user: 24T used. The fill is almost entirely legitimate Media (22T) — TV Shows 12T, Movies 9.6T — so there is no junk to delete; the real fix is the NAS rebuild. The originally-suspected junk shares (DVDRips, tdarrcache, lancache, fbshare) are already empty (0 bytes).

Short-term reclaim candidates (share-by-share du):

Target Size Note
downloads/ completed rips ~300–400 G 2160p imports already in Media (real copies, nlink=1) — but many are actively seeding in qBittorrent; prune per-file, not wholesale
system/docker on the array 316 G two images (docker.img 100 G + docker1.img 250 G — likely one orphaned); ideally lives on cache SSD, not the array
domains/ unused VM disks ~170 G MetaTrader4 + Macinabox Monterey — being converted to compressed qcow2 (2026-07-06)
onedrive 578 G OneDrive sync copy

Retired Unraid VMs archived offsite (2026-07-06) — so they're not forgotten

Proxmox is now the hypervisor of choice; new VMs go on pve1/pve2, not Unraid. The two dormant Unraid VMs were compressed to qcow2 (MetaTrader4 166 G→55 G, Macinabox Monterey 86 G→66 G), then archived encrypted to the Hetzner Storage Box at hetzner-crypt:vm-archive/holly/ and removed from /mnt/user/domains. docker1.img (250 G orphaned docker image) was also removed. To restore a VM: rclone copy hetzner-crypt:vm-archive/holly/<name> <dest> (crypt creds in proxmox/backup/.env), then attach the qcow2 to a new Proxmox VM.

Array Usage (2026-07-03)

Disk Size Used Avail Use%
disk1 3.7T 3.5T 190G 95%
disk2 3.7T 3.5T 236G 94%
disk3 7.3T 6.1T 1.3T 83%
disk4 3.7T 3.5T 184G 96%
disk5 3.7T 3.4T 336G 92%
disk6 3.7T 3.4T 262G 93%

Shares

/mnt/user: ClaireDrive, DVDRips, KiCad, MDHAdmin, Media, appdata, caab, domains, downloads, fbshare, games, lancache, onedrive, system, tdarrcache

Media Share Structure

/mnt/user/media/
├── movies/
├── tv/
├── music/
├── audiobooks/
└── podcasts/

Download Share Structure

/mnt/user/downloads/
├── complete/
│   ├── movies/
│   ├── tv/
│   └── music/
├── incomplete/
└── watch/

Storage Best Practices

Cache Usage

  • Prefer: Data written to cache first, then moved to array (good for appdata)
  • Yes: Always on cache (fast but no parity protection)
  • No: Direct to array (slower but parity protected)
  • Only: Cache only, never moves to array

Parity Considerations

  • Parity disk(s) must be equal to or larger than the largest data disk
  • Two parity disks recommended for arrays with 6+ drives
  • Monthly parity checks help detect drive issues early