File Tree Reorganization¶
v1.6 | Build 007.20260815.181840Z
Design for reorganizing the McGuckin.Net file tree.
NET-003 — Container Platform Standard — Design Review Artifact
## Proposed Five-Volume File-Tree Reorganization
Clean-sheet target architecture and migration map for JUKEBOX
| | |
|----|----|
| Report version | 0.7 |
| Date | August 15, 2026 |
| Applies to | JUKEBOX — Apple iMac (2024), Apple M4 |
| Volumes | PlexHD, PlexDB, Storage, Backups, and TARDIS |
| Design authority | Proposed revision to NET-003. NET-004 will inherit approved paths after NET-003 is updated. |
| Evidence boundary | Current top-level folders and volume characteristics were supplied in Finder screenshots. Lower-level contents must be inventoried before migration. |
1 — Storage Model 2 — Organizing Rules 3 — Proposed Trees 4 — Migration Map 5 — Migration Sequence 6 — Authority Handoff
## 1. Recommended Storage Model
Each volume receives one primary responsibility. The design avoids using folder names to disguise cross-volume ambiguity: live state stays on the live-state volume, media stays on the media volume, independent recovery data stays on the recovery volume, and Time Machine remains isolated.
### PlexHD
APFS · 494.38 GB
macOS, installed native applications, user home directories, and only the application state that must remain in standard macOS locations.
### PlexDB
APFS · 1.92 TB
High-performance live service state: native Plex metadata, Docker application data, Compose state, orchestration state, and Docker Desktop’s VM disk.
### Storage
HFS+ / SoftRAID · 44 TB
Downloads, media libraries, and controlled intake. All download and library paths remain on this single filesystem.
### Backups
APFS · 5 TB
Independent non-Time Machine recovery data: Restic repositories, exports, recipes, protected configuration, manifests, and restore evidence.
### TARDIS
APFS, case-sensitive · 5 TB
Exclusive Apple Time Machine destination. Its contents are managed by Time Machine, not by the Docker platform.
**Key recommendation** Rename the existing `/Volumes/PlexDB/Plex Media Server` directory to `/Volumes/PlexDB/Plex`. The resulting path contract is `/Volumes/PlexDB/Plex/`. Plex Media Server remains a native macOS application on PlexHD, and every item currently inside the application-data directory retains its existing relative path and internal organization.
## 2. Organizing Rules
Directory case
Volume-level platform roots use the existing capitalized convention (`Docker`, `Logs`, `Plex`, `Downloads`). Application and functional subdirectories use lowercase names.
Application key
Use the application’s approved three-letter unique key in inventories and manifests, but keep filesystem directory names human-readable, such as `sonarr` or `tautulli`.
Compose project
One logical application per `/Volumes/PlexDB/Docker/compose/`, normally containing `compose.yaml`, `.env`, and `README.md`.
Container media mount
Mount `/Volumes/Storage` consistently as `/data` inside download and Servarr containers so downloads and libraries share one container-visible root.
Secrets
Live secret files belong under PlexDB with restrictive permissions. Backup copies on Backups must be encrypted; unprotected plaintext secret archives are prohibited.
Logs
Use `/Volumes/PlexDB/Logs/` as the universal retained file-log search root. Each entry is either **DIRECT** (the application is explicitly configured to write there, or a supported container path is bind-mounted there) or **LINK** (a relative symbolic link points to the application-owned log directory on PlexDB). `Logs/README.md` records the type, target, owner, rotation authority, and health check for every entry. Applications own their log contents and rotation. Broken links raise a warning and are never replaced with an empty directory. Stdout-only container logs remain Docker-managed, size-rotated, and accessed through Dozzle; they are inventoried as **CONSOLE-ONLY** and are not copied into the retained file-log tree.
**One primary role per volume**Every folder must support the volume’s declared responsibility. Convenience copies do not redefine authority.
**Live data is not a backup**Anything required by a running service belongs on PlexHD, PlexDB, or Storage. Independent recovery copies belong on Backups.
**Applications and state are separate**Native application bundles remain on PlexHD. Large or intentionally externalized service state belongs on PlexDB.
**Stable names beat category churn**Application directories use lowercase logical application names. App identity remains stable even if a reporting category changes.
**Time Machine owns TARDIS**No custom scripts, Restic repositories, exports, or Docker files are mixed into the Time Machine destination.
**Copies precede cutovers**Migration copies and verifies data before an application is redirected. Original data is retained through a rollback period.
## 3. Proposed End-State Trees
### PlexHD
macOS and native applications
/ (PlexHD) ├── Applications/ \# Native application bundles │ ├── Arq.app │ ├── Docker.app │ ├── Plex Media Server.app │ ├── Private Internet Access.app │ ├── SABnzbd.app │ ├── SoulseekQt.app │ ├── Transmission.app │ └── Startup Manager.app ├── Library/ \# macOS-managed ├── System/ \# macOS-managed └── Users/ └── todd/ ├── Library/ \# Standard macOS/native-app settings └── Documents/ \# Human documents, not service runtime
**Design intent.** Do not create a custom platform tree at the PlexHD root. macOS retains its native structure. Docker Desktop and native application bundles stay in `/Applications`; downloads and media never return to the startup disk.
**Native application configuration**PIA, Transmission, and SABnzbd should keep settings in their supported macOS locations unless the application provides a documented external configuration root. These small settings are protected by Backups and, where eligible, Time Machine. Fragile symlinks are not the default design.
### PlexDB
live high-performance service state
/Volumes/PlexDB/ ├── README.md \# Volume role, owners, exclusions, recovery notes ├── Docker/ │ ├── README.md \# Docker tree contract and source-of-truth rules │ ├── appdata/ │ │ └── \/ \# Application-generated mutable state │ ├── compose/ │ │ └── \/ │ │ ├── compose.yaml │ │ ├── .env │ │ └── README.md │ ├── configs/ │ │ ├── platform/ │ │ ├── caddy/ │ │ └── startup-orchestrator/ │ │ ├── startup-plan.yaml │ │ └── launchd/ │ ├── docker-desktop/ │ │ └── vm-data/ \# Docker Desktop-managed VM disk location │ ├── scripts/ │ │ ├── backup/ │ │ ├── bootstrap/ │ │ ├── maintenance/ │ │ ├── recovery/ │ │ ├── startup-orchestrator/ │ │ └── validation/ │ ├── secrets/ │ │ └── \/ \# Directory 700; files 600 │ ├── state/ │ │ └── startup-orchestrator/ \# Checkpoints and last-run state │ └── templates/ │ ├── container-recipe/ │ └── startup-orchestrator/ ├── Logs/ │ ├── README.md \# DIRECT, LINK, or CONSOLE-ONLY registry │ └── \/ \# Direct directory or relative symlink └── Plex/ \# Renamed from “Plex Media Server” └── \/ \# Existing Plex-managed contents unchanged
**Design intent.** PlexDB contains live state, not the independent recovery set. `Docker`, `Logs`, and `Plex` are peers at the volume root. The iCloud project remains the governance and authoring source for approved documentation and master templates; `Docker/templates` contains approved runtime snapshots used to build or recover JUKEBOX.
**Universal Logs directory — selected mechanism**`/Volumes/PlexDB/Logs` is an index over retained application file logs, not a second copy. Use a DIRECT directory only when the application officially supports an external log path or bind mount. Otherwise use a relative LINK to the fixed application-owned directory; `Logs/plex` links to Plex’s existing internal Logs directory without changing Plex’s tree. The link itself is platform-managed, the target remains application-managed, search tools must follow symbolic links, and the health check must report a missing target. A broken link never triggers automatic target creation or application reconfiguration. CONSOLE-ONLY containers remain available through Dozzle and Docker’s bounded rotation.
**No generic PlexDB/Backups folder in the final design**The current `/Volumes/PlexDB/Backups` folder is migrated to the independent Backups volume. A second copy on PlexDB does not protect against PlexDB failure and therefore must not be presented as the platform backup destination.
### Storage
downloads, libraries, and controlled intake
/Volumes/Storage/ ├── README.md \# Media path contract and ownership rules ├── Downloads/ │ ├── incomplete/ │ │ ├── bittorrent/ │ │ └── usenet/ │ ├── complete/ │ │ ├── bittorrent/ │ │ └── usenet/ │ └── watch/ │ ├── bittorrent/ │ └── usenet/ ├── Libraries/ │ ├── Movies/ │ ├── Music/ │ ├── Reading/ │ ├── Software/ │ └── Television/ └── Unsorted/ ├── incoming/ \# Newly discovered unmanaged content ├── review/ \# Human classification required └── quarantine/ \# Suspect, duplicate, or rejected content
**Design intent.** Downloads and libraries stay under one filesystem and one shared container-visible root. This supports predictable imports and avoids presenting the same host folder under inconsistent container paths.
**Container path contract**Download clients and Servarr applications receive `/Volumes/Storage:/data`. Examples: `/data/Downloads/complete/usenet`, `/data/Libraries/Movies`, and `/data/Libraries/Television`. Application-specific aliases such as `/downloads` and `/movies` are avoided.
### Backups
independent non-Time Machine recovery
/Volumes/Backups/ ├── README.md \# Backup ownership, retention, encryption, restore order ├── Restic/ │ └── jukebox/ \# Restic-managed repository; never hand-edit ├── Application-Exports/ │ └── \/ \# Application-native backup/export format ├── Platform-Recovery/ │ ├── compose/ │ ├── configs/ │ ├── scripts/ │ ├── secrets-encrypted/ │ ├── state/ │ ├── templates/ │ └── manifests/ ├── Host-Recovery/ │ ├── inventories/ │ ├── launchd/ │ ├── network/ │ └── software/ ├── Recovery-Kits/ │ ├── current/ │ └── historical/ │ └── YYYY/MM/ ├── Validation/ │ ├── backup-logs/ │ └── restore-tests/ └── Legacy/ └── 2026-pre-standard/ \# Read-only migration holding area
**Design intent.** Backups contains everything needed to reconstruct the environment after catastrophic loss: machine-readable recipes, application-native exports, platform configuration, encrypted secrets, inventory evidence, and tested restore instructions.
**Application exports are runtime-neutral**A Servarr backup or export is created by the application itself and uses the same format before and after containerization. Docker has no universal application-aware export process. Docker deployment artifacts—`compose.yaml`, `.env`, bind-mount definitions, scripts, manifests, and encrypted secrets—are protected separately under `Platform-Recovery`. Docker Engine’s filesystem export command is not a substitute because it excludes mounted persistent application data.
**Independent does not mean invulnerable**Backups protects against PlexDB and startup-disk loss, but it remains a single local disk. Keep the full local recovery set here, then send encrypted, versioned recovery sets to the immutable off-device target defined in Section 6. iCloud Drive or OneDrive may hold an additional convenience copy, but neither is counted as the immutable layer.
### TARDIS
Apple Time Machine only
/Volumes/TARDIS/ └── \[Apple Time Machine-managed backup set\] ├── \[snapshot history\] └── \[Time Machine metadata\]
**Design intent.** The absence of a custom tree is intentional. Time Machine controls the on-disk layout. No Docker folders, Restic repositories, scripts, exports, or manually managed recovery kits are created on TARDIS.
## 4. Current-to-Target Migration Map
This map translates the screenshot-observed top-level folders into the proposed clean-sheet organization. “Classify” means the folder must be inventoried before its contents receive a final destination.
**Narrow-screen note:** Swipe or scroll horizontally to read all four migration fields.
| Current item | Proposed destination | Action | Migration note |
|----|----|----|----|
| PlexHD system tree | Unchanged macOS-managed locations | Keep | Do not reorganize `/System` or `/Library`. |
| PlexHD/Users/toddmcguckin | PlexHD/Users/todd | Stage | Perform as a separately documented macOS account short-name migration; verify ownership, login, application settings, and rollback before retiring the old home path. |
| PlexDB/Backups | Backups/Legacy/2026-pre-standard/PlexDB-Backups | Copy | Preserve first, then classify exports and recovery assets into the new Backups tree. |
| PlexDB/Exports | Backups/Application-Exports/\ | Classify | File by originating application. The export format is application-native and does not change when that application moves into Docker. |
| PlexDB/Logs | PlexDB/Logs/\ | Classify | Make this the universal retained file-log search root; assign every retained log to its owning application and apply rotation. |
| PlexDB/Plex Media Server | PlexDB/Plex | Rename | Stop Plex, preserve and verify the complete directory, rename only the top-level folder, redirect Plex to `/Volumes/PlexDB/Plex`, and test before retiring the old path reference. |
| PlexDB/Plex Media Server.rar | Backups/Legacy/2026-pre-standard/archives | Hold | Preserve as a legacy archive until its contents and recovery value are verified. |
| PlexDB/Scripts | PlexDB/Docker/scripts or Backups/Platform-Recovery/scripts | Classify | Working operational scripts live on PlexDB; protected recovery copies live on Backups. |
| PlexDB/Tautulli | PlexDB/Docker/appdata/tautulli | Copy | Use the container migration procedure and retain the native source through rollback acceptance. |
| Docker Desktop VM disk — current location to be recorded from Settings › Resources › Advanced | PlexDB/Docker/docker-desktop/vm-data | Stage | Record the displayed source path, maximum size, actual allocated size, engine version, projects, images, and volumes. Create and verify platform recovery artifacts; stop containers; then use Docker Desktop’s Disk image location Browse/Apply control. Never move `Docker.raw` in Finder. Verify the new displayed location, engine startup, projects, containers, networks, volumes, and application health. Roll back through the same Docker Desktop control or, with Docker Desktop fully stopped, restore the pre-change VM-disk copy to its recorded original location. No source or recovery copy is deleted without separate approval. |
| PlexDB/TestShare | Backups/Legacy/2026-pre-standard/quarantine/TestShare | Hold | Quarantine for review. Delete only after contents are proven unnecessary and deletion is separately approved. |
| Backups/Scripts | Backups/Legacy/2026-pre-standard/Backups-Scripts | Classify | Determine whether each file is an operational source, a recovery copy, or obsolete. |
| Storage/Downloads | Storage/Downloads/{incomplete,complete,watch}/{bittorrent,usenet} | Stage | Map current client folders into protocol and lifecycle stages without crossing volumes. |
| Storage/Libraries | Storage/Libraries/{Movies,Music,Reading,Software,Television} | Normalize | Preserve these approved library names unless a separate media-library review approves renaming. |
| Storage/Unsorted | Storage/Unsorted/{incoming,review,quarantine} | Stage | Separate newly found content from reviewed and quarantined material. |
| TARDIS snapshots | Time Machine-managed layout | Keep | No manual restructuring. |
Current items, approved target locations, migration actions, and item-specific controls {.plan}
**Docker Desktop support boundary**The relocation rule uses Docker Desktop’s supported *Settings › Resources › Advanced › Disk image location* control. Docker explicitly warns not to move the disk image directly in Finder. NET-004 must revalidate the control against the installed Docker Desktop version immediately before implementation. Official sources verified August 15, 2026: [Docker Desktop for Mac FAQ](https://docs.docker.com/desktop/troubleshoot-and-support/faqs/macfaqs/), [Docker Desktop settings](https://docs.docker.com/desktop/settings-and-maintenance/settings/), and [backup and restore](https://docs.docker.com/desktop/settings-and-maintenance/backup-and-restore/).
### Migration Action Contract
Before any row becomes an executable NET-004 runbook, its migration record must identify the exact source and target, owner, size, filesystem, application stop or quiesce requirement, permissions, ACLs, extended attributes, symbolic links, copy method, verification evidence, acceptance period, rollback source, and separately approved deletion boundary. A missing field stops that item; it does not authorize an assumption.
| Action | Prerequisite and execution | Verification and acceptance | Rollback and deletion boundary |
|----|----|----|----|
| Keep | Inventory and baseline the existing path; make no structural change. | Confirm mount, owner, permissions, application access, and expected contents. | Rollback is not applicable because no cutover occurs. Nothing is deleted. |
| Stage | Create the approved target structure and recovery evidence without redirecting the application. Quiesce first if data is copied. | Verify target ownership, permissions, ACLs, extended attributes, symbolic links, file counts, checksums, and free space. | Original source remains authoritative until a later approved cutover. Staged data may be removed only through a separately approved cleanup record. |
| Copy | Quiesce the owner, take a readable recovery copy, then copy—never move—the source to the approved target. | Verify counts, checksums, metadata, application startup, functional tests, and the defined observation period. | Restore the unchanged original path and configuration. Delete neither source until acceptance and separate cleanup approval. |
| Classify | Inventory each item’s owner, purpose, sensitivity, dependency, and recovery value before assigning a final target. | Review and approve a manifest mapping every classified item to a destination or explicit hold. | Source remains unchanged. Unclassified or disputed content is held; no deletion is permitted. |
| Rename | Quiesce the owner, create and verify a recovery copy, record all path consumers, and change only the approved path component. | Verify metadata, every path reference, application startup, functional tests, and observation period. | Restore the original name and references from the recorded manifest. The recovery copy remains until separate cleanup approval. |
| Hold | Copy the item into the named read-only Legacy or quarantine location with provenance and hash evidence. | Verify the held copy is complete, readable, attributable, and included in the inventory. | Original remains available until the hold is accepted. Release or deletion requires a separately approved disposition. |
| Normalize | Preserve approved names, create only missing standard subdirectories, and inventory every path consumer before reclassification. | Verify library visibility, application references, permissions, counts, and checksums for any copied content. | Retain the prior structure or manifest as the rollback source. Cleanup is a later, separately approved action. |
Normative meaning of every migration action used above {.plan}
## 5. Safe Migration Sequence
1. **Approve the target tree.** Resolve any requested changes in this report before updating NET-003.
2. **Promote documentation.** Create NET-003 v0.5 from a copy of the governing v0.4 parent, preserve v0.4 unchanged as the fallback, and integrate the approved tree, definitions, ownership, backup scope, and completion gates. Update every NET-004 path reference only after the new parent passes validation.
3. **Inventory lower-level contents.** Record size, owner, permissions, modification date, application dependency, and backup status for every current source folder.
4. **Create destinations only.** Build the approved empty directory structure with documented ownership and permissions. Do not redirect applications yet.
5. **Take recovery copies.** Back up live configuration and databases to Backups, record hashes/manifests, and verify that the backup can be read.
6. **Copy one workload at a time.** Stop the owning application, copy rather than move, verify file counts and checksums, then preserve the source unchanged.
7. **Redirect and test.** Update one application’s documented path, start it, verify permissions and functionality, and observe it through a defined acceptance period.
8. **Retain rollback sources.** Rename or mark the original source read-only; do not delete it until the application, backup, and restore tests all pass.
9. **Remove legacy data separately.** Deletion requires a later reviewed cleanup plan with exact targets and recovery status.
**Recommended approval boundary** Approval of this report should authorize documentation changes only: NET-003 first, NET-004 second, and project templates third. Creation of directories, data copying, application cutovers, and deletion remain separate infrastructure changes requiring their own approval.
## 6. Backup Architecture and Implementation Authority
This file-tree proposal defines where live and recovery data belong; it does not duplicate software installation, cloud-account configuration, prices, schedules, monitoring, or restore procedures.
**Architectural requirement retained for NET-003** `/Volumes/Backups` is the complete local non-Time Machine recovery root. Arq 7 with a private Backblaze B2 Object Lock bucket is the approved encrypted immutable offsite layer. The offsite copy supplements application-native exports, Restic, and Time Machine rather than replacing them. The 44 TB media library, Downloads, TARDIS, Docker Desktop VM data, routine logs, replaceable caches, and the local Restic repository are excluded unless separately approved.
NET-003 authority
Volume roles, required backup layers, protected root categories, exclusions, immutability requirement, encryption requirement, credential separation, and recovery-validation objectives.
NET-004 authority
Section 10.2 is the sole implementation authority for Arq and B2 installation, dependencies, bucket and key configuration, protected paths, retention settings, maintenance-window placement, cost estimates, monitoring, restore testing, and incident recovery.
Budgeting rule
NET-004 uses the highest credible published amount when official prices conflict, a range exists, or an announced increase is relevant. Estimates are labeled conservative, dated, and verified again before purchase.
**Promotion handoff** When this tree is approved, NET-003 v0.5 will receive only the architectural requirements above. NET-004 retains and maintains the detailed Arq 7 and Backblaze B2 implementation. No cloud account, software purchase, bucket, credential, upload, or infrastructure action is authorized by this proposal.
NET-003 proposed file-tree reorganization · v0.7 · August 15, 2026 · McGuckin-Net · Draft design-review artifact
Document Control¶
| Field | Value |
|---|---|
| Control ID | NET-INF-003 |
| Lifecycle | PUB |
| Status | Published |
| Version | v1.6 |
| Build | 007.20260815.181840Z |
| Canonical Filename | NET-INF-003_PUB_file-tree-reorganization_007-20260815-181840Z.md |
| Prior Identity | NET-003 |