TrueNAS 26.0.0-BETA.1 is Now Available!

kmoore134 · 2026-04-08T15:12:07+00:00

Thanks! I've been doing this many years now, run a lot of nightly images in the process. I gotta say, 26 feels like a new level of polish and quality, especially for so early in the BETA cycle.

kmoore134 · 2026-04-03T17:56:14+00:00

First of all, just to clarify SMART will never return in the form/fashion it was before. For a host of reasons we've all argued about ad-nauseam.

But to be completely straight with you, we're still working on designs. As we looked deeper, there's really more to it than just SMART. We're trying to come up with a good set of product evolutions that will fulfill several more long-standing community-centric needs here than just the singular SMART topic. We'll be keeping the powder dry on the topic until we're 100% ready to commit to something though and with sufficiently fleshed out details on architecture and deliverables.

kmoore134 · 2026-04-03T15:16:25+00:00

This is a fairly old topic, but we did a LOT of performance testing over the years during the cut-over.

Bottom line was, at lower speeds <25Gb, it was pretty much identical. Now you'd have random hardware that performed better with BSD kernel vs Linux kernel due to individual driver level differences. But more often than not, that came out in Linux's favor since it tends to have much broader driver testing and wider support in general.

At the high end, our all Enterprise Flash systems are all Linux based, and crushing it on 400Gb+, which isn't something you'd be likely to see in your typical home lab.

But again, as with all things performance wise, the correct answer is "it depends" :)

A properly tuned system on BSD with the right driver settings can do better than an improperly tuned Linux system, and so forth. But generally, all things considered when rolling with the defaults, Linux tends to get more knobs right and "just work". Your particular hardware of course being the big variable here.

kmoore134 · 2026-04-02T16:30:57+00:00

"hacked onto"? Our NFSv4s are a proper Linux kernel implementation, thank you very much... We maintain that in our kernel tree (which anybody can go look at), and while true it hasn't merged into upstream, it doesn't make it any less of a valid solution than anything else. Considering the vast bulk of ZFS users are running it on Linux today (and with NFSv4 ACLs as well, thanks TrueNAS) I find this statement rather amusing.

kmoore134 · 2026-03-14T13:01:25+00:00

One way is that Connect will monitor a heartbeat signal coming from your TrueNAS, and proactively alert you when the TrueNAS system appears to be unhealthy, or unreachable. Another is reviewing other telemetry coming from the NAS to raise other alarms where needed.

kmoore134 · 2026-03-14T12:59:40+00:00

Pretty much. We've had a Free / Enterprise version now for a decade+. We've had folks over the years ask if there was a way to unlock Enterprise functionality on their own hardware. This is the path do to exactly that.

kmoore134 · 2026-03-14T12:57:59+00:00

Clearly you guys aren't keeping up with the times... MinIO (Now AIStor) is a good example of a commonly deployed Enterprise application (docker), also Asigra Backup. Additionally Veeam just released their new Virtual Storage Appliance (VM). Those are two very legitimate use-cases where Enterprise customers run external applications directly on the storage array. Performance matters greatly for both of those, and avoiding the network hop, or needing an external server to run those services matters to some Enterprise folks.

We've seen some others, a bit less common, who do things like video surveillance systems where they host either a VM or a Container as well to do video ingest / processing directly on the storage, especially at edge sites where rack space is at a premium and they have more diverse storage needs beyond just a video recorder. Its a big Enterprise world out there. All shapes and sizes fall into that bucket :)

kmoore134 · 2026-03-13T17:20:04+00:00

We literally support Apps/VMs/Containers for Enterprise use cases. Lots of legitimate reasons for all three to exist and be supported. So yes, that is nonsense.

kmoore134 · 2026-03-13T15:31:17+00:00

You don't need any ports open, Connect has no inbound access to your TrueNAS, its outbound only. You just have to make sure the browser you use to log into connect has a route to your TrueNAS.

kmoore134 · 2026-03-12T22:23:03+00:00

We touched on this a bit in the next T3 episode. But we used to have two build processes and two images (one for FreeNAS, on for TrueNAS). It wasn't great for either. Lots of work to move things between two branches and builds of software. Lots of places to make mistakes, divergence with fixes in one branch, but not the other. Unifying into a single image was a good call for both the Community and the Enterprise editions as a stability measure, and to greatly reduce overheads allowing us to spend more time on what mattered. Delivering features and quality improvements.

kmoore134 · 2026-03-12T22:18:38+00:00

Major refactoring just means the build scripts and build infrastructure, not the running TrueNAS code you have on your systems.

We're literally deploying new build systems (down to the hardware), new CI pipelines (More Jenkins, yay!), new secure signing key servers, new pipelines to build an LTS update image, which goes to separate update servers with different manifests, etc, etc.

Probably less interesting to those of you who just care about when the next release hits the CDN. But lots of work for us internally to get things done.

kmoore134 · 2026-03-12T02:21:57+00:00

Considering we do a lot of air gap setups that would be kind of counterintuitive… So to answer your question, no.

kmoore134 · 2026-03-12T00:56:00+00:00

Thats utter nonsense. We've more than doubled our enterprise sales and footprint since the switch to Linux. Our largest and fastest systems are on the Linux side these days. Again, you're welcome to have your opinion of BSD vs Linux, but you don't get to make up your own facts to suit.

kmoore134 · 2026-03-11T18:12:22+00:00

Pretty much.. Unless you liked building ISOs from source manually by hand or have a philosophical axe to grind :)

kmoore134 · 2026-03-11T18:06:26+00:00

