Synology NAS — NGAGED_CLOUD

Executive Summary

00 — Executive Summary

NAS Modernization Project — Phase 1: Discovery / As-Built Inventory (Digital Twin)

• Audit date: 2026-08-21
• Auditor host: Golden-Eye (Ubuntu 26.04, orchestrator/compute) → reached NAS read-only over SSH (Tailscale 100.90.167.88, port 54321)
• Audit mode: READ-ONLY. No files, containers, packages, users, tasks, settings, network config, or storage were modified. No secrets were read or recorded.
• Scope: Complete as-built inventory of the Synology NAS (NGAGED_CLOUD) in its current state, per the Phase 1 directive.

1. What Exists

Hardware / System

• Model: Synology DS220+ (2-bay), platform geminilake, x86_64
• CPU: Intel Celeron J4025 (2c/2t)
• RAM: 17 GB (12 GB swap: 2 GB /dev/md1 + 2× zram)
• DSM: 7.3.2-86009 (build 2026/06/18)
• Storage: 2× Synology HAT3300-4T (4 TB HDD) in SHR RAID-1 (md3/md2), LVM → single 3.5 TB btrfs volume1
• External: 1× 2 TB USB drive (usbshare1, ext4, 1.8 TB)
• Disk health: Both drives report normal SMART, 0 bad sectors, temp ~35°C. No failing-disk risk currently.

Data (volume1, 3.5T — 2.5T used, 1.1T free — 70%)

• vMix Recordings — 752 GB (church service recordings)
• homes — 823 GB (6 users; shaconann 321G, vidalstephen 202G, sadevidal 141G, rore-admin 114G)
• docker — 594 GB (primarily /volume1/docker/data/media = 534 GB of media: TV 282G, Anime-TV 155G, Movies 88G)
• projects — 11 GB, media share — 21 GB, Shared Documents — 3.8 GB, music — 422 MB
• USB drive: 760 GB used (Hyber Backup homes target + DSM_HOMES_BACKUP)

Containers (Docker 24.0.2 / Container Manager)

• 23 running, ~28 stopped/exited. Total 255 images (162 dangling), 23 volumes.
• Biggest running groups:
• media-platform (~21 containers): Jellyfin, Plex, Sonarr/Radarr/Prowlarr/Bazarr (+anime variants), Overseerr, Tautulli, Deemix, TubeArchivist (kids), qmutorrent/gluetun, rdt-client, FlareSolverr, Recyclarr, CleanUpArr
• platform: Traefik v3 (reverse proxy), cloudflared (tunnel 6f717a56, serves *.nsystems.live + *.vectorhost.net), cf-ddns
• monitoring: Gatus + Gotify
• homelab: vaultwarden (password manager), rustdesk (hbbs+hbbr), devshell
• hosted: scrapline2, crimson-haven, skybreaker-transform, ghostline-command

Packages (installed, Synology + community)

• Data-facing: Hyper Backup, Synology Drive, Synology Photos, Snapshot (share snapshots on all shares), Storage Analyzer, MailPlus-Server (+ MailClient, Contacts, Calendar), Chat, Audio Station, Codec Pack
• Container Manager 24.0.2, Git, Node.js 18/20, PHP 8.2, Python 2/3.9/3.10, Tailscale, Secure SignIn, QuickConnect, Active/ActiveInsight

2. Where the Important Data Lives

3. What Depends on What

• All public web services depend on: cloudflared (tunnel) → Traefik (routing/TLS) → container. Authelia (auth) is exited/down, so exposed services may lack SSO enforcement (verify).
• All media containers bind-mount /volume/data/media (the media library). Jellyfin & Plex bind /volume/docker/data/media-library.
• devshell container bind-mounts /var/run/docker.sock, /volume1, and .ssh — a powerful container.
• homes are served via Synology Drive/FileStation and are the subject of the only configured Hyper Backup job.

4. What Is Currently Protected

• One Hyper Backup job ("Local;1") → USB drive (usbshare1, target NGAGED_CLOUD_1), daily 03:00, enabled. But state=disabled in the schedule task, and the job's folder list is homes only. Last backup ~2025-11 (from target dir listing).
• btrfs snapshots available (share snapshot service on all shares) — only vMix Recordings has an actual snapshot (empty/1 file).
• Syncthing/ActiveInsight/SynologyDrive present.

5. What Is NOT Adequately Protected (top risks)

• CRITICAL — No verified restore. No Hyper Backup restore has been tested; job last ran ~Nov 2025. Cannot prove recoverability.
• CRITICAL — vMix Recordings (752 GB) has NO backup. Not in the Hyper Backup folder list; snapshots essentially empty. Single copy on a 2-bay RAID1 (protects against disk failure, not against deletion/corruption/fire).
• HIGH — Docker/container config is not centrally backed up. /volume1/docker (compose files + stack configs) are inside the docker share (594 GB, mostly data). Many containers have no reproduceable-config backup outside the host. 255 images and 23 anonymous volumes suggest a lot of un-tracked state.
• HIGH — No offsite/off-NAS backup. USB target sits on the same NAS. No cloud/offsite copy.
• MEDIUM/HIGH — Authelia (access control) is DOWN while services are internet-exposed via tunnel.
• MEDIUM — 4 service accounts + broad permissions (see §3): devshell has docker.sock + full /volume1 + ssh access.

6. What Appears Safe

• Disk health good (both drives normal, 0 bad sectors).
• NAS RAID1 mirror functional.
• DSM up-to-date on recent minor.
• Structured compose directories (/volume1/docker/platform, /stacks, /data).

7. What Concerns Me

• The only existing backup is a stale (~9-month-old) local USB backup of homes only. Not restore-tested, not offsite, excludes the two largest/high-value directories (media, vMix).
• 42 containers exited, many months old — configuration fragility if lost.
• 155 dangling images / anonymous volumes — storage + restore clutter.
• Exposed public ports on 0.0.0.0: Plex(32400), RustDesk(21115-21119), Jellyfin(8096), phpmyadmin(8086), freightline-dev(3001).
• Authelia (SSO) is down at a time when 28+ subdomains route through the tunnel.
• vMix Recordings is the single largest, un-backed-up, irreplaceable dataset.
• SMB shares are guest-writable (including homes and docker) — mitigated only by the firewall confining SMB to Tailscale/LAN.
• SSH password authentication is enabled — brute-force surface on the known port.

