TOS 7.0.1341 (x86) Official Release Update

[enryx]

After upgrade to TOS 7 login page shows TOS 6 label instead of TOS 7.
Take a look to the image attached.

[TMzethar]

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.

Regarding the “1–20 MB fluctuation,” is this occurring during a local network transfer, or is it a remote transfer via some other method?
You can test other transfer methods, such as SMB, FTP, or WebDAV, to see if this issue occurs only in the TNAS mobile app.

[TMzethar]

After upgrade to TOS 7 login page shows TOS 6 label instead of TOS 7.
Take a look to the image attached.

Based on the screenshot you provided, the version number is unexpectedly 7.0.1341.
It appears that you skipped the required intermediate update to version 7.0.747 and went directly to 7.0.1341.
This is not the correct update process and may cause some unknown issues.
You may want to consider the following steps to restore normal operation:
Remove the side panel of the F6-424, take out the built-in USB Initboot, and flash the TOS7 UEFI image.
viewtopic.php?t=6433
Reconnect the USB Initboot to the NAS, reset the system, and proceed directly with the initial installation of the latest TOS7:
viewtopic.php?t=9523

[mcvh]

Hi everyone!
I just got the F6-425 Pro as a replacement for my old Syynology and am transferring files across systems. So far I like TOS 7 since it is very similar to DSM 7.
It was really easy to set up and getting it connected to my Mac systems.

I am from Germany and have encountered one small but not so small problem which I hope to find a solution to.
In German we have Umlaute ä, ö, ü and ß and I do have files and folders named with this. Creating these or copying those files is fine.
BUT accessing those is utterly impossible on my Macs. I can see the folders (eg Küche -which stands for kitchen) but I cannot see their contents. Same with files containing such letters. I can see them BUT NOT OPEN them.

So I have to log in to TOS 7 and rename them from there since not even that is possible in Finder at all.
Would be really helpful if somebodyy especialle from TM would be able to come up with a fix.

Thanx already in advance,
Marc

[storageninja]

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.

Morning, any update on this?

[CursaYang]

We created a folder named "Küche" and a file named "Küche", and both opened normally in Finder on our test.

Do you get any error message when accessing them? If so, please provide a screenshot.

Alternatively, you can visit the link below to schedule a remote session with our online support:

https://salesiq.zohopublic.com/signatur ... 97d0be8892

[CursaYang]

Currently, it is not supported to automatically thin out old backups when a Time Machine backup reaches the shared folder quota.

We will forward this request to our product team for evaluation.

[storageninja]

Currently, it is not supported to automatically thin out old backups when a Time Machine backup reaches the shared folder quota.

We will forward this request to our product team for evaluation.

Well thats very bad news, so the only way is to empty the fileshare when it reaches 100%? Thats not even close to the way Apple designed and implemented the TimeMachine look and feel.

[TMroy]

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.

We sincerely apologize, but based on your description alone, we are unable to determine the cause of the issue at this time. Additionally, since you have already rebooted the device, the relevant logs from that incident are no longer available. Before the next update, please enable debug mode. If the issue occurs again, please do not reboot the system — contact us directly so we can perform a remote inspection.

[snapsh0t]

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.

We sincerely apologize, but based on your description alone, we are unable to determine the cause of the issue at this time. Additionally, since you have already rebooted the device, the relevant logs from that incident are no longer available. Before the next update, please enable debug mode. If the issue occurs again, please do not reboot the system — contact us directly so we can perform a remote inspection.

It was only intended as a comment and I didn't expect any action on TM's part. I'd already updated to 7.0.1422 by the time you'd posted and that completed correctly.