Synology Maintenance Handoff

Last updated: 2026-06-22

Use this file as the first stop when starting a new Codex chat or recovering context after an update.

Cross-system future recommendations and postponed changes are tracked in:

FUTURE_CHANGES.md

Cross-system automation, retention, and incident-summary rules are tracked in:

AUTOMATION_PLAN.md
RETENTION_POLICY.md
INCIDENT_REGISTER.md

Connection

Synology host: 10.0.0.119
Maintenance user: codex-maint
SSH key on this PC: C:\Users\ravic\.ssh\codex-synology\codex-maint-synology
Project root on this PC: C:\Users\ravic\OneDrive\GitHub\VHNIC

Do not print private keys, API keys, tokens, or full unredacted config values into chat or project notes.

Operating Rules

Non-destructive work is allowed: inspect, capture, compare, copy, edit approved config, restart approved containers, and document findings.
Do not delete, prune, remove, wipe, reformat, or repair anything unless the user explicitly approves the specific target.
Do not run btrfs check --repair on the live Synology filesystem.
Prefer read-only diagnostics first, then discuss remediation before making risky changes.
Keep durable findings in project docs so future chats can recover quickly.
Summarize incidents in INCIDENT_REGISTER.md and incidents/<date-topic>/SUMMARY.md before deleting raw logs or command output.
Treat /volume1/data/media/personal as off-limits for all modification workflows. It contains irreplaceable family videos. Only perform read-only inventory or backup planning if explicitly requested.

2026-06-01 Security Review

Report:

security/breach-assessment-20260601.md

Latest privileged audit:

synology/security/audits/20260601-190945/synology-security-audit.txt

Summary:

No clear evidence of compromise was found in the reviewed Synology, Docker,

UniFi, Pi-hole, and Google Cloud DNS data.

The privileged Synology audit ran as root and captured auth-related log

excerpts, sudo activity, Docker state/events, listening ports,

shell-capable users, privileged groups, SSH daemon settings, and

scheduler/cron files.

Synology SSH currently has PasswordAuthentication yes; consider disabling

password auth later after confirming key-based access and emergency admin

access.

Direct qBittorrent and direct Seerr/Overseerr public forwards should remain

disabled.

Remaining public exposure paths to review periodically: Plex and Caddy

HTTP/HTTPS reverse proxy. Plex Test removal and Minecraft public-forward

disablement were approved/documented on 2026-06-13; verify live UniFi state

before claiming those rules are gone.

Current Storage Situation

Detailed source of truth: synology/storage/CURRENT_STATE.md

Active rebuild/evacuation plan:

synology/storage/VOLUME1_REBUILD_MIGRATION_PLAN.md

Volume 1 is the large HDD media/data pool.
Main media path: /volume1/data/media
RAID device observed as md2, online as [UUUUUUUU].
Volume 2 is an SSD mirror used for important app/container data.
Plex appdata: /volume2/VM Storage/plex
Tdarr server/config/cache/log path: /volume2/VM Storage/docker/tdarr
Former SSD cache was removed and should not be reused for production.
Volume 4 is the temporary DX1222 RAID 6/Btrfs landing zone created on

2026-06-16 for Volume 1 evacuation.

Volume name: temp_media
Mount: /volume4
Mapper: /dev/mapper/cachedev_3
RAID device: md5
Migration root: /volume4/migration-from-volume1
Intended role: temporary copy target before Volume 1 is removed/recreated.
Volume5 SSD role is now documented as the active/staged root

/volume2/docker-v5 for most non-Plex container appdata/projects/secrets.

Plex and Tautulli appdata now run from Volume3 under /volume3/docker.

Follow-up: verify DSM's displayed volume name/number versus the

/volume2/docker-v5 mount path before removing old Volume2/VM Storage

references.

Volume 1 Btrfs data scrub is finished, and the post-scrub md2 RAID

repair/resync is also finished as of the 2026-05-22 post-resync baseline.

md2 is active RAID6, clean, non-degraded, with all eight members present:

[UUUUUUUU].

Volume 1 still has known Btrfs scrub/device error history:
Scrubbed: 48.21TiB
Errors: 35,311
Error detail: csum=35311
Corrected: 0
Uncorrectable: 35,311
Device stats remain at read_io_errs=336, corruption_errs=35311.
Active Insight reported `[Critical] Btrfs checksum inconsistency was

detected - Vick-NAS at 2026-05-29 02:28 EDT`.

Fresh read-only snapshot: synology/system/privileged-health/20260529-081538
The snapshot still shows the same scrub baseline (35,311 csum errors)

and md2 remains active/non-degraded with all eight members present.

Live kernel logs still show the same known corrupt Btrfs logical block

56885910093824 in root/subvolume 262, so treat the alert as persistent

Btrfs metadata corruption until Synology support or a rebuild/recreate plan

says otherwise.

Active Volume 1 HDD SMART reports in the 2026-05-22 baseline were clean:

SMART passed, no reallocated sectors, no pending sectors, no SMART error log

entries.

Known scrub-damaged file identified, removed, and replaced by user:

/volume1/data/media/reality/Below Deck Mediterranean/Season 9/Below Deck Mediterranean - S09E11 - From Cloud Nine to Flatline.mkv

Post-resync follow-up:

Remember the known damaged file was already replaced; counters will not

decrease automatically.

Try a privileged read-only path lookup for the corrupt Btrfs logical block

56885910093824 before deciding whether more media files need replacement.

This was run on 2026-05-22 and did not resolve to a live file path:

ERROR: logical ino ioctl: No such file or directory.

If DSM/Active Insight continues reporting Btrfs/filesystem corruption after

the known file replacement, consider a Synology support case.

Avoid btrfs check --repair.

