Lusankya (Network Attached Storage)
UnRAID Server in a QNAP Box

System Identity & Hardware
Overview
Lusankya is the QNAP TS-873 chassis, repurposed from stock QNAP QTS to bare-metal UnRAID 7.2.4 (previous version: 7.2.3) after the original QNAP OS failed. This page documents the hardware as captured in diagnostics on 2026-06-23.
Hardware
Component
Detail
Chassis
QNAP TS-873 (8-bay)
Motherboard
AMD Bettong CRB, AMI BIOS QY03AR53 (2018-03-01, BIOS rev 5.12)
CPU
AMD Embedded R-Series RX-421ND, 4 cores/4 threads, 1.4–2.1 GHz
RAM
31 GiB total (no swap configured)
Boot device
Internal flash (
sda, 30GB partition)
Network
Interface
Role
Address
br0 (eth0)
Primary LAN bridge
192.168.1.77/24
eth2
2.5GbE NIC
192.168.1.119/24
tailscale1
Remote access overlay
100.70.97.16/32
Server hostname resolves as 
Lusankya.local — no SSL/HTTPS configured on the management UI (HTTP only, port 80).
DNS rebinding protection is disabled, so 
myunraid.net remote-access URLs will resolve on this LAN.
Notes / Gotchas
This hardware previously ran QNAP QTS; the OS migration to UnRAID is a known discontinuity point — any documentation or scripts referencing the old QTS Container Station predate this rebuild and are stale.
No swap configured — if RAM pressure becomes an issue under heavier Docker workloads, there's no overflow cushion.
Last Updated
2026-06-23 (from diagnostics snapshot 
lusankya-diagnostics-20260623-1011)

Array Configuration & Shares
Overview
Lusankya's array uses UnRAID's single-parity protection model — this is not traditional RAID 6. One dedicated parity drive protects against a single data-disk failure; there is no second parity drive in this configuration. (
mdNumDisks=8 → 1 parity + 7 data disks.)
Correction worth flagging: earlier references to this as an "8-bay RAID 6" setup are inaccurate to how UnRAID actually protects data. Each data disk is independently formatted XFS — UnRAID computes parity across disks rather than striping like classic RAID. Functionally it tolerates one failed disk (or two, only if a second parity drive is added), but the mechanism and recovery process differ meaningfully from hardware RAID 6.
Array Layout
Role
Device
Filesystem
Parity
sdg
— (parity, no FS)
disk1–disk6
sdh–sdm
XFS
disk7
sdn
XFS
Cache pool
sde + sdf
BTRFS, RAID1 (2× 256GB SSD)
Cache Pool
Profile: BTRFS RAID1, 2 devices (mirrored) — 
Timetec 35PN2280SATA-256GB × 2
Hosts 
docker, 
appdata, and 
system shares exclusively (
shareUseCache="only")
Docker image: 
/mnt/cache/docker/docker.img, 20GB, native backing FS
Custom Docker networks defined: 
eth1 eth3 eth4
Shares
Share
Cache Use
Disks
appdata
Cache only
cache pool
docker
Cache only
cache pool
system
Cache only
cache pool
Data
No (array direct)
disk1, disk2, disk6, disk7
Photos
No (array direct)
disk1, disk2, disk5, disk6, disk7
Multimedia
No (array direct)
disk1–disk7 (all)
All three array shares export NFS as 
private security with an explicit host allow rule for 
192.168.1.85 (Centerpoint) only.
USB Backup Targets (Unassigned Devices)
These are not array members — they're Unassigned Devices plugin-managed USB drives, matching the rclone backup scripts already documented for this host:
Mount
Drive
Raw Capacity
Used
/mnt/disks/Expansion24
ST24000DM001
24TB
13TB / 22TB usable (58%)
/mnt/disks/Expansion26
ST26000DM000
26TB
19TB / 24TB usable (80%)
Notes / Gotchas
appdata/
docker/
system are cache-only — if the cache pool fills or both SSDs fail simultaneously, Docker and VM services go down hard since Mover has nothing to fall back to for those shares.
Array capacity is getting tight: disk1–disk5 are sitting at 87–94% utilized. disk7 (the newest member, WD Red 5TB) is the slack — only 30% used. Worth planning a rebalance or disk7 expansion before disk1–disk5 fill completely.
Last Updated
2026-06-23

