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

Notes / Gotchas

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

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

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

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

Mover

Notes / Gotchas

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:

Notes / Gotchas

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:

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