8. What Remains UNKNOWN / REQUIRES MANUAL REVIEW

• Hyper Backup restore state — never verified.
• Exact Hyper Backup retention policy (version counts) — GUI-only detail.
• Router port-forwarding state — the DSM firewall allows DSM web/Drive/SSH from any source, but whether the router actually forwards those ports (5000/5001/54321) to the NAS is external to the NAS.
• Syncthing/ActiveInsight/ActiveInsight exact job configs (GUI-only).
• Who "ryan" is (empty home; deny-ACL on docker, allow on vMix).
• Whether Authelia was deliberately decommissioned or just crashed.

> Resolved during the admin-access pass (no longer unknown): firewall rules (DSM INPUT_FIREWALL), SSHD hardening (password auth enabled), per-share ACLs (enumerated), SMB guest access (all shares guest-open but Tailscale-only at firewall), DSM config backup (exists at /volume1/@config_backup, 61 KB, dated 2026-08-16), storage pool layout (SHR RAID-1, LVM 3.63 T).

9. What I Recommend Next

• Proceed to PHASE 2 — BACKUP, INTEGRITY VERIFICATION & RESTORE TESTING (see below), with priorities:
• P0: Design + implement a verified, off-NAS backup for vMix Recordings (and homes) — using golden-eye/srv1388017/edge as target, not the same-NAS USB.
• P0: Restore-test the existing USB homes backup (pick one user's dir) to prove recoverability — do NOT trust it.
• P1: Back up all compose configs + env-file NAMES (/volume1/docker/platform, /stacks, /nsystems-monitoring, plus any stack-config/ under the media stack) to a safe, reproducibly-restorable location; enable restore-test.
• P1: Record container config to a reproducibility manifest (inventory already produced; next is a docker inspect dump).
• P2: Offsite (edge) copy of critical small datasets.
• During Phase 2 you may want to enable SSH sudo or share the DSM admin password with the agent for firewall/SSHD/task-reads — OR provide those directly to complete the UNKNOWN section.

Final Gate

This document and its 12 companions constitute the Phase-1 as-built inventory / digital twin. Discovery is complete and I am STOPPING here as directed.

I request authorization to proceed to PHASE 2 — BACKUP, INTEGRITY VERIFICATION & RESTORE TESTING, with the priorities above. No destructive operation has been performed or is authorized by this directive.

System Inventory

01 — System Inventory

NAS: NGAGED_CLOUD · Model: Synology DS220+ (2-bay) · Platform: geminilake · Arch: x86_64

Network Interfaces

• Gateway: 192.168.0.1
• DNS: 8.8.8.8 / 8.8.4.4
• Public/DDNS: ngaged.synology.me (Synology DDNS enabled)
• Tailscale: v1.58.2 package, node ngaged-cloud, IP 100.90.167.88

Storage Pools / RAID / Volumes

The NAS uses SHR (Synology Hybrid RAID) over a 2-disk RAID-1 arrangement with LVM on top.

• md arrays (all RAID-1, [2/2] [UU] healthy): md0, md1, md2, md3.
• LVM (confirmed via lvs/vgs/pvs): vg1 = 3.63 T across PVs /dev/md2 (1.81 T) + /dev/md3 (1.82 T); LV volume_1 = 3.63 T (thin volume syno_vg_reserved_area 12 M also present). SHR RAID-1 confirmed.
• Filesystem: btrfs with synoacl, space_cache=v2, subvol per shared folder under /volume1/@syno.
• Encryption: Volume/share encryption supported by DSM but volume is NOT encrypted (LVM thin volume not listed as encrypted; no encrypted-mount in /proc/mounts). support_share_encryption=yes, support_volume_encryption=yes, lock_encrypted_storage=no.
• SSD cache: None. No SSD cache md devices; support_m2_pool=no.

Physical Disks

SMART / health detail (from /var/log/diskprediction/data-2026-08-21.json):

• overview_status=normal, smart=normal, smart_test=normal, bad_sec_ct=0, below_remain_life_thr=0.
• No failing-disk indicators. Safe to run a large backup at present (both drives healthy).

Encryption Configuration

• Volume + share encryption supported but the primary volume is not encrypted (drive data at rest unencrypted).
• /usr/syno/etc/keymanager present (key management service) — no encrypted volume mounted.

Storage Utilization Flags

• Main volume at 70% (1.1 TB free). Large backup of docker/data/media (534 GB) onto same volume would not fit (534 GB > 1.1 TB free — but would still fit off-NAS).
• Health is good; no immediate backup-blocking hardware risk.

Discovery Commands (sanitized)

ssh -p 54321 msn0624c@100.90.167.88
cat /etc.defaults/VERSION
cat /proc/cpuinfo | grep -E "model name|cpu cores"
free -h; cat /proc/swaps
cat /proc/mdstat
lsblk; df -hT
cat /var/log/diskprediction/data-<date>.json | python3 -m json.tool   # disk health

Storage & Shares

02 — Storage & Shared Folders

Primary volume /volume1 (btrfs, 3.5 T, 70% used). Each DSM shared folder is a btrfs subvolume under /volume1/@syno. A USB drive mounts at /volumeUSB1/usbshare (ext4).

Shared Folder Table

USB drive /volumeUSB1/usbshare (1.8 TB, 760 G used, ext4)

• NGAGED_CLOUD_1/ — Hyper Backup "Local;1" target (homes backup)
• DSM_HOMES_BACKUP/ — separate manual homes archive (Nov 2025)
• Un-backed-up itself.

Major Storage Consumers

/volume1/docker/data/media — 534 GB

• TV — 282 GB
• Anime-TV — 155 GB
• Movies — 88 GB
• Instrumentals — 4.5 GB, Music — 2.5 GB
• (Empty: Stems, MusicVideos, Anime-Movies)

/volume1/docker/data/media-library — 22 GB

• YouTube-Kids — 22 GB (TubeArchivist)

/volume1/docker/data/torrents — 9.3 GB (active download area)

/volume1/homes — 823 GB (per user)

/volume1/vMix Recordings — 752 GB

• archive 136 GB, many 4–57 GB .mp4/.avi single-service files; #recycle 6.3 GB.

Notes

• Recycle bin is enabled on homes, docker, media, projects, vMix Recordings — deleted files remain reclaimable; good for safety, but inflates size (e.g. #recycle in homes 7.2G).
• media share is largely redundant with docker/data/media — candidates for consolidation during Phase 2+.
• Container data (docker/data/media) has NO backup — re-downloadable from *arr indexers (lowest priority to back up).
• vMix + homes are the irreplaceable, high-value data.

Snapshot Configuration

• Share-snapshot service enabled on all shares (/usr/syno/etc/sharesnap/sharesnap.conf lists every share).
• Actual snapshot: only /volume1/@sharesnap/vMix Recordings/ exists and it contains just a desktop.ini (effectively empty). No usable snapshots protect any share today.

Discovery Commands

sudo du -sh /volume1/<share>
du -sh /volume1/vMix\ Recordings/* | sort -rh | head
du -sh /volume1/homes/*/ | sort -rh | head
du -sh /volume1/docker/data/media/* | sort -rh | head
cat /usr/syno/etc/sharesnap/sharesnap.conf

Users, Groups & Permissions

03 — Users, Groups & Permissions

> NOTE: Full fine-grained ACLs and share-permission matrices require synoacltool/DSM admin (sudo). Values below are from /etc/passwd, /etc/group, and filesystem ownership (read-only). Fine-grained ACLs not dumped — UNKNOWN / REQUIRES MANUAL REVIEW for exact per-user ACLs.

Local Users (/etc/passwd, non-system)

> Other DSM users exist as home dirs: shaconann, vidalstephen, sadevidal, rore-admin, rore-worship, mskeete, ryan — visible via /volume1/homes/* even though not all are in passwd excerpt. ryan has an empty home (possible orphan).

Groups (abridged, non-system)

Permission Observations / Findings

• Two full administrators (admin + msn0624c). msn0624c is the automation/SSH account with admin + docker group.
• msn0624c is a very broad account: in administrators, in docker, and it owns /volume1/backups, /volume1/docker. This is the agent's operational account — broad but intentional.
• devshell container is exceptionally privileged: bind-mounts /var/run/docker.sock, the entire /volume1, and ~/.ssh. Anyone with that container's console = full NAS control.
• nfs/nobody sharing groups exist but NFS exports file was empty (NFS not obviously exporting).
• Service accounts for packages (postgres, mysql, mailplus, chat, etc.) — expected.
• ryan home exists but empty — possible orphaned/incomplete user.
• Fine-grained share ACLs are the DSM default rwxrwxrwx+ on most shares (the + indicates extended ACL). Exact per-user access NOT enumerated (needs sudo synoacltool).

Excessive / Unnecessary Privilege Flags (for Phase 2+ review — no changes made)

• devshell container: docker.sock + /volume1 + .ssh = effectively root-equivalent. Restrict or gate.
• msn0624c as full admin + docker — acceptable for the migration operator but should be least-privileged once migration is done.
• Confirm admin account is needed vs. a dedicated admin (defense-in-depth).

SMB / NFS (now read with admin access)

• SMB service installed (SMBService). Nearly all shares are configured guest ok=yes, valid users=nobody,nobody, writeable=yes — i.e. guest-accessible SMB on chat, docker, gitea-share, homes, MailPlus, media, music, projects, usbshare1, web, web_packages. This is a significant finding: SMB shares (including homes and docker) accept guest/write. However, the DSM firewall only allows SMB (445/139/137/138) from the Tailscale subnet (100.0.0.0/8), so LAN/Tailscale-only exposure is the mitigating factor.
• NFS: /etc/exports empty → NFS not exported.

Fine-Grained ACLs (now enumerated with admin access)

• user:ryan appears with a deny on docker and allow on vMix Recordings — inconsistent; review whether the ryan account is still needed.

Discovery Commands

grep -vE "nologin|/bin/false|daemon|/sbin/" /etc/passwd
cat /etc/group
ls -la /volume1/homes/
# Fine ACLs (need sudo):
sudo /usr/syno/sbin/synoacltool --enumerate <share>   # REQUIRES MANUAL (sudo)

Containers & Services

04 — Containers & Services (Docker / Container Manager)

Engine: Docker 24.0.2 (Container Manager 24.0.2-1606) · Compose v2.20.1 · storage driver btrfs · cgroup v1 · logging db

Totals: 23 running, ~28 exited/stopped · 255 images (162 dangling <none>) · 23 volumes · 16 networks

Running Containers

Platform Layer

Media Platform (/volume1/docker/stacks/media/media-platform/)

Torrent/VPN sub-stack (docker-compose.torrent.yml)

Platform/Homelab

Hosted apps (static nginx / game services)

Exited / Stopped Containers (~28) — notable

scrapline (old), aethrix-wordpress + -phpmyadmin (0.0.0.0:8086), wordpress + wordpress-db (mariadb:11), druglord-dev, freightline, freightline-dev (0.0.0.0:3001), starforge, agent-zero, reactive-resume(+db+printer), calcom(+db+redis), uptime-kuma, dsm-router, dozzle, dungeon-generator, template-myapp-1, buildx_buildkit_synobuilder0, plus Invidious tasks (disabled).

> These exited containers represent significant un-backupped configuration fragility and storage clutter (images/volumes).

Volumes (23)

• Named: devshell-vscode-server, scrapline2_scrapline2-data, starforge_starforge-data, uptime-kuma_uptime-kuma-data, nsystems-gatus-data, nsystems-gotify-data, druglord_druglord_node_modules, freightline_freightline_node_modules, scrapline-shell_*, aethrix_wordpress_*, skybreaker-drone-strike-node-modules, sessioncraft_*, buildx_buildkit_*.
• 11 anonymous hash volumes (hex IDs) — likely from docker compose on manually-run containers (rutorrent, flaresolverr, calcom, etc.). Unknown owner/content — flag.

Networks

proxy (shared Traefik ingress net), bridge, host, plus per-project: media-platform_ta-internal, media-platform_tak-internal, calcom_*, reactive-resume_*, rustdesk_default, ddns_default, docker_default, freightline_default, sessioncraft_*, wordpress_*, socket-proxy, nsystems-monitoring_default.

Published / Exposed Ports (risk-relevant)

• 0.0.0.0 (all interfaces): Plex 32400, RustDesk 21115-21119, Jellyfin 8096, phpmyadmin 8086, freightline-dev 3001
• LAN IP: rdt-client 192.168.0.164:6500
• Tailscale-only: gatus 100.90.167.88:8081, gotify 100.90.167.88:8082, devshell 127.0.0.1:2222
• Traefik/cloudflared expose the tunnel layer (28+ subdomains) — internal service ports mostly not directly public (good), but phpmyadmin/Jellyfin/Plex/RustDesk ARE directly exposed.

Bind-Mounts (data locality)

• Media stack reads /volume1/docker/data (media, torrents, media-library).
• devshell: /var/run/docker.sock, /volume1 (whole volume), .ssh.
• vaultwarden: /volume1/docker/stacks/homelab/vault/config (password vault — backup priority).
• scrapline2: named volume scrapline2_scrapline2-data.
• Traefik: docker.sock (ro) + acme.json + config.
• cloudflared: tunnel cred JSON (6f718a56-….json) + config.

Dependencies

• All web apps depend on cloudflared → traefik → app; authelia (auth) is exited/down.
• Media stack depends on /volume1/docker/data/media and (for torrent) gluetun VPN.
• RustDesk needs both hbbs+hbbr running for relay (both up).
• DDNS (cf-ddns) depends on a valid CF token + IP detection.

Provisional Classification

> These are provisional recommendations only — no migration performed in Phase 1.

Discovery Commands

/usr/local/bin/docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"
/usr/local/bin/docker inspect --format '{{ index .Config.Labels "com.docker.compose.project" }}' <name>
/usr/local/bin/docker inspect --format '{{range .Mounts}}{{.Type}}:{{.Source}}:{{.Destination}} {{end}}' <name>
/usr/local/bin/docker network ls; docker volume ls; docker images

Packages

05 — Synology Packages

Installed packages enumerated from /var/packages/. Grouped by role.

Data / Backup / Sync

Communications / Collaboration

Media

Runtime / App frameworks

Security / Auth / Access

Core DSM services (always present)

FileStation, StorageManager, SMBService, ScsiTarget (iSCSI/SAN), LogCenter, SynoFinder, SynologyApplicationService, SynoOnlinePack_v2, SupportService, AIConsole, StorageAnalyzer, TextEditor.

Package attention (per directive)

• Hyper Backup — present, 1 job (see 06). Critical to NAS operation.
• Snapshot Replication — snapshot capability present (share snap), but no meaningful snapshots exist.
• Synology Drive — active, homes-centric.
• Container Manager / Docker — core (see §04).
• Synology Photos — active, home photos.
• Active Backup — NOT installed (no "ActiveBackup" package seen). No client backup to NAS.
• VPN packages — none (only Tailscale).
• Media services — Audio Station, CodecPack, Photos; plus Docker media stack (Plex/Jellyfin/*arr).
• File-sharing — SMB, QuickConnect, Synology Drive, FileStation.

Classification summary (for later)

• Keep/Essential: Container Manager, Hyper Backup, Synology Drive, Photos, Storage Manager, FileStation, Tailscale, SecureSignIn, SMB.
• Review: Chat, MailPlus, Calendar, Contacts, HybridShare, USBCopy, Analjyics, AIConsole, ActiveInsight — enable/retire decision.
• Retire candidates (bloat): Python2, Perl (legacy), redundant runtimes.

Discovery Commands

ls /var/packages/
for p in $(ls /var/packages/); do cat /var/packages/$p/INFO 2>/dev/null | grep -E "^version=|^package=|^description=" ; done

Backup & Recovery

06 — Backup & Recovery Audit

> Critical finding: The only configured backup is stale (~9 months old), targets the same-NAS USB drive, covers homes only, and has never been restore-tested. BACKUP EXISTS ≠ RESTORE VERIFIED.

Backup Mechanisms

1. Hyper Backup — "Local;1" → USB

Evidence of staleness: USB NGAGED_CLOUD_1 last modified Nov 2025; synobkpinfo.db dated Nov 4 2025; DSM_HOMES_BACKUP Nov 2025. No recent Hyper Backup activity log.

2. Manual homes copy — DSM_HOMES_BACKUP (USB)

• Separate homes archive on USB (admin, mskeete, msn0624c, rore-admin, rore-worship, sadevidal, shaconann, vidalstephen).
• Dated 2025-11. Not automated, not verified.

3. Docker config backups (ad-hoc)

• /volume1/docker/backups/ — manual snapshots: media-platform-20251112, traefik-20260420, wordpress/, stacks-inactive-20260501, 20250929.
• /volume1/docker/_archive/traefik-old-platform/ — old Traefik config.
• /volume1/docker/_backups/pre-kvm1-alignment-20260420/.
• These are manual, not scheduled, not verified.

4. Container/app-level backups

• backups/romm (small), backups/docker-inventory.
• No automated container config backup detected (no dsmbackup-driven docker backup; state=disabled on backup task).

5. DSM configuration backup (auto)

• DSM maintains an automatic config backup at /volume1/@config_backup (61 KB, dated 2026-08-16) — this captures DSM settings/account/network config. Good, but it lives on the same volume/NAS, so it protects against config drift, not NAS loss. Include in any off-NAS backup.

Snapshot Protection

• Share-snapshot service enabled on all shares, but only vMix Recordings has a snapshot, and it is empty (single desktop.ini).
• Effectively zero snapshot protection today.

Protection Gaps (BACKUP EXISTS vs RESTORE VERIFIED)

Conclusion

• Only the homes directories are nominally backed up, and only to a USB drive on the same physical NAS (protects against disk failure within the box, but not against fire/theft/whole-NAS loss, and is 9 months stale and unverified).
• vMix Recordings, media config, projects, vaultwarden have no effective backup.
• No restore has ever been tested → cannot assume any backup is recoverable.

Phase-2 Priorities (proposal — not executed)

• P0 — Add an off-NAS backup for vMix Recordings + homes (target: golden-eye / srv1388017 VPS / edge; rsync/rclone/rsnapshot).
• P0 — Restore-test the existing USB homes backup (restore one user dir to scratch, verify hashes) before trusting it.
• P1 — Back up all compose configs + env-file names under /volume1/docker (platform/, stacks/, nsystems-monitoring/) to a restorable location.
• P1 — Export DSM config (Control Panel → config backup) + Hyper Backup task config.
• P2 — Offsite copy of vaultwarden + key small datasets.

Discovery Commands

cat /var/packages/HyperBackup/etc/synobackup.conf
ls -la /volumeUSB1/usbshare/NGAGED_CLOUD_1/
ls -la /volumeUSB1/usbshare/DSM_HOMES_BACKUP/
ls -la /volume1/backups/ /volume1/docker/backups/
cat /usr/syno/etc/sharesnap/sharesnap.conf

Network & Security

07 — Network & Security

> NOTE: Firewall rules, SSH daemon hardening, and reverse-proxy internal rules could not be read without privileged (sudo) access. Items marked UNKNOWN / REQUIRES MANUAL REVIEW need DSM admin or the sudo password.

IP & Interfaces

• Gateway: 192.168.0.1
• DNS: 8.8.8.8 / 8.8.4.4
• DDNS: Synology DDNS enabled, ngaged.synology.me (→ public IP). QuickConnect package present.
• Tailscale package v1.58.2 — remote admin path for the agent.

Public Exposure

• Cloudflare tunnel 6f717a56-… (cloudflared container) serves:
• *.nsystems.live + nsystems.live
• *.vectorhost.net + vectorhost.net
• Ingress → http://traefik:8080 → internal services (28+ subdomains)
• Directly exposed ports (0.0.0.0):
• Plex 32400
• RustDesk 21115-21119
• Jellyfin 8096
• phpmyadmin 8086 (container exited but port defined)
• freightline-dev 3001 (container exited)
• LAN: rdt-client 192.168.0.164:6500
• Tailscale-only: gatus 100.90.167.88:8081, gotify 100.90.167.88:8082
• Loopback: devshell 127.0.0.1:2222

Exposure flags (unnecessarily exposed?)

• phpmyadmin and freightline-dev are exposed on 0.0.0.0 even though their containers are exited — if they ever start they'd be internet-facing without auth. Flag.
• Jellyfin + Plex directly bound to 0.0.0.0 in addition to the tunnel — double exposure. Prefer tunnel-only (no direct bind).
• RustDesk on 0.0.0.0 (public relay) — intentional but should be confirmed desired.

SSH Configuration

• SSH access confirmed on port 54321 (custom) from golden-eye via key.
• From admin inspection: PubkeyAuthentication yes, PasswordAuthentication yes (password auth is enabled), ChallengeResponseAuthentication no. The sshd listener runs on the standard DSM config (/usr/bin/sshd -D [listener]).
• Finding: password auth is enabled for SSH. Combined with a high but known port, this is an exposure to brute-force. Recommend key-only auth + disable password auth during Phase 2 hardening.

Firewall (DSM firewall — now read with admin access)

• DSM's firewall is the INPUT_FIREWALL chain (96 total rules). Key allow rules:
• 1 ACCEPT lo
• 2 ACCEPT state RELATED,ESTABLISHED
• 3 RETURN tcp 0.0.0.0/0 -> dports 5000,5001,6690,54321,22 — DSM web (5000/5001), Synology Drive (6690), SSH (54321/22) are allowed from ANY source (internet-facing if the router forwards them).
• Rules 4–16 RETURN many services (NFS, SMB, FTP, media ports 8096/32400/6500, iSCSI, etc.) only from the Tailscale subnet 100.0.0.0/8 — so SMB, Jellyfin(8096), Plex(32400), rdt-client(6500) are Tailscale/LAN-only at the firewall even though Docker publishes them on 0.0.0.0 (the firewall blocks non-Tailscale access to those).
• Net effect: the DSM firewall confines most services to Tailscale; but DSM web + Drive + SSH are open to the internet if the router port-forwards them. The cloudflared tunnel plus exposed Plex/RustDesk ports remain the primary internet paths.

Firewall / NFS / SMB

• iptables INPUT: INPUT_FIREWALL chain (see above). Default action for unlisted traffic is effectively drop (only RETURN/ACCEPT rules exist; unreturned packets fall to the chain policy).
• NFS: /etc/exports empty → NFS not exported.
• SMB: nearly all shares guest ok=yes (see §03), but SMB port 445/139/137/138 is RETURN-allowed only from 100.0.0.0/8 → SMB is Tailscale/LAN-only. Mitigates the guest-open shares.

Reverse Proxy / TLS / Certificates

• Traefik v3 is the reverse proxy: entrypoints, ACME (Let's Encrypt), CF DNS-01 challenge using CF_DNS_API_TOKEN (value REDACTED/SECRET). Certs stored in acme.json (/volume1/docker/platform/traefik/acme/).
• Authelia (SSO/2FA for proxied apps) is exited/down → auth middleware dashboard-auth@file still referenced by Traefik dashboard; proxied services may lack enforced SSO while Authelia is down. Verify exposure.

Certificates

• /usr/syno/etc/certificate/ contains system, ReverseProxy, _archive certs (DSM + reverse proxy certs).

Security posture summary

Phase-2 recommendations (no change now)

• Remove/disable direct 0.0.0.0 binds for Jellyfin, Plex, phpmyadmin, freightline-dev (keep tunnel-only).
• Restore/replace Authelia OR confirm Cloudflare Access is enforced for exposed apps.
• Obtain SSH/firewall config via sudo to complete the UNKNOWN section.
• Consider binding RustDesk to Tailscale/LAN only if remote relay is not strictly required.

Discovery Commands

ip -br addr; ip route; cat /etc/resolv.conf
ss -tlnp    # (needs sudo on Synology)
# Firewall (needs sudo):
sudo iptables -L INPUT -n
sudo cat /etc/ssh/sshd_config
cat /volume1/docker/platform/cloudflared/config.yaml   # tunnel ingress map
grep -iE "entryPoints|providers|acme|endpoint|email" /volume1/docker/platform/traefik/traefik.yml

Scheduled Tasks

08 — Scheduled Tasks & Automation

Tasks enumerated from /etc/crontab, /usr/syno/etc/synoschedule.d/root/*.task, and the Docker scripts/ automation tree. All are read-only observations; nothing changed.

DSM Scheduled Tasks (/usr/syno/etc/synoschedule.d/root/)

> Key finding: the only backup task (id 10) is disabled, matching the stale USB backup. DSM auto-update + security scans are enabled. Docker-prune and Invidious tasks are disabled (so nothing is auto-pruning/overwriting today — safe).

/etc/crontab (system)

• MailPlus clean-junk, clamav update, and synoschedtask dispatcher entries (mirror tasks above). No destructive crons found.

Custom Docker automation (/volume1/docker/scripts/)

Automation helpers (present but not necessarily scheduled):

• nasops (14 KB bash CLI), stackctl.sh, stack-update.sh, stack-status.sh, compose-all-down.sh
• network-watchdog.sh, dnscheck.sh, portcheck.sh, tlscheck.sh, routercheck.sh, preflight.sh, validate-traefik-config.sh
• email-notify.sh/.py, fix-postgres-perms.sh, add-authelia-labels.py, lib.sh, boot-startup.sh
• /volume1/docker/update-all-stacks.sh (deprecated → points to stack-update.sh)
• /volume1/docker/dockerprune.sh — referenced by disabled task 7; not present at /volume1/docker/dockerprune.sh (only referenced). Verify in Phase 2.
• Makefile (/volume1/docker/Makefile) — deployment/ops targets (dns, preflight, tls, deploy, etc.) — not a cron, dev tooling.

What these do / depend on

• Auto-update depends on network + Synology update server.
• Security scan depends on DSM Security Advisor.
• MailPlus tasks depend on MailPlus server; relate to mail data.
• Backup task (disabled) would call dsmbackup --backup 1 → the USB Hyper Backup job.
• Prune task (disabled) — would delete Docker junk — currently not running (good; nothing being pruned now).

Anything capable of deleting/moving/syncing/overwriting?

• No enabled task does deletion today. The prune task and backup task are both disabled.
• Docker *arr/media stack performs its own moves/hardlinks but that is application behavior, not a scheduled destructive task.
• CleanUpArr / Recyclarr (running containers) manage *arr data (cleanup/config sync) — could delete media if misconfigured; note but they are healthy and user-configured.

Discovery Commands

cat /etc/crontab
for f in /usr/syno/etc/synoschedule.d/root/*.task; do echo "--$f--"; grep -E "^(id|name|type|state|action|cmd)=" "$f"; done
ls -la /volume1/docker/scripts/

Hermes Current State

09 — Hermes Current State (on NAS)

> Finding: There is no Hermes installation running on the NAS today. The mission brief said "Hermes currently exists on this NAS" — the evidence indicates it does not currently run there. What exists is a staging artifact (an empty Ollama data directory), not a live agent. Nothing was migrated.

Evidence

/volume1/docker/ollama/ — the only NAS artifact

• logs/ollama.log — logs from an Ollama process run 2026-07-02 … 2026-07-07 (last entry 2026-07-07T05:39). Shows an Ollama server was run on the NAS ~2 weeks in July, fetching model recommendations, then stopped.
• models/blobs/sha256-6528… — 4 KB blob (a tiny placeholder/stub, not a real model). Manifest for glm-5.2:cloud present (a cloud-sized pointer, no local weights).
• Conclusion: Someone staged a Cloud-Ollama mount (ollama dir) on the NAS, ran it briefly in early July, and it is no longer running and has no usable model weights. This is a leftover staging artifact, not an active Hermes.

Why it matters for the target architecture

• The target: Primary Hermes Orchestrator → Compute/Laptop (golden-eye), with an optional lightweight NAS Domain Agent (storage/DSM operator, read-only by default, least-privilege, reports to orchestrator).
• The NAS currently has no agent — clean slate. The /volume1/docker/ollama dir should be treated as review (likely remove or repurpose as a future NAS-agent data mount during migration — Phase 2+, not now).

Data needed to (re)build a NAS Domain Agent later (NOT migrated now)

• NAS SSH account (msn0624c) + key access (present).
• Read-only DSM API/tool access (synoshare, synouser, synostgpool, synosharesnapshot — via sudo).
• A lightweight container/runtime for the agent (Ollama dir could host it).
• Connection back to golden-eye orchestrator (Tailscale 100.90.167.88 ↔ 100.112.235.92).
• Least-privilege operator identity (dedicated NAS-agent user, not full admin).

Dependencies

• The future NAS agent depends on: golden-eye orchestrator (orchestration), Tailscale (connectivity), DSM API (management), and read-only access to shares/volumes/snapshots (storage ops). None of these are provisioned for Hermes yet.

Secrets

• No Hermes credentials exist on the NAS to document (none found). Any future agent credentials must be stored in SOPS/Vaultwarden/broker, never in the wiki or chat.

Recommendation

• Treat NAS Hermes as not present; plan the NAS Domain Agent from scratch in the target architecture. The /volume1/docker/ollama dir is a REVIEW item (likely retire/repurpose). Confirm with Stephen whether a prior partial Hermes/Ollama setup was abandoned.

Discovery Commands

which hermes; ls ~/.hermes
/usr/local/bin/docker ps -a --filter name=hermes
find /volume1 -maxdepth 3 -iname "*hermes*"
ls -la /volume1/docker/ollama; du -h /volume1/docker/ollama/models/blobs/*
cat /volume1/docker/ollama/logs/ollama.log | tail

Dependency Map

10 — Dependency Map

Map of relationships among NAS shares, containers, packages, users, backups, and external infrastructure. Focus: hidden dependencies that could break after a factory reset.

External machines / services

Share → Service dependencies

• docker/data/media ← all *arr, Jellyfin, Plex, rdt-client, bazarr, deemix (bind mounts)
• docker/data/media-library ← Jellyfin, Plex (read), TubeArchivist-kids (write)
• docker/data/torrents ← qBittorrent/rutorrent/cleanuparr
• docker/stacks/…/stack-config/* ← all media containers (config; reproduceability)
• docker/platform/{traefik,cloudflared,ddns} ← all public web services (proxy/tunnel/DNS)
• homes ← Synology Drive, FileStation, Photos, Hyper Backup source
• vMix Recordings ← only filesystem/DSM (no container depends; no backup)

Container → Container

• Traefik ↔ all web apps (routing)
• cloudflared → Traefik (tunnel → ingress)
• Authelia (exited) → proxied apps (auth middleware) — down = SSO gap
• qBittorrent/rutorrent → gluetun (VPN network namespace)
• rdt-client → *arr (download client via fake qBit API)
• Plex → tautulli (stats), overseerr → sonarr/radarr (requests)
• Prowlarr → sonarr/radarr/lidarr (indexer sync)
• TubeArchivist → tak-redis + tak-elasticsearch

Users / service accounts

• msn0624c (admin + docker) → all compose stacks, SSH, backups
• ngaged-cloud group (5 family users) → homes shares
• shaconann/vidalstephen/sadevidal/rore-admin → largest homes data
• package service accounts (postgres, mysql, mailplus, etc.)

Backup

• Hyper Backup job (homes → USB) depends on USB drive + job enabled (currently disabled).
• No container/app config backup → hidden fragility for any container.

Hidden-dependency risks after a factory reset

• All DNS/TLS breaks unless Cloudflare tunnel creds (6f717a56-….json) + CF DNS token are recovered. Stored in /volume1/docker/platform/{cloudflared,traefik} — inside the docker share.
• All compose stacks lose their config if /volume1/docker/stacks + /platform + /nsystems-monitoring are not backed up.
• Vaultwarden (password manager) — if /volume1/docker/stacks/homelab/vault/config is lost, all vault credentials are lost.
• Media library is re-downloadable but huge; vMix Recordings is irreplaceable and has no backup.
• ACL/permission model is DSM-native; recreated cleanly only if config exported.
• Package list (MailPlus, Photos, Drive) must be reinstalled + re-licensed.
• Docker images (255, 162 dangling) — re-pullable but config labels are in the exited containers.
• Anonymous volumes (11 hex volumes) — content/ownership unknown; may hold unreproducible data.

Dependencies of external on NAS

• Cloudflare tunnel depends on the NAS's cloudflared container staying up (if NAS down, 28+ subdomains go dark).
• RustDesk relay (hbbs/hbbr) — clients depend on NAS.
• Plex/Jellyfin clients depend on NAS media + streaming containers.
• Synology Drive/Photos clients depend on NAS.

Diagram (text)

Internet
   │ (DNS: nsystems.live / vectorhost.net)
   ▼
Cloudflare Tunnel (6f717a56) ──► cloudflared (NAS)
                                     │
                                     ▼
                               Traefik (:80/443)
                                 │  ├─(CF DNS-01 cert)
                                 ▼
        Authelia [DOWN] ── SSO gate (gap)
                                 │
      ┌──────────────┬───────────┴──────┬───────────────┐
      ▼              ▼                  ▼               ▼
   Jellyfin        *arr stack        static apps      monitoring
   Plex            Sonarr/Radarr/    (scrapline2,      (gatus/gotify)
                   Prowlarr/Bazarr   crimson, ...)
      │              │                │
      ▼              ▼                ▼
   /docker/data/   /docker/data/   /volume1 (docker.sock
   media-library   media           via devshell)

Risk Register

11 — Risk Register

Prioritized risks with Evidence → Impact → Remediation (not executed in Phase 1).

CRITICAL

R1. No verified restore — backup may be unrecoverable

• Evidence: Hyper Backup job "Local;1" is disabled (task id 10 state=disabled); USB target NGAGED_CLOUD_1 + synobkpinfo.db last modified 2025-11 (~9 months stale); no restore test on record.
• Impact: Even the homes data cannot be guaranteed recoverable. A perceived backup may be a false sense of security.
• Remediation: Phase 2 P0 — restore-test the USB backup (restore a user dir to scratch, verify hashes) before proceeding; do not rely on it.

R2. vMix Recordings (752 GB) has NO backup

• Evidence: Not in Hyper Backup folder list (backup_folders = homes only); snapshot empty (desktop.ini only); largest single dataset (752 GB, mostly >4 GB church service videos).
• Impact: Total loss of irreplaceable recordings on any deletion/corruption/fire. Highest-value single dataset.
• Remediation: Phase 2 P0 — off-NAS backup (rsync/rclone/rsnapshot to golden-eye/srv1388017/edge) + enable snapshot scheduling + periodic integrity check.

R3. Only backup targets the SAME NAS (no offsite)

• Evidence: Hyper Backup trans_type=local → USB usbshare1 physically attached to the NAS; no cloud/offsite job.
• Impact: Whole-NAS loss (theft, fire, power surge) destroys data AND backup together.
• Remediation: Add off-NAS/offsite backup (rclone to object storage, edge VPS, or a second site).

HIGH

R4. Docker/container config not reproducibly backed up

• Evidence: Compose files + stack-config live inside /volume1/docker (no automated backup; manual snapshots stale). 255 images / 162 dangling / 11 anonymous volumes.
• Impact: Factory reset or volume loss = all stack configs gone; containers cannot be rebuilt from memory.
• Remediation: Back up /volume1/docker/{platform,stacks,nsystems-monitoring} + .env/env-file names to a restorable location; dump docker inspect for every container; snapshot named volumes.

R5. Vaultwarden (password manager) data not backed up

• Evidence: vaultwarden config at /volume1/docker/stacks/homelab/vault/config; inside docker share; no backup job.
• Impact: Loss of the password vault = total credential loss.
• Remediation: Phase 2 P1 — include vaultwarden config/ in backup (ideally offsite) + enable Bitwarden built-in backups if available.

R6. Authelia (SSO/access control) is DOWN while services are internet-exposed

• Evidence: authelia container exited; compose labels reference authelia.nsystems.live; tunnel serves 28+ subdomains.
• Impact: Exposed web apps may lack enforced SSO/2FA; dashboard-auth middleware may fail open.
• Remediation: Restore or replace Authelia, or enforce Cloudflare Access on tunnel routes; confirm every exposed route requires auth.

R7. Container config / anonymous volumes unowned

• Evidence: 11 anonymous hex volumes; several exited containers (calcom, reactive-resume, etc.) with DB volumes; no owner map.
• Impact: Unknown data, can't reproduce; storage + restore clutter; potential orphaned DBs.
• Remediation: Map each anonymous volume to its container in Phase 2; decide keep/retire; back up any needed.

MEDIUM

R8. Internet-exposed services on 0.0.0.0

• Evidence: Plex 32400, RustDesk 21115-21119, Jellyfin 8096, phpmyadmin 8086, freightline-dev 3001 all bound to 0.0.0.0.
• Impact: Direct internet exposure beyond the tunnel; phpmyadmin/freightline are exited but would expose if started.
• Remediation: Bind to 127.0.0.1/LAN/Tailscale or keep tunnel-only; disable the exited exposure.

R9. Stale/unsupported runtimes & old containers

• Evidence: Python2, Perl, old wordpress:6.8.3/mariadb:11, agent-zero, calcom, uptime-kuma, etc. exited; 162 dangling images.
• Impact: Attack surface (unpatched images), storage bloat, restore clutter.
• Remediation: Retire/archive stopped containers + prune dangling images (with approval).

R10. Undocumented/partial Docker prune task + Invidious tasks

• Evidence: tasks 7/8/9 (dockerprune.sh, Invidious stop/start) exist but disabled.
• Impact: If enabled accidentally, could delete Docker data (prune) or toggle a container.
• Remediation: Document; keep disabled; remove stale task 8/9 if Invidious not in use.

LOW

R11. Broad operator permissions

• Evidence: msn0624c = full admin + docker; devshell container mounts docker.sock + /volume1 + .ssh.
• Impact: If compromised, full NAS control.
• Remediation: Create least-privilege operator for migration; restrict/remove devshell docker.sock & /volume1.

R12. Data with unclear ownership

• Evidence: ryan home empty; legacy media share redundant with docker/data/media; anonymous volumes.
• Impact: Can't confidently archive/retire.
• Remediation: Confirm ownership in Phase 2 before any removal.

R13. Single copies of important data

• Evidence: vMix (752G) & vaultwarden & compose configs have single copies.
• Impact: any local failure = loss.
• Remediation: (covered by R2/R4/R5 backup actions)

R14. SSH/firewall hardening unverified

• Evidence: sshd_config + iptables not readable without sudo; SSH on custom port 54321.
• Impact: unknown whether root login/password auth permitted.
• Remediation: Obtain sudo/DSM admin, review SSHD + firewall, enforce key-only, restrict root.

> Admin-pass update: This is now RESOLVED (firewall + SSHD + ACLs + SMB enumerated). Two new findings from the privileged pass:

R15 (MEDIUM→HIGH). SMB shares are guest-writable

• Evidence: smb.conf shows nearly all shares (homes, docker, media, projects, music, web, chat, MailPlus, usbshare1, etc.) with guest ok=yes, valid users=nobody,nobody, writeable=yes.
• Impact: Any LAN/Tailscale client can access these shares without authentication, including homes (personal data) and docker (container configs/media). Mitigated only by the DSM firewall confining SMB to 100.0.0.0/8 (Tailscale) — so exposure is Tailnet/LAN, not internet.
• Remediation: Restrict SMB shares to named users/groups (remove guest ok), especially homes and docker. Enable SMB auth. During Phase 2, audit and lock down each share.

R (MEDIUM). SSH password authentication enabled

• Evidence: sshd_config has PasswordAuthentication yes.
• Impact: Brute-force risk on the known SSH port (54321) for any account with password auth.
• Remediation: Disable password auth (key-only), enforce for all users; ideally restrict SSH to Tailscale/LAN.

Risk summary counts

• CRITICAL: 3 (no-verified-restore, vMix no backup, no offsite)
• HIGH: 4 (docker config not reproducible, vault not backed up, authelia down + exposure, SMB guest-writable)
• MEDIUM: 4 (0.0.0.0 exposure, stale/unsupported images, undocumented disabled automation, SSH password auth)
• LOW: 4 (broad perms, unclear ownership, single copies, unverified hardening)

> No remediation performed in Phase 1. All items pending Phase 2 authorization.

Keep / Move / Retire / Replace

12 — Keep / Move / Retire / Replace (Migration Classification)

Intended architecture principle:

• Synology NAS = storage, snapshots, backup, replication, and carefully selected data-centric services.
• Compute/Laptop (golden-eye) = Hermes orchestration, AI/agent workloads, automation, dev tools, monitoring, databases, compute-heavy services.
• VPS/Edge = services needing public internet accessibility.
• NAS Domain Agent = lightweight, read-only-by-default, least-privilege storage/DSM operator reporting to the primary orchestrator.

Provisional classification for each significant workload. No migration performed in Phase 1.

Storage / Shares

Containers

Packages

Hermes / Agent

Summary of target placement

• On NAS: storage (all shares), media stack, torrent/VPN, Traefik/cloudflared/ddns (or edge), Synology data packages.
• On Compute (golden-eye): Hermes orchestrator, monitoring (gatus/gotify), dev tooling, static/hosted apps, project files.
• On VPS/Edge: RustDesk relay, any truly-public services, offsite backup target.
• NAS Domain Agent: lightweight read-only DSM/storage operator reporting to orchestrator (Phase 2+ design).

> All classifications are provisional recommendations. No migration or removal performed in Phase 1. Decision required from Stephen before Phase 2 moves any workload.