TOS 7.0.1188 (x86) Official Release Update

[CursaYang]

When you create a new shared folder in the Control Panel, a corresponding directory will be automatically generated under the `/Volume1` path.
Do you see that the newly created folder is directly mounted under the root directory `/` in the terminal?
You can check the actual mount and usage information with the following two commands:

Code: Select all

findmnt -T /Backuply

Code: Select all

df -hT /Backuply

[TMroy]

Could you tell us how you created the shared folder?
How did this shared folder get mounted under the root directory? Was it mounted there after a normal reboot?
Is /Volume1/ working correctly at this point? Is it displaying as expected?
When did you first notice this behavior, and which version of TOS were you using?
Did this occur in previous versions as well?
Is the issue reproducible?
Thank you for sharing more details — this will help us narrow down the problem.

[snapsh0t]

I skipped manually installing 7.0.1169 to see if I received the notification a week later which I did so that works.
So I manually installed 7.0.1188 which was successful. However, I have found a few issues:

The debug mode logs now default to Volume1\public\debug_log with no option to move it out of public. I used to have it under Volume1\logs\debug_log but this no longer seems possible.

This error in the log looks like something that should be fixed:

Code: Select all

Sep  8 17:57:40 NAS4 systemd[1]: /lib/systemd/system/tnas-mntdata.service:8: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.

Fake temperature readings for the HDDs are still being generated every 30 minutes:

Code: Select all

Sep  8 18:40:57 NAS4 smartd[1304]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 118 to 119
Sep  8 18:40:57 NAS4 smartd[1304]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 116 to 117

Sep  8 19:10:57 NAS4 smartd[1304]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 119 to 122
Sep  8 19:10:57 NAS4 smartd[1304]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 117 to 120

Sep  8 19:40:57 NAS4 smartd[1304]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 122 to 125
Sep  8 19:40:57 NAS4 smartd[1304]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 120 to 123

I'd be seriously worried if my HDDs really were at 120C!

[CursaYang]

There is currently no evidence in the SMART section proving that the hard drives have actually reached extremely high temperatures.
The logs more accurately indicate that the values of SMART Attribute 194 for /dev/sda and /dev/sdb are continuously fluctuating.
To determine the actual temperature, you need to cross-reference the hard drive model and the full output of smartctl -x.

[TMroy]

Thanks for flagging this. I understand your concern about a possible false reading from our system. Those values (125°C / 123°C) are far beyond any normal operating range, so I think it's absolutely worth investigating before taking action.

Just for clarity: the temperature shown in the logs comes from smartd, which is the standard smartmontools daemon. It doesn’t guess temperature — it reads SMART attribute 194 directly from each drive. So the software is reading the value the drive itself is reporting. That said, this does not always mean the physical temperature is really that high. Sensor misreadings or incorrect raw value decoding by some controllers/bridges can occasionally happen.

To help us rule out a software or system-level issue, could you try the following?
Run smartctl -a /dev/sda | grep -i temperature and smartctl -a /dev/sdb | grep -i temperature to see the raw values. Let me know if they match the 125°C / 123°C in the log.
Sometimes drives are connected through a USB-to-SATA bridge or an HBA that needs a device type parameter. Try smartctl -d sat -a /dev/sda and see if the reading changes.
Cross-check with an independent source: check the NAS BIOS/management interface, or use another tool such as hdparm -H /dev/sda or the drive vendor’s diagnostics utility.
If possible, do a physical check: power the system down, then carefully touch the disk's metal surface — not the circuit board. If it only feels warm, it's likely a sensor/reporting error. If it's painfully hot to the touch, then the temperature is likely real.
Please share the output of those commands and let us know what you find. If it does turn out to be actual heat, I’d strongly recommend keeping the system shut down until cooling is fixed, as the risk of drive failure is very high.

[angelor]

Good morning,
Given the continuous weekly updates of TOS7 and the various problems encountered by everyone (including myself) after the update, I would simply like to ask: is there a way to backup the entire system HDD/SSD (containing TOS7, APPs, configurations, VMs, etc...) before update with the new version? ....so in case of problems it is quick and easy to go back without having to reinstall everything from scratch.
Or, instead to perform a full HDD backup, maybe there is a another way to perform a only a minimal "system backup" that can be restored if the TOS7 update do not work......
Many thanks in advance.
Regards

[RyanYang]