Disk Inventory & SMART Health
Overview
Full physical disk inventory from the 2026-06-23 diagnostics SMART reports. Age is derived from 
Power_On_Hours, which reflects cumulative powered-on time, not calendar age since purchase — a drive bought 3 years ago but spun down often will show fewer hours than its shelf age.
Array Disks
Role
Model
Serial
Capacity
Power-On Hours
Approx. Age
Reallocated Sectors
Pending Sectors
SMART Health
Parity
ST6000VN0033-2EE110
ZAD9HJ1G
6TB
56,390
~6.4 yrs
0
0
✅ PASSED
disk1
ST6000VN0033-2EE110
ZAD9CS4N
6TB
56,390
~6.4 yrs
0
0
✅ PASSED
disk2
ST6000VN0033-2EE110
ZAD9HMSB
6TB
56,390
~6.4 yrs
0
0
✅ PASSED
disk3
ST6000VN0033-2EE110
ZAD9HPXB
6TB
56,391
~6.4 yrs
0
0
✅ PASSED
disk4
ST6000VN0033-2EE110
ZAD9HM6T
6TB
56,391
~6.4 yrs
0
0
✅ PASSED
disk5
ST6000VN0033-2EE110
ZAD9HN0N
6TB
56,390
~6.4 yrs
0
0
✅ PASSED
disk6
ST6000VN0033-2EE110
ZAD9HP9K
6TB
56,390
~6.4 yrs
0
0
✅ PASSED
disk7
WDC WD50EFRX-68MYMN1
WD-WX11DC4498K3
5TB
46,143
~5.3 yrs
0
0
✅ PASSED
Cache Pool
Role
Model
Serial
Capacity
Power-On Hours
Approx. Age
SMART Health
cache
Timetec 35PN2280SATA-256GB
QY250626A2C0721
256GB
5,665
~0.65 yrs
✅ PASSED
cache2
Timetec 35PN2280SATA-256GB
QY250626A2C0719
256GB
5,545
~0.63 yrs
✅ PASSED
Unassigned USB Backup Drives
Mount
Model
Serial
Capacity
Power-On Hours
Approx. Age
SMART Health
Expansion24
ST24000DM001-3Y7103
ZXA0VGZY
24TB
6,647
~0.76 yrs
✅ PASSED
Expansion26
ST26000DM000-3Y8103
ZXA0DK4L
26TB
3,898
~0.44 yrs
✅ PASSED
Boot/Unmonitored Devices
Device
Role
Note
sda
Internal boot flash
No SMART attributes reported — normal for USB flash media; not a fault
sdb
USB module
No SMART attributes reported — same as above
Fleet Summary
✅ Zero reallocated sectors, zero pending sectors, zero offline-uncorrectable sectors across every spinning and solid-state disk in the fleet. Every drive reports SMART overall-health PASSED. This is a clean bill of health as of this snapshot.
The 7× Seagate IronWolf array drives are the oldest hardware at ~6.4 years powered-on time — they're the ones to watch first for any future SMART degradation, given they're well past the 5-year mark commonly cited as when AFR (annualized failure rate) starts climbing for NAS-class drives.
Notes / Gotchas
Power-on hours ≠ calendar age. If these IronWolf drives were purchased used or pulled from another array, actual unit age could exceed 6.4 years.
Re-run diagnostics quarterly and diff this table — a sudden jump in Reallocated_Sector_Ct or Current_Pending_Sector between snapshots is the earliest warning sign, well before SMART flips to FAILED.
Last Updated
2026-06-23

