TerraMaster Forum

Target Users:
Users currently running TOS 7.0.0746 or later versions.

Note:
If your TOS version is TOS 6, please refer to the TOS 7 update instructions first.
Important: This update is only applicable to TOS 7.0.0746 and newer. Users with older versions must first upgrade to 7.0.0746 before applying this update.

Here, we sincerely thank @nitzer71, @Alak, @crisisacting, @ambul, @rfbjr, @Archivist, @apvm, @Pe6yc, @OlRedRooster, @merlin9876, @Gremlin, @sianderson and others for your sharing and feedback. Your support helped us quickly identify and fix multiple issues.

Release Notes:
This update adopts a phased gray release strategy to ensure stability across different device models and network environments.
Phase 1 (Starting Today): The manual update package is now available for download on our forum. It will be rolled out in batches based on system version, device model, and region.
Phase 2 (In One Week): The full online push will officially begin. At that time, all users will receive an update notification and can complete the update by following the on-screen prompts.

Update Notes
Bug Fixes:
1. Fixed the issue where the WiFi function was missing the regulatory database file.
2. Fixed the issue where File Manager could not properly preview images in TIFF (.tif / .tiff) format.
3. Fixed the issue where File Manager did not correctly display the current USB mount point in some cases.
4. Fixed the issue where the NTP server could not load multiple upstream nodes.
5. Fixed the issue where the status of an encrypted USB device might display abnormally and only return to normal after a refresh.
6. Fixed the issue where I/O errors of abnormal USB devices caused the Storage Manager to fail to retrieve data.
7. Fixed the issue where the app upload and decompression operations were not separated, which might cause upload anomalies under certain circumstances.
8. Fixed the issue where failure logs were not recorded when manual installation failed.
9. Fixed various other known issues.

Important Information:
1.Updating the system theoretically will not affect the data on your hard drives, but for safety, please make sure to back up your data in advance.
2.Before updating, ensure that your primary volume (usually volume1) has at least 3GB of available space. Insufficient storage space may cause the update to fail.
3.After the update, the IP address of your TNAS may change. Please use the TNAS PC desktop client to search for and reconnect to the device.

Update Procedure:
1.Download TOS 7.0.1188 update package (MD5: 351935166aa20ca621f4302205428537);
2.Go to TOS > Control Panel > General Settings > System > Update;
3.Select "Manual Update" and upload the downloaded update package file;
4.Follow the prompts to complete the update;
5.After the system update is complete, please refresh your browser;
6.The TNAS IP address may change after the update. If you cannot connect to your TNAS using the previous IP address, use the TNAS PC client to search for the new IP address;

Client Downloads:
1. Download TNAS PC 5.2.548 for Windows OS.
- MD5: 72701B52336AF9FD8B97A6BE9D5D5A7C
2. Download TNAS PC 5.2.548 for macOS (x86 architecture).
- MD5: BAA63A179C43F73965EA9C31EEB9D61E
3. Download TNAS PC 5.2.548 for macOS (ARM architecture).
- MD5: BB933DA867058884C4ADFE44EAD24AFC
4. Download TNAS PC 5.2.548 for Linux.
- MD5: 06FE93F9FFE47147854A34F28D57FCC2
5. TNAS mobile for Android: Please search for "TNAS mobile" in the app store to install.
6. TNAS Mobile for iOS: Please search for "TNAS mobile" in the App Store to install.

Добрый день. F4-425 Plus обновился, полет нормальный.

The update was successful, thank you.

pjarinov wrote: ↑08 Sep 2026, 13:58 Добрый день. F4-425 Plus обновился, полет нормальный.

День добрый. Portainer работает?

All four devices updated w/o issue.

Aucun souci de MAJ sur F4-424 avec mes usages personnels

Bravo !

Installed in stand-alone unit, free of issues.

Will await rollout for testbed devices; likely will push 7.0.1169 to production client units.

updated, F4-424 with two connected D4-320, seems no problem.

F8 SSD Plus (8x4TB NVMe, TRaid, 48GB, prod) actualizacion correcta
F8 SSD Plus (6x1TB+2x2TB, TRaid, 48GB, prod) actualizacion correcta
F4-424 Pro (2x22TB+2x10TB HDD +1TB+500GB NVMe, TRaid, 32GB, prod) actualizacion correcta
F2-423 (2x18TB, TRaid, 32GB, prod) actualizacion correcta
F2-221 (6TB+10TB, TRaid, 10GB, prod) actualizacion correcta
D1 SSD (2TB, prod) es reconocido por todos los dispositivos y montado perfectamente



Shared folder created/mounted in root filesystem instead of Volume1 – risk of filling the TOS system partition

Hola comunidad y equipo de TerraMaster.

Quiero reportar un comportamiento que encontré en dos de mis servidores TerraMaster y que considero importante revisar, ya que puede provocar que la pequeña partición del sistema TOS se llene.

En mi caso utilizo una carpeta compartida llamada Backuply, destinada a almacenar respaldos enviados desde otros servidores.

El problema que detecté fue que la carpeta compartida terminaba disponible en: "/Backuply"