2026-05-30 DSM Hang Follow-Up

Incident docs:

incidents/2026-05-30-synology-service-hang-volume3-restore/SUMMARY.md
incidents/2026-05-30-synology-service-hang-volume3-restore/DEEP_DIVE_FINDINGS.md

Key current interpretation:

DSM nginx accepted requests but timed out waiting for Synology's synoscgi

backend from 2026-05-29 21:56 through at least 2026-05-30 00:39.

The same known Volume 1 Btrfs metadata block, 56885910093824, was logging

errors before, during, and after that window.

The deep-dive did not find a clean md RAID degradation, OOM kill, kernel

panic, or SATA reset storm as the direct trigger.

A Radarr container core dump happened at 2026-05-29 21:20; several Synology

services dumped core after the forced reboot. These are preserved as

timeline markers but are not proven root cause.

Current risk should be treated as moderate/non-zero. The long-term risk is

the unresolved Btrfs metadata corruption, not the restored Volume 3 files.

2026-06-14 Plex Buffering / Volume 1 Storage Follow-Up

Support-case bundle:

synology/support-cases/20260614-volume1-btrfs-md2/

Current interpretation:

Multiple Plex users reported buffering on 2026-06-14 while Plex API/timeline

requests stayed responsive and CPU/GPU were not saturated.

The strongest evidence points to intermittent Volume 1 storage stalls, not a

generic Plex tuning issue.

Kernel logs repeated Btrfs metadata errors for logical block

56885910093824, the same block tracked in earlier Volume 1 investigations.

md2 logged self-heal retries and some give up messages while DSM still

reported the array active with all eight members present.

A read-only Btrfs diagnostic and host I/O capture were saved under the

support-case evidence folder; no repair, delete, restart, scrub, balance, or

destructive command was run for the capture.

2026-06-16/17 Volume 1 Evacuation To DX1222 Volume 4

Detailed plan:

synology/storage/VOLUME1_REBUILD_MIGRATION_PLAN.md

Support update:

Synology Support reviewed DS3622xs+ debug logs and reported thousands of bit

flip errors dating back to March 2026.

They identified unsupported Crucial CT16G4SFRA266.C8FF RAM as a likely

contributor.

Their recommended direction is to back up accessible data, remove the

unsupported RAM, remove/recreate the affected Volume 1, and restore data.

The unsupported RAM was removed after the NAS was powered down.
Do not attempt live Btrfs repair. Continue avoiding btrfs check --repair.

Current migration shape:

Source: /volume1
Destination root: /volume4/migration-from-volume1
Copy method: local Synology rsync, not Windows-mediated SMB copy.
Critical set has been copied:
/volume1/data/media/personal
/volume1/data/media/photos
/volume1/data/work
Detached queue launched:
Profile: InitialRemainder
Sets: AppData, Downloads, UserHomes, Storage, MediaAll
Run log:

/volume4/migration-from-volume1/_runs/20260616-224332-queue-InitialRemainder.out

Most recent pasted status around 2026-06-17 00:34 EDT showed active copy

item /volume1/docker, about 16.32G processed, 3.44MB/s, and roughly

0.16G remaining according to rsync. This is expected to be slow because

Docker appdata contains many small and actively changing files.

DX1222 Volume 4 creation produced immediate observability alerts for md5

resync, storage timeout/reset language, and synostgd-space segfaults.

Follow-up a little over 12 hours later showed the warning counts did not keep

climbing:

core dump events peaked at 6 and returned to 0,
storage timeout/reset/I/O-error matches peaked at 56 and returned to 0,
unknown Btrfs block matches stayed at 0,
md5 remained [UUUUUUUU] with failed disks 0,
only muted info alerts remained for md5 resync and sustained disk busy.

Expect similar creation-time alert noise when Volume 1 is recreated; treat it

as acceptable only if the counts flatten and age out instead of repeating.

Status helper:

powershell -NoProfile -ExecutionPolicy Bypass -File .\tools\synology\Get-Volume1ToVolume4MigrationStatus.ps1

The status helper now includes destination sizes by default with a short timeout.

If it prints a Terminated ( du ... ) line after partial size output, that is

the optional size scan being capped, not the migration failing.

Next posture:

Let the detached queue continue.
After it completes, run TrueUp.
Before the last pass, stop write-heavy services, then run FinalTrueUp.
Validate the landing copy before deleting/recreating Volume 1.
Restore the same logical folder shape back to the rebuilt Volume 1.
Volume 4 also has a separate DSM-managed staging share for future local

backup/config/restore use:

Share: vhnic-backups
Path: /volume4/vhnic-backups
Windows path: \\10.0.0.119\vhnic-backups
Created empty on 2026-06-20 with

tools/synology/Stage-Volume4BackupLayout.ps1.

This is not the raw evacuation copy and should not be confused with

/volume4/migration-from-volume1.

Docker And Appdata

Detailed source of truth:

synology/docker/README.md
synology/docker/BACKUP_STRATEGY.md
synology/docker/BAZARR_PLAN.md

Current appdata placement is mixed during the Volume 1 rebuild/migration work:

Plex/Tautulli: /volume3/docker
Most non-Plex active or staged container appdata/projects/secrets:

/volume2/docker-v5

Volume5 backup copy:

/volume4/migration-from-volume1/volume5-backups/docker-v5

Remaining legacy/rollback roots may still exist under /volume1/docker,

/volume1/homebridge, and /volume2/VM Storage.

Do not delete old roots until the current service placement and rollback

posture are validated.

Historical caution: on 2026-05-16, the media-project stack (sonarr,

radarr, lidarr, prowlarr, recyclarr) was cut over to Volume 2 SSD

appdata, then later fell back to Volume 1 after Plex stalls and slow/spinning

