[Help] [TOS 7.0.0777] Storage Manager update failure (90%) - DB corruption in TOSDaemon & "Main volume does not exist" [SOLVED]

[Cimmerio]

[TOS 7.0.0777] Storage Manager update failure (90%) - DB corruption in TOSDaemon & "Main volume does not exist" GUI error - F6-424 Max

Hi TerraMaster Support Team and Forum Community,

I am opening this thread to report a critical issue that occurred after attempting to update the Storage Manager application from the TOS 7 Web GUI on a TerraMaster F6-424 Max.

[h]1. System Setup & Issue Description[/h]

• NAS Model: TerraMaster F6-424 Max
• TOS Version: 7.0.0777
• Storage Configuration:
  • Datastore01 (vg0 / lv0): 2x NVMe SSDs (1 TB) in RAID 1 (contains system structure and homes).
  • Datastore02 (vg1 / lv1): 6x HDDs (20 TB) for mass storage.
• Symptom: The Storage Manager app update froze at 90%. After waiting and rebooting the NAS, Storage Manager failed to launch, and the Web GUI threw the following persistent floating error:

  Update failed! The main volume {the volume where homes is located} does not exist. Please check whether the storage configuration is abnormal.

[h]2. CLI / SSH Diagnostics[/h]
I accessed the NAS via SSH as root to inspect the underlying storage layer:

1. Physical Drive Detection: All drives (2x NVMe sdza/sdzb and 6x HDDs sda-sdf) are detected properly by the kernel (

Code: Select all

lsblk

).
2. RAID & LVM Status: Running

Code: Select all

mdadm --assemble --scan

and

Code: Select all

vgchange -ay

successfully brings all RAID arrays and LVM Volume Groups (vg0, vg1, vg2, vg3) back to ACTIVE state.
3. Btrfs Filesystem Integrity: Running

Code: Select all

btrfs subvolume list

confirms that all subvolumes and shared folders are intact inside the @ directory (@/homes, @/DataStore01, @/DataStore02, @/Plex, etc.). All user data is completely safe.

[h]3. TOSDaemon Stack Trace / Log Errors[/h]
When trying to manually restart

Code: Select all

/usr/sbin/TOSDaemon

via SSH, the process enters an error loop and outputs Go database/GORM parsing exceptions:

Code: Select all

time=2026-07-23T09:51:05.802+02:00 level=WARN msg="[config backup] register fail:group id is empty" 
!BADKEY="goroutine 14 [running]: ... gitlab.local/ZiRunHua/confRegister/internal/service.(*RegisterServer).registerFail ...

[error] failed to parse field: GroupList, error: unsupported data type: &[]
DEBUG /bin/bash -c systemctl status DockerEngine.service
[error] failed to parse field: GroupList, error: unsupported data type: &[]

It appears the interrupted 90% update corrupted the internal PostgreSQL/SQLite configuration database on the system partition (/dev/md9), preventing TOSDaemon from parsing user/group tables and failing to execute auto-mount scripts for Btrfs subvolumes in the Web GUI.

[h]4. Question / Request for Advice[/h]

1. Is there a CLI command or database repair script to fix the TOS internal DB schema without rewriting the OS partition?
2. Or is it recommended to perform a Hot-Swap OS reinstallation keeping original data by removing drives, booting empty, re-inserting drives, and applying the TOS 7 .ins package?

Thank you in advance for your support!

[TMzethar]

Sorry you're having trouble with the Storage Management update. This should help:
viewtopic.php?t=10354

[Cimmerio]

Solved, Thanks!