So many complaints, so many long posts, and nobody actually created Feature Request with specific idea what to change and allow voting to take place like @Captain_Morgan suggested.
Looks like complaining is easy and cheap but actually submitting feature requests with specific ideas to implement is too much work.
Well, I created one very simple for start. Just put link to Software Status on Update page. So lets see how many people actually want this.
You forgot the part where the time machine is invented to retrofit the new capability.
Otherwise, we have to focus on future software releases…
No. Please read back to the actual post that this was in response to. And it might be a good idea to implement it now, to save you pain ahead.
In other words, “always jam tomorrow, never jam today” because (all evidence suggests) that iX will always put off this stuff because 1) it isn’t urgent; 2) iX don’t want users to get warnings because that will impact your upgrade stats; 3) iX didn’t think of it; 4) iX don’t think it is necessary; 5) the time that it would have been useful was the last release not this one; 6) iX doesn’t have a time-machine; …
This would be a new capability built into the update process. Your updater would obviously have to be re-written and going forward have this capability. It would be a very innovative capability but I can also see why there is zero business case to do so, with a very few exceptions.
As you put it, zero enterprise customers are interested in running VMs, Apps, etc. As such, your team working on supporting same is a bit of a distraction from the core functionality that enterprise customers are paying for. At the same time, your free beta testers are attracted to the platform in part due to these features and the more learned among them can provide really good feedback.
With that in mind, even enterprise customers might benefit from this updater improvement. For example, a few may still support AFP deployments, so knowing AFP is getting nuked is pretty important. Ditto SMB aux. config settings, etc. These are likely edge cases, enterprise customers likely do read their docs a bit better, etc. … and yet it would be a great differentiator.
Whether the work is worth it is not my call. I happen to think it would be because it would underscore a customer-centric thoughtful update process. A big step towards collaboration because sometimes subtle changes may be overlooked even if the customer ends up reading the change log / update notice.
No - recommending that users ignore the Software Status page would be completely illogical Captain. (Sorry - but given the context, the opportunity to say this was impossible to resist - besides which resistance is futile.)
No one is suggesting that iX are recommending that users should deliberately ignore the Software Status page - what we are saying is that (at an absolute minimum - if you don’t do anything that is more specific) iX needs to ensure that every user upgrading cannot possibly fail to know about this page because you make them acknowledge that they have read it.
So it’s (once again) the users fault if they don’t know about or follow the Software Status page - and therefore there is zero onus on iX to do anything to prevent users from unknowingly screwing up their own system because they aren’t in touch.
And this has got to be the screwiest logic ever put forward as an excuse. “The reason a web page is obscure is because people (who don’t know it exists) don’t acknowledge it’s existence” !!!
A question to the iX staff? Do you actually listen to yourself as you are saying this stuff?
As I said before, blaming users is AFAIK the opposite of what they teach in business schools as being good customer service and helping ensure that users don’t in ignorance do something that breaks things.
You got me right there!
A long time ago I started a web page with instructions on how to fix some computer gear affected by the exploding Lelon capacitor issue. I added an email address for feedback.
Every time I got feedback that something was unclear, not explained well, if there were new sources for caps, other guides to link to (this was pre-google), I would amend my pages.
With time, the number of improvement opportunity suggestions abated, likely because the kit was no longer being sold and because the instructions reached a level where most users could use them without confusion.
I don’t expect iXsystems to jump on every suggestion / improvement opportunity / etc. - especially when they’re outside the core file server functionality that the big buck enterprise customers are paying for.
However, given the consistency with which the changes around the App / VM / Jail periphery have bitten folk in the butt, I suggest there must be a better way forward. Hence my suggestion to improve the diagnosis capabilities in the updater.
Granted, there is a perverse incentive to not implement these kinds of smarter guts - just like there has been no interest in improving ZFS diagnostics when a pool cannot import because a disk or two went offline. Make the system too intuitive to administer and there is no reason for a support contract.
As long as some risk is built into the update / maintenance process, there is a monetization opportunity. So I could see why iXSystems would not want to go down that route even if all of us could agree that it would be a worthwhile feature.
I have always believed that TN’s business model is distorted, because TN has never really understood what kind of user group it is facing, what it wants to provide to these users, and what it wants to get from these users.
About two years ago, I discussed this issue with an iX leader on the old version of the forum, but it is obvious that they did not really understand and learn from it.
When TN turned to K3s, iX once gave an ambitious plan (such as introducing cluster functions), but until TN gave up K3s, this plan could not be realized due to technical problems, and K3s always had a lot of stability problems. But iX chose to downplay this matter, as if it had never been raised. TrueCharts, an old friend of the TN community (although many people don’t like them), also became a victim of this incident. You can find some discussions at that time on Reddit: Reddit - The heart of the internet
TN uses a typical business model of first conducting technical experiments and bug elimination by the open source community, and then selling it to enterprises for profit when the system is stable. Obviously, there are big differences in the usage scenarios of geeks and enterprises.
TN’s existing development model makes it impossible for many enterprise-level features to be verified in the open source community (because there is no enterprise authorization), and many features that are only used by geeks are difficult to use in enterprise scenarios (such as Jellyfin’s GPU pass-through), but the development budget is limited, so iX has been jumping back and forth between the two.
For community users, they obviously hope that iX can add some common functions similar to those in Synology or Unraid, but iX is unwilling to add them based on its own enterprise user scenarios, and finally under pressure from the community, iX will add some more popular functions, which makes iX seem to be wavering. This is not a healthy state.
I believe that the initial decision on K3s led to quite a number of TN users and potential TN users flowing to systems such as Synology and Unraid, and most of these users will not come back, because Unraid has long supported ZFS and can provide many functions that TN cannot provide. For TN’s business model, sufficient community users are not a bad thing. Even if TN cannot directly make profits from these community users, the indirect profits and corporate valuations brought by market share will obviously far exceed the development costs. I suggest that iX rethink its own operating model, clarify the position of community needs in the iX product system, and avoid the current demand conflict situation.
Another serious mistake made by iX is hesitation and radicalism in new technologies. Yes, as I said before, these two contradictory problems appear in iX at the same time. The part about hesitation does not need too much explanation, which can be seen from the capriciousness of iX’s technical direction.
iX’s own technical capabilities are not in the first echelon, and TN is not irreplaceable in the network storage ecosystem (because TN is more about software engineering management rather than difficult development), so switching technology routes is a very risky thing for iX (including business risks and technical risks).
But whether it is K3s, Docker or Incus, iX has chosen drastic destructive updates, which is a very surprising choice for both the community and the enterprise scenario. iX seems to have only more than 100 people, but it has been encountering problems that only large companies like Microsoft will encounter.
In summary, I think iX should take the following improvement measures:
-
Re-clarify the relationship between the community and enterprise users, conduct research on the community and enterprises, and provide a roadmap for the next 1-3 years, especially the main technical direction.
-
Improve the transparency of the community. Failure to achieve the established goals is not a problem, but not actively admitting it is the most serious.
-
Use the most compatible upgrade method to introduce new technologies (many people have already mentioned this).
-
Add some functions that community users have a high voice for.
-
Develop a cloud-based community user value-added package that provides a more simplified system deployment and remote management and monitoring services to optimize the use of novice users and gain profits from them.
In fact, TrueNAS SCALE releases are often delayed, and sometimes I see the release date on the Release Note being pushed back and forth to match the actual release date.
I cannot agree with this view. I think as long as they are in my expected user group, whether they pay or not, I will identify them as “customers”.
Profits do not necessarily come directly from user payments. The market share brought by free users, the bug feedback and test data provided, the valuation and stock price brought to the company, these are indirect values, and in some cases even exceed the direct costs paid by those paying users.
For users who are not in my expectations, as long as they do have an impact on my project, I have to take their opinions into consideration. At most, I will reduce the weight of their needs, but I will not block them directly.