Parity Checks & Mover
Overview
UnRAID maintenance centers on two automatic background processes: parity checks (data integrity verification) and Mover (cache-to-array file migration). Neither is configured to run on a schedule in the current diagnostics snapshot — both should be reviewed.
Parity Checks
A parity check reads every data disk simultaneously, recomputes parity, and compares it against the parity drive — it confirms the array is internally consistent, not that the data itself is uncorrupted.
Non-correcting checks (report-only) are the safe default for routine scheduling; correcting checks should only run after an unclean shutdown or to fix errors a non-correcting check already found.
UnRAID automatically triggers a parity check after any unsafe shutdown — using a UPS is the primary defense against triggering this unnecessarily.
Recommended cadence for this array size (6TB drives): monthly, scheduled during low-usage overnight hours via Settings → Scheduler → Parity Check. A full check on a 6TB array typically runs 4–12 hours depending on concurrent load.
Mover
Mover transfers files between cache and array based on each share's Primary/Secondary storage and cache-use settings.
On this host, 
appdata/
docker/
system are cache-only (Mover takes no action on them) — 
Data/
Photos/
Multimedia write directly to the array (Mover also has nothing to move for these, since they bypass cache entirely).
Since none of the array-facing shares use cache as a write buffer, Mover schedule is largely inactive on this host today — worth confirming this is intentional rather than an oversight, since it means large incoming writes to those shares go straight to spinning disk at HDD write speed rather than bursting to SSD first.
Notes / Gotchas
Always disable Docker and VM Manager before manually running Mover — open file handles from running containers can cause incomplete or failed moves.
Mover activity is also the trigger for the NFS stale-file-handle issue documented on the Gotchas page — when Mover relocates a file, its underlying fileid changes, and NFS clients holding the old handle break.
Last Updated
2026-06-23

USB Cold-Backup Scripts (Expansion24 / Expansion26)
Overview
Two UnRAID User Scripts mirror array shares to two USB-attached cold-backup drives via 
rclone sync. Both scripts were extended with Pushover push notifications on completion (success or failure), since User Scripts has no built-in alerting.
Backup Mapping
Target Drive
Shares Covered
Expansion24 (24TB)
Data (full), 
Photos, 
Multimedia/Movies, 
Multimedia/ST
Expansion26 (26TB)
Multimedia/Audio, 
Multimedia/Books, 
Multimedia/Personal, 
Multimedia/TV, 
Multimedia/To Review, 
Multimedia/Ubooquity, 
Multimedia/audiobookshelf
Script Logic (both jobs share this pattern)
#!/bin/bash
 
# === Pushover Config ===
PUSHOVER_TOKEN="<redacted — see Pushover application dashboard>"
PUSHOVER_USER="<redacted — user key, not stored in script comments>"
 
FAILED_JOBS=""
START_TIME=$(date +%s)
 
send_pushover() {
  local STATUS="$1"
  local MESSAGE="$2"
  curl -s \
    --form-string "token=${PUSHOVER_TOKEN}" \
    --form-string "user=${PUSHOVER_USER}" \
    --form-string "title=UnRAID Backup - <ExpansionXX>" \
    --form-string "message=${MESSAGE}" \
    --form-string "priority=$( [ "$STATUS" = "FAIL" ] && echo 1 || echo 0 )" \
    https://api.pushover.net/1/messages.json > /dev/null
}
 
run_sync() {
  local SRC="$1" DEST="$2" LOG="$3" LABEL="$4"
  rclone sync "$SRC" "$DEST" --log-file="$LOG" -v
  if [ $? -ne 0 ]; then
    FAILED_JOBS="${FAILED_JOBS}\n- ${LABEL}"
  fi
}
 
# One run_sync call per share/subfolder pair...
 
END_TIME=$(date +%s)
DURATION=$(( (END_TIME - START_TIME) / 60 ))
 
if [ -z "$FAILED_JOBS" ]; then
  send_pushover "OK" "All jobs completed successfully in ${DURATION} min."
else
  send_pushover "FAIL" "Backup finished with failures in ${DURATION} min.\nFailed jobs:${FAILED_JOBS}"
fi
Key design points:
Each 
rclone sync call is wrapped in 
run_sync(), capturing its own exit code — a failure in job 2 of 7 doesn't mask or get overwritten by job 7's exit code.
All jobs run independently to completion regardless of earlier failures (no 
set -e) — by design, so one broken share doesn't block backups of everything else.
A single Pushover notification fires at the end summarizing success or listing exactly which job(s) failed, with failure notifications set to 
priority=1 to bypass Pushover quiet hours.
Notes / Gotchas
Both 
PUSHOVER_TOKEN and 
PUSHOVER_USER should be redacted from any wiki copy of this script — store actual credentials in the User Scripts plugin directly, not in a doc that might get exported or shared.
$? only reflects the immediately preceding command — if a future edit pipes 
rclone output through another command (
| tee, 
| grep, etc.), the exit code capture breaks silently. Keep the exit-code check directly after the 
rclone call.
These backups are not parity-protected — they live on Unassigned Devices, outside the array. A single backup drive failure has no recovery path other than re-running the sync from source.
Last Updated
2026-06-23

