TerraMaster Forum

AES wrote: ↑26 Apr 2026, 06:42

We need to check this issue remotely. Please find the online customer service by the entrance at the bottom right of the official website to schedule a time for the remote session.

Some of the problems were resolved; the site settings in Google Chrome were to blame, because in incognito mode on another PC, everything suddenly worked, and after resetting the site settings, it worked on the main Mac as well.

The only thing left to figure out is the Surveillance autostart/autoload issue.

I hope a remote support session will resolve this.

AES wrote: ↑28 Apr 2026, 03:56

Hi, our engineer was working remotely on you today. Since you were not on-site, the remote process was interrupted and we were unable to continue. We have left you a message in the online chat room. Please check and reply to it. We will conduct another remote investigation at your convenience.

Feedback on TOS 7: Improving SSH persistence and Surveillance Manager stability

Hello TerraMaster Team,
I have been using the new TOS 7 on my F8-series NAS, and while I appreciate the new features, I would like to share some constructive feedback regarding a few technical issues I’ve encountered. I hope this information will help your developers make the system even more stable.
1. SSH Host Keys Persistence:
Currently, it seems that SSH host keys are regenerated after every firmware update. This causes a "Remote Host Identification Changed" warning on client devices (like macOS/Linux). It would be great if the /etc/ssh/ keys could be preserved in a persistent partition to ensure a seamless connection for administrators after updates.
2. Volume Mounting and App Startup:
On systems with multiple high-speed NVMe drives, there seems to be a minor conflict with volume indexing after reboots (Volume numbers sometimes swap). This occasionally causes the Surveillance Manager to lose its path to binaries or databases.
3. Surveillance Manager Initialization:
I noticed that the Surveillance application sometimes attempts to start before the data volumes are fully ready. Adding a small delay or a "retry" logic to the service startup would greatly improve the user experience, as it would prevent the app from staying in a "Disabled" or "Error" state after a reboot.
Conclusion:
An AI assistant and I spent a considerable amount of time analyzing the system logs to understand these behaviors. We managed to find some manual workarounds using custom scripts to ensure the services restart correctly. Of course, since we don't have access to the full internal system code, we might be mistaken in some of our technical assumptions, but we wanted to share our findings anyway. We decided to post this on the forum to help your team address these points in future updates and make TOS even more robust for everyone.
Thank you for your hard work on improving TOS!
Best regards,
Anton
TerraMaster F8

AES wrote: ↑01 May 2026, 01:17

The questions and suggestions you raised have been recorded. The project team will discuss them one by one.
TOS7 will be better with the participation of you and other users like you.

AES wrote: ↑01 May 2026, 01:17 Feedback on TOS 7: Improving SSH persistence and Surveillance Manager stability

2. Volume Mounting and App Startup:
On systems with multiple high-speed NVMe drives, there seems to be a minor conflict with volume indexing after reboots (Volume numbers sometimes swap). This occasionally causes the Surveillance Manager to lose its path to binaries or databases.
TerraMaster F8

We have conducted tests in various scenarios based on your environment, but no similar anomalies have been found so far.
We will continue to keep an eye on it.
Do any two of your SSDs have the same SN?
If the issue is not related to the SN code of the SSD, you can consider scheduling a remote inspection with an engineer on the official website's Live Chat.