I cannot agree with this view.
Neither do I…
Ok, I guess I was wrong about only considering customers paying users. I take it back.

As you put it, zero enterprise customers are interested in running VMs, Apps, etc. As such, your team working on supporting same is a bit of a distraction from the core functionality that enterprise customers are paying for.
Wasn’t that the whole business case for rug-pulling out FreeBSD in favor of Debian? that they would be able to replace the horrible FreeBSD Jails that actually work, with kubernets or docker or sume such? Sticking with FreeBSD would make sense from an Enterprise perspective in my opinion, but it dosent matter sins Im not buying TrueNAS… An my homelab is vanilla FreeBSD…

would be able to replace the horrible FreeBSD Jails
FreeBSD Jails are great! One of the key issues was the ability to support Apps/Plugins… Docker is much better at that.
There’s a list of many other things we can do with Linux, but Jails was not the issue.
My point is that I dont see the business case for putting themself in the situation they are in with TrueNAS…
I imagine clustering was a big reason hence the original name SCALE but unfortunately that didn’t work out.
If you wanna Hyperconverge with the big boys then you’ve gotta cluster.
It’s a difficult thread to read and parse, so let me try to summarize.
TrueNAS 25.04.0/1 has a Virtualization solution that is subpar and causes migration issues. TrueNAS 25.04.2 will include a fix for that with the re-integration of “Classic Virtualization”. Most users agree with that transition and it’s expected in late July. (Read the Software Status page before updating).
Some users have requested that TrueNAS always provide smooth transitions between versions.
TrueNAS Enterprise provides this smooth transition to paying customers. It is part of our commitment and our support service. Enterprise customers follow a very Conservative update process and do not use Experimental features. If you are running a business, then TrueNAS Enterprise is recommended.
TrueNAS CE is used for innovations and field testing and that is not planned to change. While TrueNAS CE has this smooth transition goal, the commitment we have made is that smooth transitions are generally feasible for users who are carefully following the “Conservative” persona on the Software Status page. Some users object to this policy, but it is today’s reality and we will not sugarcoat it. It’s the seatbelts for the sports car and they can be worn or not.
(I should add a special call-out to early adopters and testers - we love you and appreciate all the work you put into to find and report issues. Please read the Release Notes to avoid surprises!)
The Software status page is in docs, on blogs, and on the primary web site. However, some users have not noticed it or used it. There are user requests to include it more forcefully in the update process. TrueNAS generally agrees with this for future software, but in the meantime, we request that users read the software status page before updating a production system. Please encourage all users to do this.
If anyone has specific needs for this improved update process, they should use the Feature Request process and get votes. Or, they should join Discord and contribute to the software.
The positive out of all of this is that with 25.04.2+, TrueNAS will be more complete, earlier than Goldeye. We’ll be releasing our Goldeye plans soon.
Some users also object to my tone… in a previous life I was called “Dr No”. I have a tendency to be blunt to avoid any confusion. Apologies if that comes off wrong.

Feature Request
Since yesterday there’s a feature request, just FYI for all following this post.
If I may make a further suggestion: Going forward, if the software could show stacking issues, that would be awesome also. For example, let’s say my NAS is on 23.whatever and I want to make the jump to 25.4. It would be very relevant to not only show release notes for the transition from 24.10 → 25.4 but also every intermediate step in between. Because a lot changed in the meantime. So make that one pop up or window per iteration that the user is updating over, not just the latest one.