TOS 7.0.1278 (x86) Official Release Update

[Crashoveride]

Please perform the following verifications:

1. MTU verification: Change the MTU from 8192 to 1500 to determine whether the issue is related to Jumbo Frame configuration;
2. Link speed verification: Confirm whether the issue occurs only at 5Gbps, and test whether the same problem reproduces at 2500Mbps and 1000Mbps.

Both suggested checks failed. The problem is not EEE, not jumbo frames, and not 5Gbps. After a link partner disappears, both r8169 ports come back with link up, but the data path stays dead until the NAS is rebooted.

Tested on F2-425 Plus, TOS 7.0.1278, Intel N95.
eth0: 192.168.1.100/24 to the router, MAC 6c:bf:b5:05:4d:26
eth1: 10.10.10.1/24 direct to a Mac mini M4 via a bus-powered Thunderbolt 5GbE adapter, MAC 6c:bf:b5:05:4d:27

1. EEE off did not fix it.
ethtool --set-eee eth1 eee off was still disabled the next morning. After the Mac was powered off overnight, ping 10.10.10.1 failed with 100% loss. ethtool showed Speed 5000Mb/s, Duplex Full, Link detected yes. arping from eth1 got 0 responses. dmesg only had "Link is Down" and later "Link is Up - 5Gbps/Full", with no MAC/PHY error.

2. MTU 1500 did not fix it.
Both sides were set to MTU 1500, EEE still disabled. The next morning ping 10.10.10.1 failed again. eth1 was still mtu 1500, EEE disabled, link up at 5000Mb/s.

3. 1000Mbps did not fix it.
eth1 was forced to 1000Mbps full duplex on both sides, EEE still disabled. The next morning:

Code: Select all

ifconfig en10
media: 1000baseT <full-duplex>

ping 10.10.10.1 from the Mac: 100% packet loss. No interface reset was done before the test.

4. eth0 fails the same way after a short link down.
The router reboots on a schedule every Tuesday at 03:00. After that reboot the router port still showed link up at 5000Mbps full duplex, but the NAS was not seen as a client: active no, rx/tx 0 bytes, no new DHCP request from 6c:bf:b5:05:4d:26. 192.168.1.100 did not answer.

This morning both paths were dead at the same time, so SSH was impossible and ip link down/up could not be run. Only a NAS reboot recovered both ports. After reboot eth0 and eth1 are up at 5000Mbps full, and ping works on 10.10.10.1 and 192.168.1.1.

Please check the r8169 MAC re-init on link-up for both 0000:02:00.0 eth0 and 0000:03:00.0 eth1. The PHY reports link up, but the port does not pass traffic until the interface is reopened or the NAS is rebooted.

[EriChan]

Thank you very much for your thorough and methodical testing! Ruling out EEE, MTU, and 5G rate negotiation, while confirming that both eth0 and eth1 experience the exact same link stall after the upstream peer reboots, provides invaluable diagnostic data.

We have forwarded your complete test results, logs, and troubleshooting steps directly to the relevant team for in-depth analysis and issue reproduction.

If convenient, please navigate to TOS Desktop > Support & Help > Issue Report to generate and download a system report, and email it to our technical support team at support(at)terra-master.com to assist with further investigation. Please remember to include this forum thread URL and your forum username in the email.

Thank you again for your patience and support!

[Alak]

J'ai une question certainement stupide sur TOS 7 mais...

Voilà, pourquoi suis-je obligé d'inclure le compte "Guest" au groupe des administrateurs pour avoir un accès sur des TV (GoogleTV, android) et que cela ne soit pas refusé par l'appareil ? Dans les droits individuels de "Guest", j'ai configuré des accès en lecture seule sur certains dossiers. Mais si ce compte invité est uniquement ajouté au groupe "AllUsers" (ce qui serait pourtant logique...) et pas à "Admin", j'ai systématiquement une erreur sur le téléviseur de lecture des contenus stockés sur mon NAS. A noter que tous les échanges utilisent le protocole SMB.