Arr access made the migration a suspect variable. The root cause was not proven

to be Volume 2, but the rollback reduced risk and kept services on the known

working layout. See synology/docker/MIGRATION-20260516-media-project.md.

Container project YAML is mirrored locally under:

synology/docker/projects

Refresh from Synology:

powershell -NoProfile -ExecutionPolicy Bypass -File .\synology\docker\Sync-FromSynology.ps1

Upload project YAML back to Synology only when intentionally applying a change:

powershell -NoProfile -ExecutionPolicy Bypass -File .\synology\docker\Sync-ToSynology.ps1 -ProjectName <project> -Apply

The upload helper now refuses to upload any project folder containing a local

.secrets directory unless -AllowSecretsUpload is explicitly supplied. Use

project-specific secret install helpers instead of copying .secrets folders

into /volume1/docker/projects.

Current container security/helper review:

synology/docker/CONTAINER_SECURITY_OPERABILITY_REVIEW.md

Current Container Notes

Seerr / Former Overseerr

Detailed source of truth: synology/docker/OVERSEERR_REVIEW.md

Seerr replaced Overseerr on 2026-05-24 after the app reported that Overseerr

is superseded by Seerr.

Active container:
seerr
image ghcr.io/seerr-team/seerr:latest
appdata /volume1/docker/seerr
host port 5055
restart policy unless-stopped
Seerr log confirmed:

Overseerr to Seerr migration completed successfully.

Legacy container:
overseerr
stopped,
restart policy changed from always to no,
stale appdata removed on 2026-06-01 after Seerr was confirmed active.
Clean migration backup

/volume1/docker/overseerr.codex-before-seerr-20260524-232436 was also

removed on 2026-06-01 during approved stale Docker cleanup.

Runtime now runs as service seerr inside the media-project Container

Manager/Docker Compose project:

/volume1/docker/projects/arrs-compose/compose.yaml.

Bazarr

Bazarr was added to media-project on 2026-06-03 as a conservative subtitle

pilot and retired on 2026-06-14 after continuing log noise and no clear value

from the workflow.

The tracked media-project compose no longer includes bazarr.
Homepage, Prometheus service probes, expected-container alerts, and web UI

autoheal should no longer expect Bazarr.

Keep old Bazarr helper scripts and runbooks as historical reference only; do

not recreate the container unless the user explicitly reopens subtitle

automation.

Retirement helper:

powershell -NoProfile -ExecutionPolicy Bypass -File .\synology\docker\projects\arrs-compose\Remove-BazarrFromMediaProject.ps1 -Apply

Detailed source of truth:

synology/docker/BAZARR_PLAN.md
synology/docker/Bazarr-Runbook.md
synology/docker/Set-BazarrSafeSubtitleProviders.ps1

Audiobook Stack

Added on 2026-06-04 as a separate audiobook Container Manager project.

ReadAIrr was retired from the stack on 2026-06-14 after repeated expensive

rescans and bad imports.

Compose source:

synology/docker/projects/audiobook-compose

Synology project path:

/volume1/docker/projects/audiobook-compose

Services:
audiobookshelf: stable audiobook library/player, host URL

http://10.0.0.119:13378.

Runtime/appdata:
Audiobookshelf config/metadata: /volume3/docker/audiobookshelf.
Current audiobook files: /volume1/data/media/audiobooks/books.
Audiobookshelf library:
Container library path is /audiobooks/books.
The initial scan on 2026-06-04 added items from the original flat .m4b

folder.

The audiobook files were then physically reorganized into author/title and

author/series folders. Audiobookshelf stale missing records were cleaned

through API helpers only; no media files were deleted.

First-pass Audiobookshelf series/collections were created, then corrected

for known duplicate/stale parent records. Latest documented post-cleanup

state is 194 active items, 0 missing, 0 invalid, and 21 series.

Guardrails:
Audiobookshelf may be exposed through Caddy as

https://audiobooks.ravick5.com for ShelfPlayer/app access after DNS and

proxy deployment are complete.

Do not assist with DRM removal or Audible bypass workflows.
Do not delete audiobook media or appdata without explicit path-level

approval.

Reading Stack

Prepared on 2026-06-05 as a separate internal production-style Container

Manager project named reading.

Compose source:

synology/docker/projects/reading-compose

Synology project path:

/volume1/docker/projects/reading-compose

Services:
kavita: ebook/comic/manhwa reader, host URL

http://10.0.0.119:7578, image jvmilazz0/kavita:latest.

mylar3: comic/manhwa management candidate, host URL

http://10.0.0.119:8091, image lscr.io/linuxserver/mylar3:latest.

Runtime/appdata:
Kavita config: /volume3/docker/kavita/config.
Mylar3 config: /volume3/docker/mylar3/config.
Media roots:
/volume1/data/media/books
/volume1/data/media/books/comics
/volume1/data/media/books/manhwa
Kavita mounts the existing book media root read-only as /books; this is

intentional because Kavita should read and serve, not

mutate, the source library.

Mylar3 mounts /comics and /manhwa writable for possible future library

management. Do not configure Mylar3 indexers, download clients, or automatic

acquisition until the user explicitly approves that workflow.

Homepage has tracked cards for Kavita and Mylar3, and Prometheus has

Blackbox HTTP probes for both.

Keep Kavita and Mylar3 internal-only. Any external access should be a

separate Caddy/MFA/SSO discussion, not an automatic follow-on.

Lidarr

Lidarr runs inside media-project with appdata at /volume1/docker/lidarr

and media mounted at /data.

On 2026-06-04, Lidarr track renaming was enabled and configured for the

preferred library shape:

artist folder: {Artist Name}
standard tracks:

{Album Title} ({Release Year})/{Artist Name} - {Album Title} - {track:00} - {Track Title}