pero, en mi configuración original, los datos escritos en esa ubicación estaban consumiendo espacio de la pequeña partición raíz de TOS en lugar de almacenarse correctamente dentro de Volume1.

La partición raíz de estos equipos es aproximadamente:
"/dev/md9
7.5 GB
Mounted on /"

mientras que el volumen de almacenamiento real es mucho más grande y está montado en: "/Volume1" En uno de mis servidores, por ejemplo, Volume1 tiene aproximadamente 7.3 TB, y en el otro aproximadamente 26 TB.

Esto representa un problema importante porque aplicaciones de respaldo como Backuply pueden escribir varios gigabytes o terabytes. Si esos datos terminan en la partición raíz de aproximadamente 7.5 GB, el sistema puede quedarse rápidamente sin espacio y potencialmente afectar el funcionamiento de TOS.

Comportamiento esperado

Al crear una carpeta compartida denominada, por ejemplo: "Backuply"
esperaría que físicamente los datos se almacenen dentro de: "/Volume1/Backuply"
aunque TOS presente o exponga la carpeta como: "/Backuply"

Es decir, /Backuply debería apuntar realmente al almacenamiento de Volume1 y nunca consumir la pequeña partición raíz del sistema.

Solución temporal que tuve que implementar:

Para evitar que Backuply continuara llenando la partición raíz, creé la carpeta físicamente en:
"/Volume1/Backuply"

y después utilicé un bind mount para mantener /Backuply como ruta visible para la aplicación:
"mount --bind /Volume1/Backuply /Backuply"
continuo en el. siguiente post>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

<<<<<<<<<<<<<<<<<<<< continuacion del anterior post

Como necesitaba que esta configuración sobreviviera a reinicios, creé además un servicio de systemd:
"[Unit]
Description=Backuply bind mount to Volume1
After=local-fs.target
Wants=local-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStartPre=/bin/mkdir -p /Backuply
ExecStartPre=/bin/bash -c 'for i in $(seq 1 120); do if findmnt -rn -T /Volume1/Backuply -o TARGET | grep -qx "/Volume1"; then exit 0; fi; sleep 2; done; echo "ERROR: /Volume1 no esta disponible" >&2; exit 1'

ExecStart=/bin/bash -c 'mountpoint -q /Backuply || /bin/mount --bind /Volume1/Backuply /Backuply'
ExecStop=/bin/umount /Backuply

[Install]
WantedBy=multi-user.target"

El servicio quedó habilitado con:
"systemctl daemon-reload
systemctl enable backuply-bind.service
systemctl start backuply-bind.service"

Después de implementar esta solución comprobé que:
"df -hT /Backuply /Volume1/Backuply"
muestra que /Backuply utiliza el mismo almacenamiento Btrfs de Volume1.

También confirmé mediante:

stat -c 'Device=%d Inode=%i Ruta=%n' /Backuply /Volume1/Backuply

que ambas rutas apuntan al mismo directorio de almacenamiento.

Por ejemplo, en uno de los servidores obtengo:

Device=48 Inode=256 Ruta=/Backuply
Device=48 Inode=256 Ruta=/Volume1/Backuply

y en el segundo servidor:

Device=63 Inode=256 Ruta=/Backuply
Device=63 Inode=256 Ruta=/Volume1/Backuply
El problema se presentó en dos servidores

Realicé este procedimiento en dos servidores TerraMaster diferentes, llamados internamente Kiara y Elena.

En ambos tuve que asegurar manualmente que:

/Backuply

apuntara realmente a:

/Volume1/Backuply

para evitar que los respaldos consumieran la partición raíz.

Además, recientemente actualicé el firmware de ambos servidores. Antes y después de la actualización verifiqué RAID, Btrfs, montaje de Backuply y el servicio systemd.

Los arreglos RAID permanecieron correctamente sincronizados y el bind mount continuó funcionando después del reinicio.

Por qué considero importante que TerraMaster revise esto

Una partición raíz de aproximadamente 7.5 GB puede llenarse extremadamente rápido si una aplicación escribe datos pensando que está utilizando una carpeta compartida del volumen de almacenamiento.

Para una carpeta utilizada para respaldos, esto representa un riesgo considerable.

Creo que TOS debería garantizar que cualquier carpeta compartida creada sobre Volume1 tenga su almacenamiento físico asociado a Volume1 y que nunca termine almacenando los datos directamente en la partición raíz del sistema.

Me gustaría saber:

¿Este comportamiento es esperado por TOS?
¿Existe alguna configuración oficial para definir correctamente el volumen físico utilizado por una carpeta compartida?
¿Es un problema conocido?
¿Podría TerraMaster revisar por qué una carpeta compartida puede terminar utilizando la partición raíz en lugar de Volume1?
¿Existe una solución oficial que evite tener que utilizar un bind mount y un servicio systemd personalizado?

Puedo proporcionar comandos, capturas, información de los montajes, df, findmnt, configuración de Btrfs y cualquier otro dato que necesite el equipo técnico para reproducir el problema.

Gracias.