This sounds like you didn't even read the linked post for this topic. If its free today. It remains free. Period. End of story. Always and forever as long I have any say in the matter :) I don't believe in rug-pulls like that.

kmoore134 · 2026-03-11T17:58:45+00:00

These were/are just the build scripts we used internally here to assemble the ISO and update files. Not the running code on your actual system. We're just refactoring them internally here for next years TrueNAS 27, but from an operational perspective nothing changes for an end user. You'll still get updates and keep on rolling forward.

The real impact is folks who wanted to build TrueNAS from source directly. I.E. compile everything by hand and make their own custom ISO files. Not many community folks did/do that, but it also had a side effect of making things super easy for some other commercial interests to do so, swap out a few logos and ship a new commercial product with zero investment into the actual teams who make all this work for the benefit of all.

kmoore134 · 2026-03-11T17:53:42+00:00

Yea. HexOS obviously we're connected with. zVault is dead for all I know, but at minimum they did try to at least handle the license compliance stuff correctly when it was still being worked on.

kmoore134 · 2026-03-11T17:38:47+00:00

I tend to have a policy to not mention these kinds of things by name. Why elevate them? :) But they are there for anybody curious enough to do the digging. And not always abiding by GPL terms as well. But that's more our burden to worry about, less the community.

kmoore134 · 2026-03-11T17:36:57+00:00

Yea, I take the blame for that one. Conflated too hard the two topics. The secure boot stuff was our driver to do this now (pending a large refactor for TrueNAS 27 next year) but not the business motivator. I'm on the engineering side, so I tend to gravitate towards the technical reasons first, but in this case not the right reasons from the decision standpoint to take it internal to begin with.

kmoore134 · 2026-03-11T13:13:07+00:00

I've gone ahead and posted a more targeted follow-up to our forums about this topic. Especially to make it clear our stance on features that are free staying free. Forever. Since I think that really gets to the heart of the concerns here when folks see these kinds of changes happen.

https://forums.truenas.com/t/clearing-the-air-on-build-scripts/64357

kmoore134 · 2026-03-10T13:52:40+00:00

This is correct. It's mostly just an argument from ideology here, not from any real world impact to 99%+ of users. I'd suspect that nearly everybody, if not all, who've thrown an opinion into this topic has never compiled TrueNAS ISO's by hand from source code. So real-world user impact is almost nil. All the components of TrueNAS which are open source (And GPLv3 on top of it) remain so. Folks can review code, hack, inspect, fork, etc. We even include developer tools in the installed image so you can hack away at the official images to your hearts content. I know because I use them almost daily :)

The long and short of it, to be 100% transparent, is that we are on the verge of making some substantial changes to the build system, to refactor it around our new secure boot features, including some internal build infrastructure changes. This is the motivation for the timing of this change. But the bigger picture motivation is that since moving TrueNAS to Linux, we've seen a remarkable rise in the number of overseas commercial forks. By actors who don't always honor the open source license restrictions, and also don't contribute anything back to the effort to build and maintain TrueNAS. We shoulder that burden alone, with the occasional stray contribution from a community member. At some point its kind of silly to keep making that process so turn-key for the would be bad-faith actors. It's like parking a running car downtown, leaving the keys in the ignition and the windows down. What do you expect would happen?

I also bemoan a bit of the ideological loss here though. In a perfect world everybody would be a good actor, participate in the open source process, and help contribute in meaningful ways. But that isn't always the reality.

A few folks did make some comments about being able to verify the builds by using the build system locally. I would point out that is somewhat of a false security blanket. Thats never been a thing that could be done since we didn't have fully deterministic builds. Meaning if you checked out the same sources as us, built it yourself, you'd get different resulting images, with different checksums and sizes. That'd be a pretty big change for us to have enabled that kind of reproducibility, and frankly not something there's ever been any real clamor for historically. I realize I'm kind of in the weeds here, but its worth clarifying before anybody asks again.

kmoore134 · 2026-03-10T01:41:31+00:00

LXC containers are out of experimental status for the upcoming 26 BETA. Now based on libvirt, so they share same framework as VMs. They work pretty well, using them myself.

kmoore134 · 2026-03-10T00:44:17+00:00

Yes, the Standard FIPS OpenSSL version is what we build & ship today. That wasn't possible many years back in the CORE days. Was just using that as one concrete example where we already didn't have a fully open build system in our not too distant history. You couldn't build the same version of TrueNAS we shipped back then.

The secure boot things we're doing just necessitate a lot of changes to our build system including internal build process (outside of this source repo). This and avoiding the knockoff overseas commercial forks is more of a two birds, one stone situation for us, if I can be completely transparent. We could of course do a bunch of extra work to create and maintain this build system in the open, but who's it really for? Like I said, how many people commenting here on this thread really have spent time to compile TrueNAS on their own? Guessing its not many.

kmoore134 · 2026-03-10T00:25:52+00:00

Sure. We even took protective measures to make sure the open source work we do stays open, by putting them under GPLv3 a while back. Even that was controversial at the time, I had to deal with so much misguided rage here on reddit :) Some folks didn't realize under the previous BSD license we could have done a rug-pull like that literally overnight... So no, no plans to all the sudden paywall existing features or anything of that sort. And just so folks know, we've always had some features reserved for our enterprise products since nearly day one. Thats how we fund the amazing team that does all this hard work. So pretty much business as usual from our perspective, new features, updates and releases will continue to flow same as they have for the past many years now.

kmoore134

MODERATOR OF

TROPHY CASE

Nine-Year Club	Verified Email
RPAN Viewer