multi-disc tracks:

{Album Title} ({Release Year})/{Artist Name} - {Album Title} - {medium:00}-{track:00} - {Track Title}

A full-library rename was triggered through Lidarr API as one RenameFiles

command per artist. The first attempted all-files command failed because

Lidarr received artistId=0; subsequent artist-scoped commands were the

intended run. If checking later, inspect Lidarr command history/logs for

RenameTrackFileService.

Lidarr DB integrity checked ok before the rename, but repeated transient

SQLite database is locked messages were observed under load on 2026-06-04.

Treat recurring lock messages during quiet periods as worth follow-up.

The older standalone seerr-compose project source is retained as historical

migration documentation, but it is no longer the active runtime project.

Anime request routing was fixed on 2026-05-21:
animeSeriesType = standard
activeProfileName = Anime - Dubbed 1080p
activeAnimeProfileName = Anime - Dubbed 1080p
directory remains /data/media/anime
Safety copy on Synology:

/volume1/docker/overseerr/settings.json.codex-before-anime-fix-20260521

Do not expose Seerr directly to the internet as-is.
Stage 1 reverse proxy is prepared as a Caddy Docker project:

synology/docker/projects/reverse-proxy-compose.

Remote project files are at:

/volume1/docker/projects/reverse-proxy-compose.

Intended runtime appdata is:

/volume3/docker/reverse-proxy.

Runtime appdata folder was prepared on Volume 3.
DSM owns host ports 80/443; Caddy is configured for host ports 8088/8443.
Caddy is live and serves the Seerr request UI at:
overseerr.ravick5.com
seerr.ravick5.com
requests.ravick5.com
UniFi maps public 80 -> 10.0.0.119:8088 and public

443 -> 10.0.0.119:8443.

Caddy reaches Seerr by Docker DNS name seerr:5055.
Seerr now has applicationUrl=https://overseerr.ravick5.com and

trustProxy=true; csrfProtection remains disabled until public login and

request testing succeeds.

Seerr cacheImages remains false because the app warns this can consume

significant disk. To address browser mixed-content warnings without enabling

image caching, Caddy now sends:

Content-Security-Policy: upgrade-insecure-requests; block-all-mixed-content.

Before inviting users, test login/request flow through the public hostname,

test one normal request and one anime request, then enable csrfProtection

after testing succeeds.

NZBHydra2

Detailed source of truth:

synology/docker/BACKUP_STRATEGY.md
synology/docker/VPN_QBIT_NZBHYDRA_REVIEW.md

NZBHydra2 backup retention was reduced on 2026-05-21:

backupFolder: "backup"
backupEveryXDays: 7
backupBeforeUpdate: true
deleteBackupsAfterWeeks: 2

Safety copy on Synology:

/volume1/docker/nzbhydra2/nzbhydra.yml.codex-before-retention-20260521

On 2026-05-27, NZBHydra2 was moved from an unlabeled standalone container

named linuxserver-nzbhydra2-1 into the media-project Compose project as

service/container nzbhydra2. The appdata path did not change:

/volume1/docker/nzbhydra2

The host port remains 5076.

Existing backup ZIP files were not deleted by Codex.

NZBGet

On 2026-05-21, two NZBGet UI errors were fixed by correcting paths in

/volume1/docker/nzbget/nzbget.conf:

CertStore=/config/cacert.pem
SevenZipCmd=/config/app/nzbget/7zz
CertCheck=yes

Safety copy on Synology:

/volume1/docker/nzbget/nzbget.conf.codex-before-path-fix-20260521-173139
/volume1/docker/nzbget/nzbget.conf.codex-before-certcheck-yes-20260521-173437

The nzbget container was restarted after the change. DNS resolution from

inside the container was verified afterward. Certificate checking was then

enabled and the container restarted again; the prior CertCheck is disabled

warning did not reappear in the checked log tail.

On 2026-06-12, the tracked active media-project compose was prepared to move

NZBGet credentials out of YAML and into:

/volume3/docker/media-project/secrets/nzbget.env

Use these helpers from the workspace to apply or repair that state:

powershell -NoProfile -ExecutionPolicy Bypass -File .\synology\docker\projects\arrs-compose\Install-MediaProjectNzbgetSecret.ps1
powershell -NoProfile -ExecutionPolicy Bypass -File .\synology\docker\projects\arrs-compose\Deploy-MediaProjectCompose.ps1 -Apply
powershell -NoProfile -ExecutionPolicy Bypass -File .\synology\docker\projects\arrs-compose\Recreate-NzbgetFromMediaProject.ps1

The first helper may prompt for the NZBGet username/password if the local

ignored .secrets file does not already exist. The recreate helper is scoped to

the nzbget service and does not recreate the rest of media-project.

Recyclarr

Detailed source of truth: synology/docker/RECYCLARR_PLAN.md

Recyclarr exists only as a historical/reference tool unless the user

explicitly asks to reactivate it. It is not the active preference authority

and should not be scheduled.

On 2026-05-25, a conservative Recyclarr sync was applied to Sonarr only.
Targeted existing Sonarr profiles:
1080
Reality
Key score added:
Language: Not English = -10000
Other scoring added includes WEB tier preferences, repack/proper preference,

and strong rejection for junk patterns such as BR-DISK, LQ, AV1, and

extras.

On 2026-05-27, a storage-conscious policy was applied for normal

TV/Reality and Movies/Kids Movies. As of 2026-06-03, active maintenance of

that policy is direct Sonarr/Radarr API helpers rather than Recyclarr:

Sonarr profiles: 1080, Reality
Radarr profile: HD - 720p/1080p
x265/HEVC remains unpenalized.
Anime custom-format scoring remains untouched.
Size caps were applied with

