TerraMaster Forum

Let me ask the Terra Master support team here few things that can give us another, more realistic, line of investigation.

1. Is it IPv6 required for TOS 6.0.794 work and what will happen if it's disabled? (it can affect some TOS apps, like docker for example)

2. Is the adaptive load-balancing (ALB or Bonding mode 6) well tested on TOS 6.0.794?

3. What about jumbo frames - any TOS issues with MTU 9000?

4. As I already identified on TOS 6.0.794 the debug is not going to work, before manually to create in the @system folder the required path (debug/log). Any other pitfalls that are not public for the users on that TOS version?

5. The super-user SSH access is allowed by default to the system and the attempts to add another user in sshd_config file are remediated with the ssh_prepare script that's overwriting the super-user as only allowed via SSH. If that meaningless measure is workaround-ed is that going to affect something else in the TOS to the degree of system crash?

Thank you!

PS: BTW, Your Cloudflare protection is triggered if the full path to files like sshd_config and ssh_prepare is mentioned in the post ...

TMzethar wrote: ↑21 Dec 2025, 13:06 Hi.
Many users who use this NAS model and system, like you, have not encountered similar issues. The available information does not clearly indicate the source of the problem.
Next, it may be necessary to consider checking power supply-related issues. Are you currently connected to a battery/UPS instead of mains power?
Is the power adapter original? Is its LED light bright? What is its output voltage (V)?
If you have an adapter with 1.5 times or even higher output power than the original one for the 12V 5.5*2.5 interface, you can try replacing it for testing.

Are you sure that many users are on TOS v6 with F5-221 and they are configuring on the NAS enough parameters to make it performant?
Take a look on the questions from my previous post and on the result of that last test:

