I looked a little deeper into the problem I had
earlier with launching Docker containers. Below is my conclusion, in collaboration with llm
***
Subject: Critical Bug Report: Docker bind-mounts fall back to rootfs (/dev/md9) during boot, risking system partition exhaustion.
Dear TerraMaster Support Team,
I am reporting a critical boot sequence race condition in TOS that affects Docker containers after a system reboot. This issue appeared after a recent TOS update.
1. Hardware & Environment:
Device: F4-424 Pro
OS: TOS 7
Storage: Multiple internal BTRFS volumes across different LVM volume groups (vg0 to vg4).
2. Symptoms:
After a cold boot, multiple Docker containers (Homepage and Jellyfin) start in a severely degraded state due to incorrect path resolution:
A) Homepage Container:
Incorrect Disk Space Reporting: Paths that should point to large BTRFS volumes incorrectly fall back to the system root partition.
Expected: Mounts pointing to /dev/mapper/vgX-lvX (1.8T - 20T volumes)
Actual after cold boot: Paths like /mnt/hdd2, /mnt/hdd3, /mnt/hdd4 point to /dev/md9 (7.4G system partition)
Screenshots with "df -h" output:
B) Jellyfin Container:
Critical Mount Fallback: Similar behavior where media paths fall back to rootfs.
Expected: /dev/mapper/vg2-lv2 20T 19T 1.9T 91% /music
Actual after cold boot: /dev/md9 7.5G 3.4G 3.7G 48% /music
Playback Failure: Jellyfin throws FFmpeg exited with code 254 errors because actual media files are inaccessible.
Screenshots with "df -h" output:
C) System Stability Risk:
Since these containers actively write data (caches, logs, metadata, transcodes) to these paths, this fallback behavior poses an immediate risk of filling up the 7.5GB system partition (/dev/md9), which can cause the entire TOS to crash or become read-only.
Note: Manually restarting the containers 1–2 minutes after boot fully resolves the issue, confirming this is strictly a timing/mounting sequence problem.
3. Root Cause Analysis (Evidence from "dmesg -T" and Docker behavior):
The Docker service is not configured to wait for all user volumes to finish their mount sequence. Volumes 3, 4, and 5 experience significant mounting delays relative to the base system initialization.
Here is the exact timeline from a fresh boot log:
09:30:47 – Volume 1 (vg0-lv0) mounted.
09:30:49 – Volume 2 (vg1-lv1) mounted.
(~48-second system stall occurs here, during which TOS scripts repeatedly overwrite smartmontools.service symlinks).
09:31:37 – Volume 3 (vg2-lv2) mounted.
09:31:57 – Docker network interfaces (docker0, br-*) initialize, and containers (including Homepage and Jellyfin) begin starting.
09:32:22 – Volume 4 (vg3-lv3) finally mounts.
09:32:23 – Volume 5 (vg4-lv4) finally mounts.
The full dmesg output -
https://dropmefiles.com/Fy6R8
Conclusion: Because containers start before the target volumes are fully mounted, the host paths do not yet exist as mount points. Docker's default behavior is to create a fallback directory on the host's current filesystem, which is the root partition (/dev/md9).
4. Steps to Reproduce:
Configure multiple internal storage volumes (e.g., Volume 1 through Volume 5).
Set up Homepage and/or Jellyfin Docker containers with bind-mounts pointing to directories on Volume 3, 4, or 5.
Enable "Start on boot" for these containers.
Reboot the NAS.
Execute "df -h" inside the running containers shortly after boot. Mounts will point to /dev/md9 (rootfs) instead of the correct /dev/mapper/vgX-lvX volumes.
***
I hope this is the right approach and that it will help solve the problem.
i havent updated to 780 to give a chance for an email to come through