tools/synology/arr-vhnic-storage-conscious-quality-caps.sh rather than a

Recyclarr quality-definition block, because preview showed Recyclarr would

otherwise fill omitted 2160p/remux qualities from guide defaults.

Post-check confirmed Anime - Dubbed 1080p has these Recyclarr scores at

0; leave Anime alone unless there is a separate preview and explicit

approval.

Latest direct preference audit:

synology/docker/arr-preference-audit/20260603-221118/SUMMARY.md

showed 31 pass, 0 warn, 0 fail.

On 2026-06-03, Set-RadarrMainProfile1080Only.ps1 tightened the main Radarr

movie profile so it allows only HDTV-1080p, WEB 1080p,

WEBRip-1080p, and WEBDL-1080p. It disables SD/DVD/480p/720p,

Bluray/remux, and 2160p fallback qualities.

qBittorrent And Gluetun

Detailed source of truth: synology/docker/VPN_QBIT_NZBHYDRA_REVIEW.md

qBittorrent routes through Gluetun.
qBittorrent is bound to tun0.
qBittorrent image as of 2026-05-27:

linuxserver/qbittorrent:5.1.4-r3-ls453.

On 2026-05-27, linuxserver/qbittorrent:5.2.1_v2.0.12-ls459 was tested.

The container wrapper started, but the qBittorrent application/WebUI did not

come up cleanly, so the service was rolled back to 5.1.4-r3-ls453.

This is an explicit reviewed pin rather than the floating latest tag.

qBittorrent remains pinned to linuxserver/qbittorrent:5.1.4-r3-ls453, but

it is no longer marked Watchtower monitor-only as of 2026-06-12.

Keep com.centurylinklabs.watchtower.depends-on=gluetun.
Do not re-add com.centurylinklabs.watchtower.monitor-only=true unless a

separate qBittorrent-after-Gluetun recreate mechanism is installed.

Reason: when Gluetun is updated/recreated, qBittorrent must also be

restarted/recreated so it joins Gluetun's new network namespace.

qBittorrent also uses long-form Compose depends_on for Gluetun with

restart: true. That helps for explicit Compose operations involving

Gluetun, but it does not guarantee qBit restarts after every possible Docker

daemon/container-runtime restart event.

On 2026-06-12, qBittorrent became unreachable after Gluetun changed. The

repair helper synology/docker/projects/vpnproject-compose/Repair-QbitGluetunNamespace.ps1

recreated qBittorrent after ensuring Gluetun existed in the compose graph,

and 10.0.0.119:8090 returned to normal.

User currently reports qBittorrent is connectable and does not want VPN/port changes right now.
Gluetun HTTP proxy and Shadowsocks were observed enabled; later review whether they are needed.
Gluetun was recreated with qBittorrent during the 2026-05-27 image refresh

and settled healthy. Forwarded port at verification time was 55641.

On 2026-06-12, the Gluetun WireGuard private key was removed from the tracked

compose file. Gluetun now expects the key in:

/volume3/docker/gluetun/secrets/gluetun.env.

Use synology/docker/projects/vpnproject-compose/Install-GluetunSecret.ps1

to install that file before recreating Gluetun from compose.

Tdarr

Detailed source of truth: synology/docker/tdarr/README.md

Synology hosts the Tdarr server/UI/database.
Desktop runs the native worker node.
Primary desktop native node cache now maps /temp to the direct UNC path

\\10.0.0.119\VM Storage\docker\tdarr\transcode_cache. Avoid T:/

for the primary node unless a scheduled-task-safe mapping is proven, because

the node failed transcodes on 2026-06-04 when the mapped drive was

unavailable to the node process after restart. A temporary local cache

test at D:/TdarrCache produced copyFailed entries because the Tdarr

server could not see local-only completed cache files.

Synology internal node is disabled.
Kids TV and Kids Movies completed cleanly on 2026-05-23:
active jobs: 0
transcode queue: 0
current file-level transcode errors: 0
current file-level health-check errors: 0
Tdarr reported saved space: 1226.4 GB
Movies was added to Tdarr on 2026-05-23 as VHNIC Movies with ID

movies01, path /media/media/movies, transcodes enabled, health checks

enabled, folder watching enabled, scheduled scan enabled.

TV Shows was added on 2026-05-26 as VHNIC TV Shows with ID tvShows01,

path /media/media/tv shows, cloned from the Movies library settings.

Worker counts on the desktop node are now user-controlled from Tdarr. The

user may intentionally raise/lower transcode or health-check workers depending

on gaming/RDP/Plex responsiveness.

Reality was added on 2026-06-07 as VHNIC Reality with ID reality01, path

/media/media/reality, cloned from the TV Shows library settings.

Reality repair follow-up on 2026-06-07:
current active health-failure bucket initially contained 20 old Survivor

AVI files,

codecs were msmpeg4v3 and mpeg4 with malformed MP3 header warnings,
Set-TdarrRealityLegacyRepairProfile.ps1 updated only reality01 to use

the local safe fallback plugin as HEVC MP4 with AAC audio,

the 20 files were requeued through Tdarr's API,
follow-up capture synology/docker/tdarr/health/20260607-233715/tdarr-health-failures.txt

showed no rows in the current failure table.

Current rollout posture: Kids TV, Kids Movies, Movies, TV Shows, and Reality

have completed the original broad rollout targets. A 2026-06-10 capture

showed queue/errors at zero. A newer 2026-06-11 local capture shows 112

queued transcodes and 98 active jobs with 0 transcode errors and stable

DB load; treat this as the user's remaining evening finish-out queue and

recapture after it drains before changing profiles or adding Anime. Personal

is off-limits.