Autre remarque concernant Surveillance Manager : Si je réalise une mauvaise configuration qui sature le disque de stockage réservé, cette application ne me propose pas de reconfigurer ou de rectifier. Elle ne me propose pas non plus de supprimer les plus anciens enregistrements et de rectifier la configuration de mes caméras. Non, elle fait alors disparaitre toute la configuration de toutes les caméras ! Seule solution pour s'en sortir : supprimer manuellement des fichiers sur l'espace de stockage configuré et redémarrer le NAS. Alors seulement je retrouve à nouveau toutes mes caméras et je peux enfin ajuster les paramètres.

Franchement, j'ai pensé que j'allais devoir en passer par une reconfiguration totale. Heureusement, la disparition des caméras n'était que visuelle et la configuration toujours présente.

Bien cordialement à vous

PS : Notez que ces deux petites remontées ne sont pas bloquantes puisque des solutions de contournement existent. Mais, à mon sens, elle sont illogiques et stressantes et j'ai mis pas mal de temps à comprendre pourquoi Kodi sur androidTV me refusait l'accès à une vidéo de vacances pourtant présente dans ma médiathèque ou pourquoi brusquement je ne retrouvais aucune caméra lorsque je voulais visualiser mon domicile sur surveillance manager.

[vitali]

How to install OpenClaw? I have F4-424 with fresh TOS 7.0.1278. Also I configured custom ports for http and https. I installed OpenClaw application via Application Center, but when I click on it - it always open a window with "500 Internal Server Error" message. What should I do? Is it really Beta or just a first try without any testing?

[CursaYang]

Merci de nous avoir transmis des retours détaillés ainsi que les résultats de vos tests.

Concernant le problème d'accès SMB, nous avons bien pris en compte le fait que lorsque le compte Invité n'est ajouté qu'au groupe AllUsers avec des droits de lecture seule sur les dossiers partagés, l'accès reste impossible sur Google TV et Android TV, tandis qu'un accès fonctionnel est possible après ajout de ce compte au groupe Admin. Nous procéderons à des vérifications approfondies concernant les permissions des groupes d'utilisateurs SMB dans TOS, le mappage des listes de contrôle d'accès (ACL) ainsi que la compatibilité SMB des téléviseurs.

Concernant le Surveillance Manager, lorsque l'espace de stockage est totalement épuisé, le système doit normalement afficher une invite claire et traiter les enregistrements conformément à la politique d'enregistrement configurée, et non pas provoquer la disparition des caméras paramétrées de l'interface. D'après vos résultats de test, la configuration des caméras a été restaurée après la suppression partielle des enregistrements et le redémarrage du NAS, ce qui signifie que la configuration est probablement toujours conservée. Le problème est plus vraisemblablement lié à l'état des services ou au chargement de la configuration suite à l'épuisement de l'espace de stockage.

Nous transmettrons ces deux problèmes au service R&D pour une vérification complémentaire. Merci encore de nous avoir communiqué ces informations, qui nous sont très précieuses pour le diagnostic du problème.

Thank you for providing detailed feedback and test results.

Regarding the SMB access issue, we have confirmed that when the Guest account is only added to the AllUsers group with read-only access to shared folders, it remains inaccessible on Google TV and Android TV, while normal access works properly once it is added to the Admin group. We will conduct further checks on TOS's SMB user group permissions, ACL mapping, and TV-side SMB compatibility.

Regarding the Surveillance Manager, when storage space is fully exhausted, the system is supposed to send a clear prompt and process recordings according to the configured recording policy, rather than causing configured cameras to disappear from the interface. Based on your test results, the camera configuration was restored after you deleted partial recordings and restarted the NAS, which indicates that the configuration is likely still retained. The issue is more probably related to service status or configuration loading after storage exhaustion.

We will submit both issues to the R&D team for further verification. Thank you again for providing this information, which is highly valuable for troubleshooting.

[CursaYang]

How to install OpenClaw? I have F4-424 with fresh TOS 7.0.1278. Also I configured custom ports for http and https. I installed OpenClaw application via Application Center, but when I click on it - it always open a window with "500 Internal Server Error" message. What should I do? Is it really Beta or just a first try without any testing?

