TOS 7.0.1130 (x86) Official Release Update

[Nitrokalel]

porque un no se arregla el consumo de CPU y global serach tiene que se r actualizadao?
F8 SSD Plus (8x4TB NVMe, TRaid, 48GB, prod) uodate ok
F8 SSD Plus (6x1TB+2x2TB, TRaid, 48GB, prod) uodate ok
F4-424 Pro (2x22TB+2x10TB HDD +1TB+500GB NVMe, TRaid, 32GB, prod) update ok
F2-423 (2x18TB, TRaid, 32GB, prod) update ok
F2-221 (6TB+10TB, TRaid, 10GB, prod) update ok
D1 SSD (2TB, prod) is recognized

[kkay1961]

Hello TerraMaster Support,
I am reporting two issues that appeared immediately after installing a TOS 7 update on my TNAS. (7.0.1105)

NAS model: F4-425 Plus
Previous TOS version: 
Current TOS version: 7.0.1105
Kernel: 6.12.63+ #15
Date of incident: August 12, 2026
Time zone: EDT (UTC-4)

Before the update, I created this TOS configuration backup:

TNAS_TOS7_config_backup_20260812174224.bin

ISSUE 1: EXTERNAL USB DISK BLOCKED STORAGE INITIALIZATION

Immediately after the update, only Volume 1 was visible. After rebooting once, Volume 4 returned, but Volume 2 was displayed as:

“Volume corrupted”
Used: 0 B
Free: 0 B
Total: 0 B

The Storage Manager showed that the underlying hardware remained healthy:

* Storage Pool 3: Normal
* RAID 1
* Two of two disks present
* HDD3: WDC WD40EFPX-68C6CN0, 4 TB, Normal
* HDD4: WDC WD40EFPX-68C6CN0, 4 TB, Normal
* Expected pool capacity: 3.63 TB

Linux diagnostics confirmed that the RAID and filesystem were intact:

* `/dev/md1`: active RAID 1 with both members `[UU]`
* Logical volume: `/dev/mapper/vg2-lv1`
* Btrfs UUID: `50b54c0b-2fcb-48b7-83e0-02bc622c9a31`
* Btrfs data present: approximately 1.05 TiB
* No Btrfs read, write, flush, corruption, or generation errors

An external 8 TB USB disk was connected:

* Disk: Seagate ST8000DM004-2U9188
* Linux device: `/dev/sdf`
* USB/SATA bridge: Innostor Technology Corporation
* USB ID: `1f75:0611`
* USB path: `4-1.2`
* Connected through a Realtek USB 3.2 hub, USB ID `0bda:0423`

After the update, the kernel reset this USB device approximately once per minute:

`usb 4-1.2: reset SuperSpeed USB device number 3 using xhci_hcd`

TOS repeatedly launched SMART and ATA queries against `/dev/sdf`. Hundreds of `smartctl` processes and one `hdparm` process became blocked in uninterruptible `D` state, usually at `blk_execute_rq` or `blk_mq_get_tag`.

The external disk was not mounted and did not contain an active filesystem visible to `lsblk`.

The TOS storage-mount service timed out:

`tnas-mntdata.service: start operation timed out`

However, because the unit uses `KillMode=none`, the `mntdata` process continued running after systemd marked the service failed.

The critical timing was:

* 17:56:41 — TOS began mounting `/dev/mapper/vg2-lv1` as `/Volume2`
* 18:26:25 — External USB device `/dev/sdf` was physically disconnected
* 18:26:27 — TOS reported the Volume 2 mount successful

Relevant log:

`[mntdata] mntVolume /dev/mapper/vg2-lv1 -> /Volume2 success`

The mount completed approximately two seconds after disconnecting the external USB device.

Afterward:

* `/Volume2` mounted normally read/write
* Capacity: 3.7 TB
* Used: 1.1 TB
* Available: 2.6 TB
* All expected folders were present, including Photos, BackUps, Documents, lab, media-production, and syncthing
* RAID remained `[UU]`
* Blocked-process count returned to zero
* Btrfs device error counters were all zero
* Storage Manager no longer represented an actual filesystem failure

This indicates that the “Volume corrupted” warning was false. A hung USB SMART/ATA probe blocked the TOS mount process and prevented Volume 2 from completing its normal mount.

Please investigate:

1. Why TOS repeatedly launches additional SMART queries while previous queries against an unresponsive USB device remain blocked.
2. Why one malfunctioning external USB device can block unrelated internal RAID/LVM/Btrfs volumes from mounting.
3. Why Storage Manager labels this condition “Volume corrupted” instead of reporting a mount timeout or blocked external USB device.
4. Whether the updated kernel or SMART subsystem has a compatibility issue with Innostor USB-to-SATA bridge ID `1f75:0611`.
5. Whether `tnas-mntdata.service` needs a longer startup timeout, device-specific timeouts, or isolation from external USB probing.

ISSUE 2: SSSD FAILS BECAUSE TOS MAPS ROOT TO UID 9999

After the same update, `sssd.service` failed repeatedly:

`SSSD couldn't load the configuration database [5]: Input/output error`

System information:

* SSSD version: 2.6.3
* `/etc/sssd/sssd.conf` exists
* Owner: UID 0 / GID 0
* Mode: 600
* Configuration uses the local `shadowutils` domain
* `/var/lib/sss/db/config.ldb` was missing
* Root filesystem was read/write and showed no filesystem or I/O errors