TV Shows repair follow-up on 2026-05-27:
current active health-failure bucket: 48 queued files,
44 MPEG4/AVI files,
4 H.264/MKV files,
controlled repair notes are documented in

synology/docker/tdarr/README.md.

Local notes:
synology/docker/tdarr/COMPLETION_MILESTONES.md
synology/docker/tdarr/NEXT_LIBRARY_ROLLOUT_PLAN.md
synology/docker/tdarr/ANIME_PROFILE_PLAN.md
synology/docker/tdarr/native-worker/SECOND_WINDOWS_NODE.md

Homepage Portal

Detailed source of truth:

synology/docker/projects/homepage-compose/README.md

Homepage is the primary internal VHNIC portal as of 2026-06-03.
Internal URL: http://10.0.0.119:7576
Rendered diagram/docs URL: http://10.0.0.119:7577
Container Manager project: homepage
Local tracked project path:

synology/docker/projects/homepage-compose

Synology compose path:

/volume1/docker/projects/homepage-compose

Runtime config path:

/volume3/docker/homepage/config

Runtime static docs path:

/volume3/docker/homepage/docs

Runtime secret/env path:

/volume3/docker/homepage/secrets/homepage.env

The portal includes:
service launchers,
live media/app widgets,
live Prometheus summary cards,
Grafana dashboard shortcuts,
maintenance/runbook cards,
backup/safety cards,
diagram/map references.
It does not mount the Docker socket. Do not add Docker socket access directly;

if live Docker widgets become necessary, prefer a narrow read-only socket

proxy.

Homepage replaced the Homarr pilot. Homarr container/appdata were removed

after approval. Do not expose Homepage publicly without first deciding on a

VPN/overlay or MFA/SSO access model.

Observability

Pilot observability stack running on Volume 3:
Grafana
Prometheus
Blackbox exporter
Node exporter
cAdvisor
Tdarr exporter
Tautulli exporter
UniFi exporter
Local compose/config path:

synology/docker/projects/observability-compose

Synology compose/config path:

/volume1/docker/projects/observability-compose

Writable appdata path:

/volume2/docker-v5/appdata/observability

Observability secret path:

/volume2/docker-v5/appdata/observability/secrets

Initial Grafana URL:

http://10.0.0.119:3000

Initial Grafana credentials:
username: admin
password changed by user on 2026-05-24; do not assume the original

bootstrap password still works.

This stack is intentionally non-critical and is the first low-risk real

workload for the Samsung Volume 3 SSD mirror.

First deployment record:

synology/docker/projects/observability-compose/DEPLOYMENT-20260524.md

Project README:

synology/docker/projects/observability-compose/README.md

Current dashboards:
VHNIC Service Health: Blackbox reachability checks for Synology apps,

Plex TCP, Pi-hole admin/DNS, and UniFi gateway TCP.

VHNIC Synology and Docker Metrics: Node exporter and cAdvisor metrics

for Synology CPU, memory, load, /volume1//volume2//volume3 usage,

disk throughput, disk busy percentage, read-latency signals, CPU I/O wait,

network throughput/errors, Synology md/RAID active/failed/maintenance

state, and top container CPU/memory/network.

VHNIC Pi-hole DNS Health: Blackbox DNS probes against PiHolePi4

(10.0.0.195) and PiHole4B (10.0.0.132) for google.com A-record

lookup success and query duration.

VHNIC UniFi Network Health: Blackbox TCP probes for UDM SE HTTPS/SSH and

both U7-Pro APs over SSH, plus live UniFi Integration API metrics for

device state, wired/wireless client counts, and wireless clients by AP.

AP HTTPS was tested but omitted because the APs did not answer on 443.

VHNIC Tdarr Progress: read-only Tdarr SQLite exporter metrics for active

jobs, transcode queue, errors, total files, space saved, library counts, and

staged status counts. It also includes Prometheus-history-based queue ETA

panels using one-hour and six-hour queue depletion rates plus an estimated

completion clock. Treat these as directional because Tdarr throughput

changes with file size, codec, worker count, and whether new libraries are

added. Important Grafana implementation detail: the estimated completion

clock query multiplies the projected Prometheus Unix timestamp by 1000

before formatting with dateTimeAsIso; otherwise Grafana displays a

1970-era date.

VHNIC Plex Activity: read-only Tautulli API exporter metrics for active

streams, direct/transcode split, LAN/WAN/total bandwidth, current session

inventory, stream breakdowns by user/platform/location/media type,

per-session bandwidth/progress, recent 24-hour and 7-day play/watch-time

summaries, and Plex library counts. The exporter reads Tautulli's existing

API key from /volume1/docker/tautulli/config.ini at runtime; the key is

not stored in tracked project files.

VHNIC Infrastructure Overview: single-glance summary that combines core

service failures, Synology load/storage, Tdarr queue/errors, DNS/UniFi

latency, UniFi client/device counts, container memory, and Plex

stream/transcode status.

VHNIC Alert Watch: passive Prometheus alert view for exporter failures,

service probe failures, high volume usage, sustained disk busy time,

Synology RAID failed disks or maintenance/resync/check state, Tdarr errors,

Plex transcodes, and UniFi offline devices. Warning notification routing to

Discord is now configured through Alertmanager and discord-alert-bridge;

info alerts remain dashboard-only.

VHNIC Public Exposure: public Seerr/reverse-proxy reachability, HTTP

status, TLS certificate expiration, and Seerr/Caddy container resource

signals.

VHNIC Storage Integrity: Volume 1/2/3 space, Btrfs error counters and

increases, filesystem read-only/device-error flags, RAID member/sync state,

disk busy/throughput/latency, temperature/fan metrics, and container OOM

event counts. Known old Volume 1 Btrfs corruption counters are historical;