New attempt - fully automated installation from scratch.
--- 2 hours stable work --- Note: App Center is not acessible
Sun Dec 21 17:24:49 -05 2025
Changed IP address to static, disabled IPv6, applied ALB bond, changed ports to 7171 / 7443, created /Volume1/@system/debug/log, enabled ssh/9222, removed notifications for SSH login
--- survived 5 minutes and self-shutdown ---
Sun Dec 21 17:31:59 -05 2025
started the NAS and removed debug/log and re-enabled IPv6
--- survived 16 minutes and self-shutdown --- Note: App Center is still not acessible (https://dl.terra-master.com/ server under maintenance)
Sun Dec 21 17:51:18 -05 2025
started again, registered for Remote Access as a test (the registration is working)
--- 1 hour stable work ---
Sun Dec 21 18:58:18 -05 2025
created 2 users, changed SMB workgroup, enabled NFSv3, enabled DDNS
--- survived 16 minutes and self-shutdown ---
Sun Dec 21 19:26:15 -05 2025
started again, observation - the existing users are with different IDs, but trying to use the existing home folders (corrected for the currently created users)
--- survived 1 hour and 9 minutes and self-shutdown ---
Sun Dec 21 20:42:48 -05 2025
started again, removing ALB bond (only eth0 stays), created the rest of the users (all home folders' permissions corrected)
--- survived 1 hour and 14 minutes and self-shutdown ---
Sun Dec 21 22:24:17 -05 2025
started again, Reset System Configuration, reboot, init and super-user, static IP, SSH notifications removed, reboot
Sun Dec 21 22:42:46 -05 2025
--- 9 hours work overnight ---
removing SSH notifications, re-creating first user - immediate self-shutdown.

From all of the above and the previous 2 days stable work with System Rescue live Arch linux and simple samba shares, on the same platform, with the same identical conditionis, what is the only conclusion that could be made?

My bet is that TOS v6 is unstable on F5-221 and the additional observation is that the Terra Master support do nothing to find the problem.

Is that the support, your customers should expect from you, guys?

Tos6 on F5-221 is performing fine for me. (But then, I'm not trying to treat it as "linux" and am working within the TOS environment).

Gremlin wrote: ↑23 Dec 2025, 06:19 Tos6 on F5-221 is performing fine for me. (But then, I'm not trying to treat it as "linux" and am working within the TOS environment).

It seems like you are using 6.0.783 - I didn't gave it a try, but I really pushing it to the limits... stil in the TOS environment, though.

Are you disabling IPv6, using Jumbos, Mode 6 link-aggregation, NFSv3, SMB per subnet restrictions etc.?

Any containers, like proxy, pi-hole, Jellyfin?

Thank you for the feedback!

Interesting development today.

TM tech was looking only in one problem - the non-working samba shares. It took about 75 minutes to tell me that I have to do a new re-installation.

After the re-install, the result was the same... after the first user creation, all shares are not accessible only from the super-user.

I'm giving up on TOS... moving to TrueNAS.

Good luck with that support guys!

AlAleksiev wrote: ↑23 Dec 2025, 06:35

Gremlin wrote: ↑23 Dec 2025, 06:19 Tos6 on F5-221 is performing fine for me. (But then, I'm not trying to treat it as "linux" and am working within the TOS environment).

It seems like you are using 6.0.783 - I didn't gave it a try, but I really pushing it to the limits... stil in the TOS environment, though.

Are you disabling IPv6, using Jumbos, Mode 6 link-aggregation, NFSv3, SMB per subnet restrictions etc.?

Any containers, like proxy, pi-hole, Jellyfin?

Thank you for the feedback!

No Containers
IPv6 is set to auto, but I don't have v6 from my provider.
Actually I'm on .794, just forgot to upddate sig. Thanks for the heads-up
No Jumbos, no link-aggregation. No NFS, SMB3
My Lan1 is 2.5 and Lan2 is 1Mbps. Link aggregation doesn't work with asymetric lans.
I do have 10MB total RAM, if that is of any help. Steady state usage is generally < 2MB.

Hey Gremlin, thank you, sir!

I think you mean 10 GB RAM, not MB
That's making the big difference for sure!

When my F5-221 was with 6 GB RAM it was running with 100-120 MB free memory, when on TOS v6... and at some point was crashing.
When moved to v5.1.145, there were 2.5-3 GB free - however, on that version TOS has another problems. That's where their tech was fighting 75 minutes to figure out why the samba authentication is not allowing the users to see the shares. They asked me to re-install - funny guys.
RAM is making a big differnce for the NAS platforms, because of the caching for all the processes.

In the moment when you'll try to add some performance related configuratoins, like the Jumbo MTU or the Adaptive load-balancing, this is going to level up the requirements for the read/write operations and as a result to require more RAM to succeed.
Few more containers, in such a conditions, are usually enough to hit the limits and crash it - TOS is fragile

You gave me a very good information though. In the F5-221 spec (https://www.terra-master.com/pages/f5-221-specification) is written that besides the build-in 2 GB RAM we can use no more that 4 additional GB.
The fact you are with 10 GB RAM , means that the single additional slot can take 8 GB SODIMM and to fullfil the TrueNAS requirements of 8 GB.
I already ordered that SODIMM - once here, I'll "hit the button" and forget the TOS for good ...

Cheers

The +8GB upgrade was quite popular amongst forum users (at least). I am using Crucial, but that's another chapter now ......

AlAleksiev wrote: ↑23 Dec 2025, 21:57… On the F5-221 spec (https://www.terra-master.com/pages/f5-221-specification) is written that besides the built-in 2 GB RAM, it can use no more that 4 additional GB …

That's likely stated as such due to there not being 6 GB RAM modules available for sale, as Intel lists the J3355 as having a maximum capability of 8 GB @ https://www.intel.com/content/www/us/en ... tions.html

As long as the UEFI/BIOS doesn't restrict the module compatibility (which has previously been a concern on older revisions), it'll accept & address more than 8 GB.

---

If someone has the tinkering abilities, they could remove the 4×512 MB DRAM ICs on the motherboard & replace them with 4×1 GB or possibly 4×2 GB ICs as long as the current UEFI/BIOS can recognize said replacement ICs or can be modified & updated with a custom one in advance of soldering the replacements (obviously, warranty void <most units are already outside of it> & proceed at one's own risk); might even be able to get up to 16 GB working.

I see... obsolate spec for an obsolate device.
Well, it was running 4.2.30-2203011626 for 3 years with 2 GB RAM, bonded interfaces, Plex and few docker containers.
The certificates were expired, but it was rolling... when the newer containers were with more requirements, it started to suffer...
Maybe it's just a time to fully re-build it with 8 GB, new pools etc. and to recover the data from the backup.
I'm just not sure if TOS is the right way to go... it seems pretty fragile and the support doesn't seems to care too much for the users.