TerraMaster Forum

Hi all,

I'm running into a problem with Time Machine backups to a Terra Master NAS over SMB, and I'd like to check whether others have seen this or whether it's a known issue.

Setup
- NAS: Terra Master F4-SSD, TOS TOS7 1341, btrfs volume
- Client: MacBook M4 Pro, macOS 27.0.1
- Backup target: SMB share, Time Machine enabled on the share, with a size quota of 1500 GB set in TOS
- The Time Machine sparse bundle was originally created with a 16 TB virtual size, the default?

What happens
- Backups ran normally until the backup set reached about 1.5 TB on the NAS.
- After that, every backup fails with BACKUP_FAILED_TARGETVOL_DISK_FULL (56), underlying NSPOSIXErrorDomain Code=28 "No space left on device".
- The failure happens at the point where Time Machine opens the mount point, before any data is written:
MountPointValidity - open failed, error: 28 No space left on device
- Old backups are never thinned. The backup set stays above the quota indefinitely, so the problem persists.
- The same behavior happened earlier when the quota was 750 GB and I raised it.

What I checked
- Free space as reported on the client: df on the SMB mount shows about 3.1 TiB free, which matches what the NAS reports for the volume. So the free-space value that macOS sees is not wrong, and it does not show the quota at all.
- The sparse bundle on the NAS is about 1.4 TiB by du, which is what the quota counts against.
- The btrfs qgroup output shows no max_rfer or max_excl limits. So the quota is not a btrfs qgroup limit. It seems to be enforced by a layer in TOS that rejects writes with ENOSPC.
- The Time Machine sparse bundle reports 16 TB capacity internally, and the APFS container inside has ample free space. So the bundle itself is not full.

My reading
Time Machine decides whether there is room (and whether to thin old backups) based on the free space the destination reports. Because the quota is enforced at write/open time but is not reflected in that free-space value, Time Machine sees roughly 3 TB free. *It never starts thinning* and every backup fails at open with ENOSPC, which Time Machine reports as "disk full". As far as I can tell, the quota prevents the backup from ever reaching the point where thinning would run.

Questions
1. Is there a supported way to set a size limit on a Time Machine share on TOS that Time Machine can see (for example, a free-space value that reflects the quota)?
2. Has anyone got Time Machine to thin old backups automatically on a quota-limited share?
3. Is there a recommended approach for capping Time Machine size on Terra Master: remove the quota and reserve space another way, or manage thinning manually with tmutil?

Happy to run any diagnostics. Thanks.

F4-425 Plus as been upgraded well

Permissions for shared folders have become corrupted. Attempting to reset the permissions is futile; nothing changes, and the modifications are not applied. All applications that use the "multimedia" shared folder have stopped working following an update.

1inkman wrote: ↑23 Oct 2026, 04:50 Permissions for shared folders have become corrupted. Attempting to reset the permissions is futile; nothing changes, and the modifications are not applied. All applications that use the "multimedia" shared folder have stopped working following an update.

Hi. What version of the TOS were you using before the update?
In the shared folder permissions settings, there is an option labeled “App Users.” Is this the setting you tried to reset? Could you please specify which app you were using and describe exactly how it isn’t working properly?

TMzethar wrote: ↑23 Oct 2026, 09:51

1inkman wrote: ↑23 Oct 2026, 04:50 Permissions for shared folders have become corrupted. Attempting to reset the permissions is futile; nothing changes, and the modifications are not applied. All applications that use the "multimedia" shared folder have stopped working following an update.

Hi. What version of the TOS were you using before the update?
In the shared folder permissions settings, there is an option labeled “App Users.” Is this the setting you tried to reset? Could you please specify which app you were using and describe exactly how it isn’t working properly?

Hello. I am setting permissions for Jellyfin and Plex to "read-only," and for Transmission to "read/write." I apply these recursively to the directories, but the settings don't take effect—they remain set to "deny."

The previous version was TOS 7.0.1298. I am configuring these permissions under "App Users."

Upgraded my F4-SSD from 7.0.1298 to 7.0.1341 and it was not accessible afterwards. I had to power-cycle it to get it back.

1inkman wrote: ↑23 Oct 2026, 20:23 Hello. I am setting permissions for Jellyfin and Plex to "read-only," and for Transmission to "read/write." I apply these recursively to the directories, but the settings don't take effect—they remain set to "deny."

The previous version was TOS 7.0.1298. I am configuring these permissions under "App Users."

In File Manageer, you can set permissions and apply them to subdirectories. If you are still unable to access the files, please check for possible file system errors.
viewtopic.php?t=2575
If no file system errors are found, you can contact us online to schedule an engineer to help you troubleshoot remotely:
https://salesiq.zohopublic.com/signatur ... 97d0be8892

Hi. I am having problems to upgrade from 7.0.1278 to 7.0.1341, even to 7.0.1298 in my F2-423. In the syslog, always have some hash problems:

Oct 23 12:02:09 TNAS TOSDaemon[2458]: VerifyUpdatePackage failed: hash mismatch for usr/lib/modules/6.12.63+/kernel/drivers/net/wireless/ralink/rt2x00/rt2800usb.ko.xz: expected d6f83ca7b3569194b8e483c6c6bda02ef9982854927d699648716c2f55d23b42, got d8dc842efeca3e239e59f5a7d9aa237998ddc8f5a5e6b88ae0174ae1497e599b
Oct 23 12:02:09 TNAS TOSDaemon[2458]: E1023 12:02:09.814586 2458 updaterestore.go:364] hash mismatch for usr/lib/modules/6.12.63+/kernel/drivers/net/wireless/ralink/rt2x00/rt2800usb.ko.xz: expected d6f83ca7b3569194b8e483c6c6bda02ef9982854927d699648716c2f55d23b42, got d8dc842efeca3e239e59f5a7d9aa237998ddc8f5a5e6b88ae0174ae1497e599b
Oct 23 12:02:09 TNAS TOSDaemon[2458]: Package verification FAILED: hash mismatch for usr/lib/modules/6.12.63+/kernel/drivers/net/wireless/ralink/rt2x00/rt2800usb.ko.xz: expected d6f83ca7b3569194b8e483c6c6bda02ef9982854927d699648716c2f55d23b42, got d8dc842efeca3e239e59f5a7d9aa237998ddc8f5a5e6b88ae0174ae1497e599b
Oct 23 12:02:09 TNAS TOSDaemon[2458]: Update aborted due to verification failure
Oct 23 12:02:09 TNAS TOSDaemon[2458]: Cleanup: removed package dir /Volume1/.update_6cf63d40d9af5463182da96e489889c1

Do you think it could be a problem with the space in the system partition?

dplegue wrote: ↑24 Oct 2026, 22:32

The HDD or array likely has a file system error or bad sectors. Please try deleting the remaining extraction directory and try again. If the problem persists, it is most likely due to the reasons mentioned above.
You can refer to this guide to try repairing the file system:
viewtopic.php?t=2575
While the scenario you’re suggesting is highly unlikely, you can try entering the following commands in the terminal after the problem occurs (but before shutting down) to verify and check for related disk or memory errors:

T6-423 updated fine. Everything appears fine BUT file transfers from my phone to the NAS feel a lot slower. (GUI shows fluctuating between I and 20mb.