alerting focuses on new growth.

VHNIC Observability Stack Health: Prometheus readiness, scrape target

state, rule-evaluation failures, scrape durations/sample rates, exporter

health, scrape failures, and firing alerts.

Discord warning notification plumbing was installed and test-posted on

2026-05-25:

Prometheus sends alerts to Alertmanager, Alertmanager routes

severity="warning" alerts to discord-alert-bridge, and the bridge posts

to a Discord webhook stored only in an ignored/protected secret file. Info

alerts remain dashboard-only to avoid notification noise.

Prometheus alert rules live at:

synology/docker/projects/observability-compose/prometheus/alerts.yml.

The UniFi exporter reads /volume2/docker-v5/appdata/observability/secrets/unifi.local.env

at runtime. Install/update that remote secret from the ignored local

tools/unifi/.secrets/unifi.local.env file with:

synology/docker/projects/observability-compose/Install-ObservabilityUnifiSecret.ps1.

The API key should not be committed.

Prometheus jobs verified scraping on 2026-05-24:
synology-node
docker-cadvisor
pihole-dns
tdarr
tautulli
unifi
service-http
service-tcp
Last known healthy target state after expanded observability work:

synology-node 1/1 up
docker-cadvisor 1/1 up
tdarr 1/1 up
tautulli 1/1 up
unifi 1/1 up
pihole-dns 2/2 up
service-http 11/11 up
service-tcp 9/9 up

Later Discord alerting expansion verified:
alertmanager up,
discord-alert-bridge up,
service-http expanded to include Seerr public aliases and alerting

endpoints,

warning alerts route to Discord,
info alerts remain dashboard-only.
Last known passive alert state after reload:
alert rules loaded: 17
VHNICExpectedContainerMissing watches expected always-on containers.
VHNICContainerRestartingOften watches repeated restarts.
Recyclarr is intentionally excluded because it is now manual-only.
a routine info alert may fire when Plex is actively transcoding.
Current known observability limitations:
Pi-hole deep query/block stats are not implemented because unauthenticated

Pi-hole v6 API endpoints returned 401 Unauthorized; current Pi-hole

monitoring is DNS probe health only.

UniFi live exporter uses the Integration API and currently covers

device/client state, not WAN throughput, AP channel utilization, retry

rates, or client experience.

Alert notification routing exists for warning alerts, but rule thresholds

and notification noise still need real-world tuning.

Automation And Retention

Windows scheduled task Codex VHNIC Weekly Maintenance Report runs Sundays

at 07:30 and writes read-only report bundles under

reports/weekly-maintenance.

Codex automation review-vhnic-weekly-maintenance-report reviews the weekly

report Sundays at 09:30.

Codex automation refresh-vhnic-project-docs-and-handoff refreshes full

project docs and handoff material Mondays at 09:00.

Raw logs should be summarized into incidents before long-term retention.

Exact-path approval is still required before deletion.

Desktop / Apollo

Apollo on the main desktop is installed as ApolloService.
Service binary: D:\Program Files\Apollo\tools\sunshinesvc.exe.
Startup type: Automatic delayed start.
It runs as LocalSystem and should not require interactive login.
On 2026-05-23, service recovery was configured by the user:
restart after 60 seconds,
restart after 60 seconds,
restart after 60 seconds,
failure actions on non-crash failures enabled.
Verified afterward:
ApolloService running,
ports 47984, 47989, 47990, and 48010 listening.
If Apollo seems unavailable after reboot, wait for delayed startup first; if it

still fails, check service recovery/events and D:\Program Files\Apollo\config\sunshine.log.

Container Manager Project Alignment

The 2026-05-27 Container Manager organization pass verified that active

containers now have Compose project labels that match the intended Synology

Container Manager project rows where possible. Important current mappings:

media-project: Sonarr, Radarr, Prowlarr, Lidarr, NZBHydra2,

Seerr, NZBGet

homepage: Homepage internal VHNIC portal
reading: Kavita and Mylar3 internal reading stack
monitoring: Grafana, Prometheus, Alertmanager, exporters, cAdvisor,

Blackbox, Node exporter, Discord alert bridge

vpn-project: Gluetun and qBittorrent
plex: Plex and Tautulli
reverse-proxy-compose: Caddy reverse proxy
tdarr: Tdarr, with source folder

/volume2/VM Storage/projects/tdarr-compose

The 2026-05-27 image refresh is documented in

synology/docker/IMAGE_UPDATE_LOG.md.

If Synology Container Manager still displays zero containers for one of those

project rows after refreshing the UI, treat it as DSM project registry/cache

drift first. Docker itself currently reports the Compose projects correctly.

Do not delete appdata, Docker volumes, or media to repair this. Wrapper

replacement is acceptable only after confirming the compose file, appdata paths,

and rollback plan.

DSM stores registered Container Manager project metadata under

/volume1/@appconf/ContainerManager/projects, which is root-readable only.

Do not hand-edit those files without first capturing a backup and confirming

the exact DSM schema. Prefer importing/registering projects through Container

Manager when possible.

On 2026-05-27, the user registered missing DSM Project rows through Container

Manager's UI for:

monitoring
tdarr
reverse-proxy-compose

After registration on 2026-05-27, before later Recyclarr and Dispatcharr

cleanup, the Container Manager Project page showed:

media-project       9 containers
reverse-proxy-compose 1 container
monitoring          10 containers
tdarr               1 container
plex                2 containers
watchtower          1 container, stopped
vpn-project         2 containers

Docker-side verification at that point matched:

media-project running(8)
monitoring running(10)
plex running(2)
reverse-proxy-compose running(1)
tdarr running(1)
vpn-project running(2)

The media-project count differs because Recyclarr is intentionally stopped

