OMV / homeNas storage structure review — VM 189 — 2026-06-01¶

Read-only investigation of OMV storage architecture inside VM 189 (homenas). Goal: build a complete picture of what is stored, how it is organized, and where improvements are possible without new hardware. No system changes made.

This complements the broader storage review at D:\PVE\storage-review-2026-05-31.md (which covered the hardware + RAID + backup posture). This report focuses on the OMV-side data architecture: subvolumes, mounts, shares, plugins, snapshots, content patterns.

Section A: Btrfs structure (mounts, subvolumes, allocation)¶

Two btrfs filesystems, six mount points total. The structure is more sophisticated than the prior review described — OMV is using actual btrfs subvolumes for share isolation, not bind mounts of subdirectories.

/dev/md0 (838 GB, 41% used)  ─►  /srv/dev-disk-by-uuid-71c8857b-... (r-tank root, subvolid 5)
                                  ├─ subvolid 267: r-tank/proxmox/backup ─► bind mount /export/p-backup
                                  └─ (no other subvolumes; r-tank, mac, windows are regular dirs)

/dev/md1 (1.4 TB, 73% used)  ─►  /srv/dev-disk-by-uuid-55cabf8d-... (s-tank root, subvolid 5)
                                  ├─ subvolid 257: s-tank/proxmox/ext-store ─► bind mount /export/ext-store
                                  ├─ subvolid 339: k8s-data              ─► bind mount /export/k8s-data
                                  └─ subvolid 353: k8sdata               ─► bind mount /export/k8sdata

So OMV created proper btrfs subvolumes for r-tank/proxmox/backup, s-tank/proxmox/ext-store, k8s-data, and k8sdata. Each is bind-mounted (/etc/fstab bind,nofail) onto /export/<name>/ for NFS export. This is good architecture — subvolumes allow per-folder snapshots and per-folder space accounting.

Compression: NOT enabled. Mount options are rw,relatime,space_cache with no compress= flag. btrfs property get returns no compression hint. Every file is stored uncompressed.

Section B: Directory layout per filesystem¶

r-tank (/dev/md0, 838 GB)¶

/srv/dev-disk-by-uuid-71c8857b-.../
├── r-tank/                        336 GB   ← bulk of r-tank data
│   ├── windows/                   2.1 GB   (SMB share Window-store — boilerplates, ISOs, automation-pack)
│   ├── mac/                       1.7 GB   (SMB share mac-store — single TrueNAS ISO + .DS_Store files)
│   ├── mac-store/                 0        (empty; possibly leftover from a rename)
│   └── proxmox/
│       └── backup/                ~333 GB  (subvolume; bind-mounted to /export/p-backup; contains "dump/" and "snippets/")
├── R-tank/                        0        ← empty; possibly a typo/duplicate of r-tank/
├── windows-store/                 0        ← empty; orphaned share path?
└── .snapshots/                    metadata only (OMV-managed snapshots; see Section G)

Note the three top-level naming variants: r-tank/, R-tank/, windows-store/. Only the lower-case r-tank/ has content. The other two are 0 bytes and appear to be leftover from share name changes during initial setup.

s-tank (/dev/md1, 1.4 TB)¶

/srv/dev-disk-by-uuid-55cabf8d-.../
├── s-tank/                        1.1 TB   ← bulk of s-tank data
│   ├── proxmox/
│   │   └── ext-store/             ~1.0 TB  (subvolume; bind-mounted to /export/ext-store; contains "dump/", "images/", "private/")
│   └── recovery/                  ~875 GB  (Apple HDD ddrescue image: apple-1tb.img + .map + .log + .pid)
├── k8s-data/                      0        (empty subvolume, NFS-exported to 172.16.10.0/24 — unused VLAN)
└── k8sdata/                       0        (empty subvolume, NFS-exported to * — security issue from prior review)
    └── images/                    0        (empty)