TOS account mapping is:

* `TNAS`: UID 0, GID 0, interactive administrative account
* `root`: UID 9999, GID 9999, nologin account
* `sssd`: UID 122, GID 132

A root write test in `/var/lib/sss/db` succeeded, proving that the filesystem and directory were writable by UID 0.

A system-call trace of `sssd --genconf` showed:

`setresuid(-1, 9999, -1) = 0`
`setresgid(-1, 9999, -1) = -1 EPERM`
`openat(..., "/var/lib/sss/db/config.ldb", O_RDWR|O_CREAT, 0666) = -1 EACCES`

SSSD appears to resolve the username `root` to TOS UID 9999, drop its effective UID to 9999, fail to change the group, and then lose permission to create `/var/lib/sss/db/config.ldb`.

Attempts to set `user = TNAS` in the `[sssd]` section could not resolve the bootstrap problem because SSSD must first open or create `config.ldb` before it can read that generated setting. A controlled bootstrap attempt also resulted in an SSSD segmentation fault, so no further modifications were made.

The original SSSD configuration was restored, all temporary files were removed, and the failed status was cleared. The NAS currently operates with local accounts, but SSSD remains a reproducible packaging/account-mapping issue.

Please investigate whether the TOS SSSD package or service needs to be patched so it uses UID 0 directly, the `TNAS` account, or the dedicated `sssd` account rather than resolving the name `root` to UID 9999.

CURRENT SYSTEM CONDITION

The NAS is currently stable:

* Volume 1 mounted read/write
* Volume 2 mounted read/write
* Volume 4 mounted read/write
* Both two-disk RAID 1 arrays show `[UU]`
* No blocked processes
* Btrfs error counters for Volume 2 are all zero
* `mediadb.service` is active
* `mediaindex.service` is active
* No failed services are currently listed after clearing the unused SSSD failure state
* The external USB disk remains disconnected
* No Btrfs repair, RAID rebuild, formatting, or configuration restoration was performed

I can provide screenshots, complete `dmesg` output, `journalctl` output, the `strace` excerpt, storage layouts, and additional diagnostics if needed.

Thank you,
Kevin

[apvm]

Updated and no problem yet with F4-424, only thing I am trying to solve is I attached a Seagate Expansion usb drive to F4-424 but there is no shared volume, I can only access it via my PC to write files to it but F4-424 have no volume or shared folder for it so Plex can't see the files.

[EriChan]

To help us quickly pinpoint and resolve the issue, please send the system report (via TOS > Technical Support > Submit Feedback) along with any other relevant files to [email protected] for further review.

[EriChan]

Once you connect an external storage device to the NAS, you can access, read, and write files directly by going to TOS Desktop > File Manager > External Storage.

Regarding the issue where media applications like Plex cannot read data from external USB drives, we have confirmed this limitation/issue. We plan to optimize and improve this in a future update to allow applications proper access to USB drives.

Thank you for your understanding and patience!

[DCCentR]

Cant enable VMs after updating it to v1.0.057 on TOS 7.0.1130, system restart didn't help.

tail -n 300 /var/log/syslog: https://pastebin.com/raw/P7rV91jQ

[EriChan]

Based on the logs you provided, several essential binaries and service scripts under /usr/local/VMs/bin/ (such as libvirtd, virtlockd, redis-server, and ensure-prereq.sh) are missing (No such file or directory). This indicates that the package extraction or installation was incomplete during the update process.

To resolve this issue:

1. Go to App Center, uninstall the VMs application (make sure NOT to check the option to delete all configuration files).

2. Reinstall the VMs application from the App Center and enable it again.

(Note: Your existing virtual machine disk images and configurations will remain safe).

If the issue persists after reinstalling, please let us know!

[DCCentR]

Based on the logs you provided, several essential binaries and service scripts under /usr/local/VMs/bin/ (such as libvirtd, virtlockd, redis-server, and ensure-prereq.sh) are missing (No such file or directory). This indicates that the package extraction or installation was incomplete during the update process.

To resolve this issue:

1. Go to App Center, uninstall the VMs application (make sure NOT to check the option to delete all configuration files).

2. Reinstall the VMs application from the App Center and enable it again.

(Note: Your existing virtual machine disk images and configurations will remain safe).

If the issue persists after reinstalling, please let us know!

Thanks, reinstalling the program helped.

I have another question about VMs: for some reason, the LAN1 interface is always duplicated in there. Is that normal?


That's how it's been in all versions of the program/TOS7, as far as I can remember.

[EriChan]

We appreciate your feedback. The issue has been confirmed and passed to our product team for assessment in a future update.

[storageninja]

NTP issue still present in TOS 7.0.1130

After updating to TOS 7.0.1130, the previously reported NTP issue still appears to be present. The NAS continues to select LOCAL(0) instead of an external NTP server, even though the external servers are reachable.

Code: Select all

ntpq -p

shows:

Code: Select all

*LOCAL(0)

Could you please confirm whether the NTP issue is not yet fixed in TOS 7.0.1130 and is still planned for a future update?

That could be quite catastrophic over time. I use the NAS as local time source I need to remove that because its indeed not syncing externally.

Code: Select all

ntp       102815  0.0  0.0  76172  6488 ?        Ssl  21:41   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u ntp:ntp

There seems no configuratie path given via -c ...