[7.3.1] Mover can relocate share data into rootfs via stray /mnt/<pool> dir

Expected Behavior

Before moving array→pool for a yes/prefer share, the mover verifies the target is a real mounted pool — e.g. mountpoint -q "/mnt/$shareCachePool", or validation against the defined pools config — and skips the share with a syslog warning if not. Array data is never relocated onto the RAM backed rootfs.

Actual Behavior

The mover's only validity check is a bare directory test. From stock /usr/local/sbin/mover (7.3.1) — the -d test appears in both the "yes" branch (line 54) and the "prefer" branch (lines 73/78):

if [[ -n $shareCachePool && -d "/mnt/$shareCachePool" ]]; then

-d is true for any directory, including a plain (unmounted) directory on rootfs, which on a poolless system is RAM (tmpfs). Such directories appear without any user shell action: dockerMan auto creates a template's host path at container start, so a single stale template referencing /mnt/cache/... arms this on any poolless box.

Once the directory exists, every scheduled mover run relocates share files from the array into RAM (copy + delete source). Everything moved is silently destroyed at the next reboot. In my incident, damage was limited only by accident: in-use files are skipped and large copies fail as tmpfs fills — small, closed files (configs, DBs of stopped containers) are exactly what gets eaten. With mover logging off (the default) there is no trace of any of it.

Even granting the "no stray folders under /mnt" doctrine: the mover is the component that converts a benign stray directory into silent destruction of array data. A one line mountpoint check removes the destruction regardless of how the directory got there.

Steps to Reproduce

1. System with no pool named "cache"; a share (e.g. appdata) with shareUseCache="prefer", shareCachePool="cache" (the pre-7.0 default, still carried by upgraded installs).

2. mkdir /mnt/cache (or start any container whose template has a /mnt/cache/... host path)

3. stat -f -c "%n -> type=%T fsid=%i" /mnt/cache/

4. Place a closed test file in /mnt/disk1/appdata/movertest/

5. Run: mover start

6. The file is now under /mnt/cache/appdata/movertest/ (verify RAM: stat -f -c %T /mnt/cache → tmpfs) and gone from disk1. Reboot: the file no longer exists anywhere.
   

Additional Context

Verified against the stock 7.3.1 /usr/local/sbin/mover. No mover modifying plugins installed (ca.mover.tuning not present). Share .cfg files date to the 6.12 era (upgraded install) — legacy prefer/cache defaults on a system where /boot/config/pools/ is empty.

Workarounds

- Set affected shares to Primary: Array / Secondary: None (or actually create the pool they name).

- Remove any plain directory squatting at /mnt/<poolname> — rescue its contents first; they are in RAM.

- Fix container templates with direct /mnt/<pool> host paths.

- Enable mover logging (Settings → Scheduler → Mover Settings) so any recurrence is visible; disable the mover schedule until share configs are corrected.

Screenshots / Videos / Diagnostics

Attached diagnostics — captured 2026-07-03, ~1 hour I encountered this problem: it preserves the pre-incident share configs (prefer/cache on appdata/system/domains, /boot/config/pools/ empty). The system has since been repaired.