Important: the 1.0 TB on s-tank/proxmox/ext-store is exactly what the orphan tracker (D:\PVE\orphaned-fast-disks-20260531-212124.txt) describes. Find inside s-tank: 43 .qcow2 files + 1 .raw (LXC 500) + the recovery artifacts. After Phase 2 cleanup brings fast reachable, deleting those files reclaims roughly ~561 GB allocated (less due to thin/sparse storage).

Also: s-tank/recovery/ holds the Apple HDD ddrescue artifact (~875 GB of the 1 TB image since 100% rescued). That is a deliberate kept artifact from session 1 — not orphan. Confirm with Kay whether it should be migrated to a smaller / external location, or stays here as the working copy until HFS+ triage is done.

Section C: NFS exports and bind mount complexity¶

/etc/exports:

/export/p-backup    10.0.10.5/24(fsid=38b6f4de-...,rw,subtree_check,insecure)
/export/ext-store   10.0.10.5/24(fsid=571b62cb-...,rw,subtree_check,insecure)
/export/k8s-data    172.16.10.0/24(fsid=8de24e7f-...,rw,subtree_check,insecure)
/export/k8sdata     *(fsid=38e9f5fc-...,rw,subtree_check,insecure)        ← SECURITY
/export             10.0.10.5/24(ro,fsid=0,root_squash,no_subtree_check)
/export             172.16.10.0/24(ro,fsid=0,root_squash,no_subtree_check)
/export             *(ro,fsid=0,root_squash,no_subtree_check)

/etc/fstab bind mounts (the actual implementation):

/srv/.../71c.../r-tank/proxmox/backup/    /export/p-backup    none bind,nofail 0 0
/srv/.../55c.../s-tank/proxmox/ext-store/ /export/ext-store   none bind,nofail 0 0
/srv/.../55c.../k8s-data/                 /export/k8s-data    none bind,nofail 0 0
/srv/.../55c.../k8sdata/                  /export/k8sdata     none bind,nofail 0 0

Mapping summary:

Export	Source subvolume	Network	Purpose today	Contents
`/export/p-backup`	`r-tank/proxmox/backup` (subvolid 267)	10.0.10.5/24	Proxmox vzdump target (Backup-NAS storage)	~333 GB of .vma.zst + .notes from old vzdump runs
`/export/ext-store`	`s-tank/proxmox/ext-store` (subvolid 257)	10.0.10.5/24	Proxmox VM disks (fast storage)	~1.0 TB of orphaned .qcow2 from destroyed VMs
`/export/k8s-data`	`k8s-data` (subvolid 339)	172.16.10.0/24	k8s persistent volumes for the destroyed VMs	empty (0 B)
`/export/k8sdata`	`k8sdata` (subvolid 353)	*`` (anyone)**	k8s persistent volumes	only an empty `images/` dir
`/export` (pseudo-root)	/	mixed	NFSv4 pseudo-root	read-only top-level

Both k8s-data and k8sdata exports are orphaned — the k8s clusters they served are destroyed. The 172.16.10.0/24 subnet referenced in k8s-data is not a current VLAN in any planning doc.

Section D: Samba shares and what is actually in them¶

Two SMB shares, both backed by r-tank/:

Window-store¶

path = /srv/dev-disk-by-uuid-71c8857b-.../r-tank/windows/
read only = no
guest ok = no
browseable = yes
vfs objects = btrfs shadow_copy2     ← Time Machine / "Previous Versions" via btrfs snapshots
shadow:snapdir = /srv/.../71c.../.snapshots/

Content (2.1 GB total, 5 items):

automation-pack/ (dir, kay-owned)
boilerplates-main/ (dir, kay-owned — git repo-style content)
proxmox-backup-server_3.0-1.iso (876 MB, 2023-08)
proxmox-mail-gateway_8.0-1.iso (1.18 GB, 2023-08)
rsa.txt (561 B)
.DS_Store cruft

mac-store¶