and DSM counts it in the project while docker compose ls reports running

containers.

Later on 2026-05-27, Recyclarr was removed from media-project because its

normal stopped state made the whole DSM project look unhealthy. Its appdata was

left intact at /volume1/docker/recyclarr; only the stopped container wrapper

was removed. Recyclarr should be run manually or through a controlled helper

when profile sync is desired.

Later on 2026-05-29, Dispatcharr was removed from media-project because the

IPTV provider will not be renewed. Compose was redeployed with

--remove-orphans, the Dispatcharr container was stopped/removed, and

monitoring expected-container rules were updated so it is no longer treated as

missing. Stale appdata at /volume1/docker/dispatcharr was removed on

2026-06-01 after exact approval.

Final desired Docker project grouping after this cleanup:

media-project: running(7)
homepage: running(1)
monitoring: running(10)
plex: running(2)
reverse-proxy-compose: running(1)
tdarr: running(1)
vpn-project: running(2)
watchtower: running from its own project; qBittorrent is pinned but not monitor-only

Later on 2026-05-27, the user chose to run Watchtower again now that

qBittorrent is pinned. Watchtower was recreated from

its Compose project after correcting TZ=America/New_York so the schedule runs

at local 2 AM rather than UTC 2 AM. The compose project name was also set

explicitly to watchtower so Synology Container Manager and Docker labels

match. Verification showed:

watchtower Up, healthy
com.docker.compose.project=watchtower
first run scheduled 2026-05-28 02:00:00 -0400 EDT

On 2026-06-12, tracked Homebridge and Watchtower compose files were hardened

with security_opt: no-new-privileges:true. To apply the tracked state on the

Synology, run:

powershell -NoProfile -ExecutionPolicy Bypass -File .\synology\docker\Apply-HomebridgeWatchtowerHardening.ps1 -Apply

Expect a brief Homebridge interruption while the container is recreated.

On 2026-05-27, Tdarr was moved from implicit project name tdarr-compose to

explicit project name tdarr. The container restarted cleanly and endpoints

answered afterward:

8265 Web UI: 200
8266 server API: 302
9201 Tdarr exporter: 200

During the post-restart scan, Tdarr logged one storage read error:

EIO lstat /media/media/tv shows/Obi-Wan Kenobi/Season 1/Obi-Wan Kenobi - S01E02 - Part II.mkv

Treat that as a candidate file/path/storage follow-up; do not delete or repair

anything without explicit approval.

Plex

Detailed source of truth: synology/docker/plex-diagnostics/20260515-235255/FINDINGS.md

Plex appdata is on Volume 2.
Current Plex DB quick checks returned ok for the main library DB and blobs DB.
Historical corrupt DB artifact exists from 2025-03-14, but recent checks did not show current DB corruption.
Dimension 20 playlists were created on 2026-05-25. Details and helper scripts

are documented in synology/docker/PLEX_PLAYLISTS.md.

The Dimension 20 playlist helpers read the Plex token from the Plex container

at runtime and do not print it.

Open Decisions

Reverse proxy location for Seerr and other apps:
Synology,
Raspberry Pi,
or another host.
Observability follow-up:
current Grafana/Prometheus stack is running on Volume 3,
decide later whether to add Grafana notification routing, Pi-hole

authenticated metrics, deeper UniFi metrics, or desktop Tdarr worker health.

Homebridge review and Docker migration completed on 2026-05-28:
former runtime was Synology Package Center package homebridge version

4.1.2,

current runtime is Docker Compose project homebridge, container

homebridge, image homebridge/homebridge:latest,

live appdata/config is /volume1/homebridge,
UI port is 8581; bridge port is 51537,
plugins observed: Ring, TP-Link/Kasa, Rain Bird,
compose file is

synology/docker/projects/homebridge-compose/compose.yaml,

rollback archive is

/volume1/docker/backups/homebridge/homebridge-before-docker-.tar.gz,

detailed review is synology/docker/HOMEBRIDGE_REVIEW.md,
monitoring now probes Homebridge UI and expects the homebridge

container,

Rain Bird was cleaned up after migration on 2026-05-28:

showRequestResponse=false, firmware override 2.10, friendly device

name RainBird Controller, and local compatibility patch helper

synology/docker/homebridge/Patch-HomebridgeRainBirdPlugin.ps1,

monitoring now has a RainBird Controller TCP reachability probe on

10.0.0.24:80,

do not run package and container at the same time, and preserve persist/

plus accessories/ to avoid resetting HomeKit pairing.

Dynamic DNS plan for Google DNS and public IP updates.
Public request aliases already exist for overseerr.ravick5.com,

seerr.ravick5.com, and requests.ravick5.com. Future work is notification

routing and CSRF hardening, not basic alias creation.

Future use of the two bays freed by cache removal:
best current planning preference is two new 2TB or larger endurance/NAS SSDs as a mirrored Volume 3 for high-churn app workloads,
do not reuse the removed cache SSDs for production.
Appdata backup destination:
external USB,
another machine/NAS,
offsite/cloud,
or interim local NAS copy.
Tdarr second Windows node:
candidate machine: 10.0.0.126
ping/RDP/SMB reachable as of 2026-05-23,
SSH not open,
needs hardware/GPU check and Tdarr Node install/config before enabling

workers.

Recent User Preferences

Anime is dubbed-only; avoid workflows that favor subbed/Japanese releases.
Anime should be the last Tdarr target and should use a custom stream-preserving

profile.

Personal media is not a compression target. It contains irreplaceable family

videos and must not be modified.

User wants to reduce manual media acquisition over time, especially for Anime.
User values local project documentation for recovery and comparison.
User is open to sudo/privileged access where useful, but wants explicit approval before deletion or high-risk remediation.