Hello, please be assured that this is not an issue caused by OpenClaw.
Our investigation confirms that the root cause is the system's authentication service not operating properly, which prevents the application portal from completing identity verification.
We have developed a fix for this: you need to rebuild and restart the service. Once the operation is complete, refresh the page to access the application as normal. This issue will not affect any of your stored data.

Please execute the following commands in your terminal:

Code: Select all

printf '[Unit]\r\nDescription=Start twm_authentication service\r\nWants=TOSDaemon.service\r\nAfter=TOSDaemon.service\r\n\r\n[Service]\r\nType=exec\r\nExecStart=/usr/sbin/twm_authentication\r\nRestart=always\r\nRestartSec=1\r\n\r\n[Install]\r\nWantedBy=tnas-system.target\r\n' \
> /lib/systemd/system/twm_authentication.service

Code: Select all

systemctl daemon-reload

Code: Select all

systemctl enable --now twm_authentication.service

[vitali]

This fixed the issue, thank you!

[Alak]

Merci de la prise en compte ! Notez bien que pour surveillance manager, il s'agit à l'origine d'une erreur de ma part : Dans"stockage" j'ai limité la durée d'enregistrement à 5 jours et au-dessous, dans l'espace alloué, j'ai indiqué une capacité, qui cumulée avec toutes les caméras, est supérieure à la capacité physique du disque visé. Ce sont des test préliminaires et j'ai pensé qu'il y aurait une rotation des enregistrements dés les cinq jours enregistrés. J'ai depuis rectifié le tir en prenant garde à ce que l'addition de la configuration de chaque caméra ne dépasse pas la capacité physique du disque .

Je tenais à le redire : l'erreur d'origine venait de moi. Mais la réaction à la saturation (qui était prévisible) m'a surpris, puisque je n'ai plus eu aucune vision pour reparamétrer.

[EriChan]

Thank you for the follow-up and the extra details!
The abnormal behavior of Surveillance Manager when reaching storage limits or threshold states is indeed an issue worth investigating and optimizing. We will synchronize this information with our R&D team for further review.

[CraftyClown]

I’m experiencing serious stability and external storage issues with my F4-424 Pro following an upgrade from TOS 7.0.1163 to TOS 7.0.1278


**Hardware configuration**

- NAS: TerraMaster F4-424 Pro
- Two D5-300 USB storage enclosures, both using software RAID5 managed by TOS
- D5 #1: Five 16TB drives — Volume4
- D5 #2: Five 4TB drives — Volume5
- Four internal HDDs
- NVMe SSD containing applications and Docker configuration

**Problems experienced**

Following the update to 7.0.1278, the NAS began experiencing severe system lockups.

Symptoms included:

- TOS becoming unresponsive or failing to load applications.
- SSH connections hanging or timing out.
- Multiple processes becoming stuck, including TOSDaemon and Samba.
- Repeated kernel watchdog soft-lockup errors.
- Volume5 unexpectedly switching to read-only.

Several forced restarts were necessary when the NAS stopped responding.

**Troubleshooting performed**

I isolated the external enclosures to identify the problem.

With only the first D5-300 connected, the NAS booted successfully, Volume4 mounted read-write, and the system remained responsive without kernel errors.

After reconnecting the second D5-300, both RAID arrays assembled successfully. However, Volume5 initially mounted read-write and then switched to read-only following Btrfs write failures.

The kernel recorded the following:

```
BTRFS error (device dm-1):
bdev /dev/mapper/vg2-lv4 errs: wr 10

BTRFS: error in btrfs_commit_transaction:
errno=-5 IO failure
(Error while writing out transaction)

BTRFS info (device dm-1 state E):
forced readonly

BTRFS error (device dm-1 state EA):
Transaction aborted (error -5)
```


The second RAID itself reported:

- RAID5, five active drives
- State: clean
- Failed devices: 0
- All five drives operational
- Block device not marked read-only

Shortly afterwards, the kernel began reporting soft lockups involving `smbdconf` and `TOSDaemon`, and the NAS became unresponsive again.


It appears that there is an issue with having two external enclosures connected at the same time! Is this something that you are aware of?


If there isn’t a quick fix for this, is there a way for me to downgrade back to TOS 7.0.1163?