UnRAID Operational Gotchas
Overview
Accumulated friction points from running UnRAID on Lusankya and integrating it with Centerpoint's Docker stack. Each entry includes root cause and the working fix.
1. NFS "Stale File Handle" After Mover Runs
Symptom: A client (Centerpoint) holding an NFS mount to a Lusankya share suddenly gets 
Stale file handle on 
ls or file access, requiring an unmount/remount to recover.
Root cause: When Mover relocates a file between cache and array, the underlying FUSE file ID changes. NFS clients cache file handles tied to the old fileid; UnRAID's 
fuse_remember tunable controls how long those handles are cached client-side, and a mismatch after a Mover-triggered fileid change produces "stale handle" until the client refreshes.
Fix:
Force NFS v4.2 on the client mount (NFSv3 is far more prone to this than v4.x).
In 
/etc/fstab on the client, use 
_netdev,nofail,x-systemd.automount,x-systemd.idle-timeout=300 rather than a static mount — automount re-establishes the handle on next access instead of hanging on a dead one.
On the UnRAID side, the 
fuse_remember tunable (Settings → Global Share Settings) can be tuned if this happens frequently outside Mover events — but automount on the client side resolves it without touching server config.
2. Centerpoint Mounts Not Loading After Restart
Symptom: After a reboot, none of Centerpoint's NFS/CIFS mounts to Lusankya come back automatically; Docker containers depending on them fail to start.
Root cause: Docker services start before network mounts are ready at boot — a race condition, not a Lusankya-side fault.
Fix: 
sudo mount -a recovers immediately. To prevent recurrence, add 
_netdev to the relevant 
/etc/fstab lines so systemd waits for network availability before attempting the mount, and consider 
x-systemd.automount for more graceful boot-time handling.
3. Portainer 500 Error on Compose Redeploy After Changing NFS Path
Symptom: Updating a stack's NFS source path (new IP or mount point) in Portainer fails with a generic 
Request failed with error code 500.
Root cause: Docker refuses to redefine an existing named volume's 
driver_opts in place — the old volume definition with the stale NFS config is still registered.
Fix: Either 
docker volume rm the stale named volumes before redeploying, or — the more durable fix — replace named NFS volumes with direct bind mounts to an already-working host-level mount (
/mnt/data/...) per the established Centerpoint convention of direct bind mounts over named volumes with 
driver_opts.
4. Immich / Any App Expecting Sentinel Files on a Pre-Existing Library Path
Symptom: An app (e.g. Immich) crashes on startup when its data volume points at a pre-existing directory rather than an empty one — it's looking for first-run sentinel files (
.immich, etc.) that only get created during fresh initialization.
Fix: Manually create the expected subdirectories and sentinel files before first container start, with ownership matching the container's expected UID (commonly 1000).
5. UnRAID Array ≠ Traditional RAID 6
Clarification, not a bug: UnRAID's array uses per-disk XFS/BTRFS filesystems with a dedicated parity calculation layer — single parity drive here means tolerance for one failed data disk, recovered by rebuilding from the remaining disks + parity. This is functionally different from striped RAID 6 (which tolerates two failures by design). Don't assume RAID-6-equivalent fault tolerance when planning around this array; a second parity drive would be required to match that.
6. Cache-Only Shares Have No Mover Fallback
Symptom: None directly observed yet on this host, but worth flagging — 
appdata/
docker/
system are configured 
shareUseCache="only". If the 2-disk BTRFS cache pool fills or both SSDs fail, there's no array fallback; writes simply fail.
Mitigation: Monitor cache pool free space proactively; don't let it run consistently above ~85% utilized.
7. Boot Flash / USB Enclosures Don't Report Standard SMART
Symptom: Diagnostics SMART reports for the boot flash drive and any USB-bridged drive come back empty — easy to misread as a tool failure.
Root cause: Most USB-to-SATA bridges and flash media don't pass through SMART attributes the same way native SATA/SAS does. This is expected, not a fault — but it does mean those devices have no early-warning health signal, so physical inspection / replacement-on-schedule is the only mitigation for the boot flash itself.
Last Updated
2026-06-23