path = /srv/dev-disk-by-uuid-71c8857b-.../r-tank/mac/
read only = no
guest ok = no
browseable = yes
vfs objects = btrfs shadow_copy2     ← same shadow_copy2 setup

Content (1.7 GB total, just 1 real file):

TrueNAS-SCALE-22.12.3.3.iso (1.67 GB, 2023-09)
.DS_Store cruft

Observations¶

Both shares are tiny relative to the filesystem. 2.1 GB + 1.7 GB = ~4 GB on a 838 GB filesystem (less than 0.5% utilisation for the shares themselves; the remaining 333 GB is Proxmox vzdump backups).
mac-store is essentially one ISO file. Either delete or leave alone — it does no harm.
Window-store contains a mix of work artefacts (boilerplates, automation, ISOs). Worth a Kay pass to decide what's still useful.
No "Window-store" or "mac-store" credentials — valid users = (empty) means default user-group ACL applies. Anyone in the users group on the OMV side can read/write. The only user currently in users group is kay.
shadow_copy2 + btrfs is working — Samba is configured to surface btrfs snapshots as Windows "Previous Versions" and macOS Time Machine. Good for accidental delete recovery (within the snapshot retention window).

Section E: OMV plugins, scheduled jobs, notification config¶

Installed OMV packages (version 6.9.13-1, "Shaitan", OMV 6 on Debian 11)¶

Plugin	Version	Likely status
`openmediavault` (core)	6.9.13-1	core
`openmediavault-autoshutdown`	6.0.10	configured? unknown
`openmediavault-compose`	6.11.3	Docker compose plugin; unknown if any compose stacks are running
`openmediavault-diskstats`	6.0.5-1	disk stats monitoring
`openmediavault-keyring`	1.0.2-2	repo keyring
`openmediavault-omvextrasorg`	6.3.6	community plugin source — required for several of the above
`openmediavault-sharerootfs`	6.0.3-1	enables sharing of OS root partition
`openmediavault-tgt`	6.0.4	iSCSI target; unknown if configured
`openmediavault-usbbackup`	6.0.5-1	USB backup; potentially valuable for cheap offline backup, see Section I
`openmediavault-zfs`	6.0.14	ZFS plugin; no ZFS pool exists

Notifications (config.xml `<notification>` block)¶

All these notification types are enabled:

monitprocevents, monitloadavg, monitmemoryusage, monitcpuusage, monitfilesystems
mdadm (RAID degraded / failed alerts)
smartmontools (SMART threshold alerts — note: drives are P410i-masked, so SMART doesn't actually work without ssacli)
cronapt (apt package update alerts)

But email delivery is DISABLED in config.xml:

<email>
  <enable>0</enable>      ← OFF
  <server/>                ← no SMTP server
  <port>25</port>
  <tls>none</tls>
  <sender/>
  <authentication>
    <enable>0</enable>
  </authentication>
  <primaryemail/>          ← no recipient
  <secondaryemail/>
</email>

Effect: all the "enabled" notifications go nowhere. mdadm could declare a drive failed tomorrow, smartmontools could see a sector reallocation spike, and nothing would alert anyone. The Proxmox-side vzdump job sends to [email protected] (different system, different email pipeline), but OMV itself is silent.

Snapshot scheduler (from .snapshots/ contents pattern)¶

Naming pattern <name>@weekly_YYYYMMDDT000001 strongly suggests OMV's built-in weekly snapshot scheduler is in use. Weekly snapshots happened from 2023-11-12 through 2024-03-24 (covering r-tank, mac-store, Window-store subvolumes), then stopped during the 15-month dormancy, then resumed 2026-05-31 at 00:00:01 (Window-store, r-tank, mac-store all snapshotted again).

So the scheduler IS running and IS taking snapshots, but only on r-tank's named subvolumes. No snapshots are being taken on s-tank. This is a substantial gap — the 1 TB of data on s-tank has no snapshot recovery path.

Cron jobs in /etc/cron.d/¶

Standard system jobs (anacron, e2scrub_all, mdadm, php, sysstat) + OMV jobs (mkrrdgraph, powermngmt, userdefined). No btrfs scrub scheduled — manual scrub at boot time is the only protection.

Section F: File type distribution (what kind of data is this)¶

r-tank: top file extensions by count¶

275  .yaml      \
260  .yml        |  ← config / IaC / k8s manifests (lots — almost certainly inside the vzdump backups
195  .log       |    of the destroyed k8s and mgmt VMs)
180  .zst       |  ← compressed (Proxmox vzdump output is .vma.zst)
180  .notes     |  ← Proxmox vzdump generates .notes alongside each .vma.zst
175  .tf        |  ← Terraform
 75  .md         /
 65  .sample   (git template files)
 45  .hcl      HashiCorp Configuration Language (Terraform/Vault)
 40  .DS_Store macOS cruft
 30  .cfg      Proxmox config (.conf snapshots)
 15  .iso      installation ISOs (in SMB shares)
 10  .tfvars / .tfstate (Terraform state)
 10  .exe / .html / .conf / .backup

Interpretation: r-tank holds Proxmox vzdump output from the now-destroyed k8s + mgmt cluster — including the contents of those VMs' filesystems (yaml/yml/tf/hcl/log/cfg artefacts visible because the vzdump indexes file types). The .vma.zst + .notes combo is the canonical Proxmox backup file pair.

Notable: the 165+ Terraform-related extensions hint at substantial IaC work that's preserved only in these backup files. If Kay still wants that material, it's recoverable by mounting the .vma.zst backups.

s-tank: top file extensions by count¶

43  .qcow2     ← VM disk images (37 orphans + 6 extra from before the inventory snapshot)
 1  .raw       ← LXC 500 rootfs
 1  .pid       \
 1  .map        |  ← Apple HDD ddrescue artifact (apple-1tb.img/.map/.log/.pid)
 1  .log        |
 1  .img       /

Interpretation: s-tank is overwhelmingly VM disk images (the orphans) and the recovery image. Almost no "normal user" data lives here. Consistent with prior expectation.

Section G: Compression, snapshots, deduplication¶

Compression — NOT enabled¶

Mount options: rw,relatime,space_cache — no compress=zstd / compress=lzo / compress=zstd:3
btrfs FS property: ro=false, label= (no compression hint at FS level)
Per-file: no transparent compression in effect

Opportunity (rough estimates, see Section I): - r-tank .vma.zst already zstd-compressed → marginal further compression at the btrfs layer - r-tank .notes/.yaml/.tf/.log/.hcl/.md (text content) → typically 60-70% reduction with zstd:3 - s-tank .qcow2 (mostly sparse but containing OS data) → modest reduction; sparse holes don't compress further, but the contained data does

Snapshots — partial coverage¶

r-tank: YES. Weekly snapshots per-share, managed by OMV. ~30 snapshots since 2023-11. Samba shadow_copy2 exposes them as "Previous Versions"/Time Machine.
s-tank: NO snapshots at all. The 1 TB of data has no point-in-time recovery within btrfs.

Deduplication — NOT in use¶

No bees, duperemove, or similar deduplication daemon installed
The bulk content (Proxmox backups, VM disk images, single ISOs) wouldn't dedupe well anyway

Scrubbing — manual only¶

No cron-scheduled btrfs scrub
Last scrub: 2026-05-28 at boot (OMV's boot-time auto-scrub), both filesystems clean, all errors 0

Section H: User accounts and ownership patterns¶

Real user accounts¶

kay (uid=1000, home=/home/kay, shell=/bin/sh)

Only one real user account. No additional users for family members yet — consistent with Path D not being live yet.

Group structure¶

The users group is the implicit access-control group:

Mode pattern: drwxrwsr-x (group sticky-write bit s) on all r-tank subdirs
Owner pattern: root:users

This means anyone in the users group can write to the shared folders, and the sticky-write bit ensures new files inherit users group ownership.

For Path D, when 3-5 family members are onboarded, each will need: - A Linux user account inside homeNas - Membership in the users group (or new per-family groups) - A Samba user/password (or Authelia → SMB integration if going that route)

Top-level ownership¶

r-tank/   root:users   drwxrwsr-x      ← shared, group-writable
R-tank/   root:users   drwxrwsr-x      ← empty leftover
windows-store/   root:users   drwxrwsr-x  ← empty leftover

s-tank/   root:root    drwx--x---      ← PRIVATE (root-only)
k8s-data/   root:users   drwxrwsrwx    ← world-writable (!), via NFS export
k8sdata/   root:users   drwxrwsrwx     ← world-writable (!), via NFS export

Note s-tank/ is private (drwx--x---, root-only). Effective control of read access goes through the bind-mount + subvolume layer, not the top-level. The s-tank/proxmox/ext-store subvolume is bind-mounted and exported normally.

Note k8s-data and k8sdata have drwxrwsrwx (world-write). This is sloppy on top of the already-sloppy * NFS export of k8sdata. If exposed to a network where any device can write, anyone could write garbage.

Section I: Specific improvement opportunities (NO new hardware required)¶

Tiered roughly by impact-per-effort. All are read/write changes that should be staged separately and reviewed.

Tier 0 — Hygiene + security (low effort, low risk)¶

Fix /etc/exports: change /export/k8sdata * to either a specific subnet or remove. Same finding as the previous storage review. Edit /etc/exports via OMV web UI or omv-salt deploy run nfs after editing the config DB; never directly (OMV regenerates).
Delete the empty k8s-data and k8sdata subvolumes + their bind mounts + their NFS exports. No data lost (they're empty). Removes confusing/orphan config.
Delete the empty R-tank/ and windows-store/ top-level directories on r-tank. No data lost. Stops the naming-collision confusion.
Delete the macOS .DS_Store files on the SMB shares. Cosmetic; ~50 KB freed.

Tier 1 — Reclamation (high impact, depends on Phase 2)¶

Delete the 43 .qcow2 + 1 .raw orphans on s-tank/proxmox/ext-store once fast is reachable again (Phase 2). Frees ~1 TB on s-tank. Already tracked in homelab-tracker Phase 4 + D:\PVE\orphaned-fast-disks-20260531-212124.txt.
Decide on the Apple HDD ddrescue image (apple-1tb.img, ~875 GB on s-tank/recovery). Options:
Keep until HFS+ triage is complete (homelab-tracker resume-checklist step 6) — natural
Migrate to external storage to free s-tank — if Kay has a target external drive
Delete (probably not — it's the only recovered copy)

Tier 2 — Compression + snapshot policy (moderate effort, ongoing benefit)¶

Enable compress=zstd:3 mount option on both filesystems. Edit /etc/fstab (or via OMV) to add the compress flag. Then re-mount or reboot. NEW writes are compressed. To compress existing files, run btrfs filesystem defragment -r -czstd <path> (this rewrites files — large IO operation; do during downtime).
Schedule weekly btrfs scrub on both filesystems. Currently only scrubs at boot. Add cron entries: btrfs scrub start <mountpoint> weekly. Light load (~2 min for s-tank SSD-backed, ~21 min for r-tank HDD-backed).
Add s-tank to the OMV snapshot scheduler. Currently OMV only snapshots the named r-tank subvolumes. Adding s-tank/proxmox/ext-store to the snapshot rotation (after the orphan cleanup so we're not snapshotting garbage) protects future VM disks from accidental delete.

Tier 3 — Monitoring + notifications (low effort, valuable)¶

Enable OMV email notifications. Configure SMTP relay (Gmail with app password, SendGrid, Postmark, etc.) in OMV web UI → System → Notification → Email. Set recipient to a live address. With this enabled, the existing mdadm/smartmontools alerts actually get delivered. Pair with Kay confirming [email protected] is alive (or switching to a different address).
Enable USB backup as a poor-person's off-site. The openmediavault-usbbackup plugin is installed. Pair with one of the Sabrent enclosures from session 1 (or buy a cheap external HDD): configure to backup r-tank/proxmox/backup/, the SMB shares, and (post-cleanup) s-tank/proxmox/ext-store/ to USB. Schedule weekly. Then physically rotate the drive between two locations. Crude but real off-site coverage until PBS + Cloudflare R2/B2 are operational.

Tier 4 — Plugin / cert hygiene¶

Uninstall unused plugins. Confirm with Kay what's not used:
- openmediavault-zfs — no ZFS pool exists; can be removed
- openmediavault-tgt (iSCSI target) — if no iSCSI in use
- openmediavault-compose — if no Docker compose stacks running
- openmediavault-autoshutdown — only useful if you actually want OMV to auto-power-off Reduces attack surface and update load.
Replace the OMV SSL certificate. Current cert has CN=10.0.70.11 (legacy VLAN 70 IP), expires 2027-11-13. When the network rebuild brings homeNas to its new IP, regenerate with proper SAN entries for both the new IP and the FQDN homenas.hm.iamkay.eu. Self-signed for now; eventually replace with Let's Encrypt via the architecture-locked DNS-01.

Tier 5 — Architecture (defer; multi-session)¶

Consider migrating from mdadm+btrfs to btrfs-native RAID during the eventual storage rebuild (when SSDs are replaced). Removes one layer of the nest doll. Requires data evacuation + recreation.
Consider replacing P410i with an LSI HBA in IT mode to unlock real drive SMART. Major hardware change; separate decision.

Section J: Items requiring user decision before any cleanup¶

TrueNAS ISO on mac-store — keep or delete? (1.7 GB freed if deleted)
Proxmox ISOs on Window-store — keep for future reinstalls, or delete? (2.1 GB)
automation-pack, boilerplates-main, rsa.txt on Window-store — still needed? Move to git, or leave on share?
R-tank/ and windows-store/ empty leftovers — delete? (Zero risk; zero gain other than clarity)
k8s-data/ and k8sdata/ empty subvolumes — delete subvolumes + exports + bind mounts? (Zero risk)
SMTP relay choice for OMV notifications — Gmail (Kay's existing account, requires app password), or a transactional sender (SendGrid/Postmark/Mailgun)?
USB backup target — would Kay buy a cheap external drive (or repurpose one of the Sabrent enclosures) for offline backup? If yes, what rotation cadence?
OMV cert regeneration timing — wait for VLAN 10 rebuild and use the new IP + FQDN, or regenerate now with both old and new?
apple-1tb.img retention — keep in s-tank/recovery/ until HFS+ triage, or migrate to external storage?
Plugin removals — which of zfs/tgt/compose/autoshutdown are actually wanted?
Compression policy — enable zstd:3 on r-tank and s-tank? Re-defragment existing files (large IO operation), or only compress new writes?
Snapshot policy on s-tank — add weekly snapshots after orphan cleanup is done?
Family-onboarding ACL design — when Path D family accounts are created, single shared users group, or per-family groups + per-share ACLs? (Affects how shares are configured before family upload.)

Appendix: Raw data files (on homeNas)¶

Collected to /tmp/omv-review-20260601-090058/ on homenas. 27 small files (~30 KB total). Includes per-filesystem btrfs filesystem df/usage/scrub status/device stats, mdadm --detail, smb.conf parsed shares, OMV config head, notification structure, full fstab + exports, file extension counts. These get cleared on next homenas reboot. If long-term retention is desired, scp to host /root/ or laptop D:\PVE\.

Report generated 2026-06-01 by read-only investigation of VM 189. No system state was modified. Counter-check recommendations with anything Kay knows that contradicts the data — particularly around what content on Window-store / mac-store is still useful, and whether the Apple HDD recovery image should stay on s-tank or move.