1. ¿Este comportamiento es esperado por TOS?
This is not the expected behavior of TOS. This issue is more likely related to how you configured the backup path, possibly due to incorrect mapping. How did you set up the backup path in the plugin?

2. ¿Existe alguna configuración oficial para definir correctamente el volumen físico utilizado por una carpeta compartida?
Yes. In TOS, go to "Control Panel" > "Shared Folders". The list will clearly show which volume each shared folder is on. You can also open the directory in File Manager and copy its absolute path directly from the top path bar.

3. ¿Es un problema conocido?
This is not a known issue. No other users have reported this plugin writing data to the root directory. When using this plugin, as long as the "Backup Locations" path is set correctly when creating the backup, the backup data will not be written to the root directory. Keep in mind that in Linux, a path starting with / is an absolute path that points directly to the root filesystem. So when creating a backup task, you should not fill in /Backuply directly, otherwise the application will treat it as the root partition and write data there.

4. ¿Podría TerraMaster revisar por qué una carpeta compartida puede terminar utilizando la partición raíz en lugar de Volume1?
TOS is only responsible for providing the storage path for shared folders and does not actively map them to the root directory. Only applications, containers, plugins, or manually executed commands will actually operate on those paths. If the backup data ends up in the root partition, you should check which step directed the path there.

5. ¿Existe una solución oficial que evite tener que utilizar un bind mount y un servicio systemd personalizado?
Based on available information, /Backuply is not the default storage path for Backuply. So the recommended approach is to use the full absolute path of your shared folder when creating backups, for example: /Volume1/Backuply. You can also try creating a "Backup Location" directly on the Backuply page and set the storage location to the absolute path of your shared folder during creation. This will eliminate the need for bind mounts and custom systemd services.

[OttO1916]

Both F2-221 and F5-221 updated to 7.0.1188
I noticed two issues on my F5-221:
- The description of some shared folders cannot be changed: operation failed
- All my rSync jobs are missing. When I recreate them 3 are added and started fine, but the 4th one starts running - and then all jobs disappear from the rSync screen.
They also stop running i guess, because no more LAN activity. System remains "sluggish"
The same symptons after a reboot
A configuration restore does not help, the jobs don't show up anymore. (Are job configs included in a config backup? )
It's kind of a nuiseance because i need them to update my archives on another TNAS.

[sianderson]

There is currently no evidence in the SMART section proving that the hard drives have actually reached extremely high temperatures.
The logs more accurately indicate that the values of SMART Attribute 194 for /dev/sda and /dev/sdb are continuously fluctuating.
To determine the actual temperature, you need to cross-reference the hard drive model and the full output of smartctl -x.

you have to admit a log that says "Temperature_Celsius changed from 122 to 125" is very misleading then?

[snapsh0t]

Thanks for flagging this. I understand your concern about a possible false reading from our system. Those values (125°C / 123°C) are far beyond any normal operating range, so I think it's absolutely worth investigating before taking action.

Just for clarity: the temperature shown in the logs comes from smartd, which is the standard smartmontools daemon. It doesn’t guess temperature — it reads SMART attribute 194 directly from each drive. So the software is reading the value the drive itself is reporting. That said, this does not always mean the physical temperature is really that high. Sensor misreadings or incorrect raw value decoding by some controllers/bridges can occasionally happen.

To help us rule out a software or system-level issue, could you try the following?
Run smartctl -a /dev/sda | grep -i temperature and smartctl -a /dev/sdb | grep -i temperature to see the raw values. Let me know if they match the 125°C / 123°C in the log.
Sometimes drives are connected through a USB-to-SATA bridge or an HBA that needs a device type parameter. Try smartctl -d sat -a /dev/sda and see if the reading changes.
Cross-check with an independent source: check the NAS BIOS/management interface, or use another tool such as hdparm -H /dev/sda or the drive vendor’s diagnostics utility.
If possible, do a physical check: power the system down, then carefully touch the disk's metal surface — not the circuit board. If it only feels warm, it's likely a sensor/reporting error. If it's painfully hot to the touch, then the temperature is likely real.
Please share the output of those commands and let us know what you find. If it does turn out to be actual heat, I’d strongly recommend keeping the system shut down until cooling is fixed, as the risk of drive failure is very high.

I will try those commands later but wanted to add that Storage Manager shows a much more realistic 25C to 30C.
The drives are currently a pair of WD 3TB Red EFRX. When I had the 18TB Red Pro in the NAS smartd reported temps around 60C but they were really at half that.