Lately, it's been difficult to gauge the stability of new Unraid releases based on the current forum threads. It's unclear whether reported issues are isolated cases tied to specific hardware/plugins/odd configurations or broader problems that warrant holding off on upgrading production systems. With both of my servers now serving important roles, I can no longer risk testing potentially unstable versions so I hold off on upgrading. I suspect many others are in the same position.

A major part of the problem seems to be the reduced visibility and participation in beta and RC testing phases. These threads are now somewhat hidden under the Bug Reports section, making it unlikely that new or casual users will stumble upon them. Unless a user is keeping up on the Unraid News blog (which frankly we all should but I'm not sure this is realistic), they probably have no idea these pre-releases exist. In the past, pre-release threads were posted prominently in Announcements, encouraging broader testing.

Combining that visibility pain point with the current licensing model, which doesn't support dedicated test environments without a full license, community engagement in pre-release testing has understandably declined. I've never signed up for the Trial but I have to assume it is one time use per account so this obviously wouldn't work either.

To help improve on these issues, I propose a few ideas:

• Move the Prereleases back to the Announcements area, leave the Bug tracking subforum where it is to collect feedback

• Unraid offer a limited-use full license specifically for testing new releases, valid only during a beta/RC cycle. Perhaps it could expire at the end of these cycles? This could allow spare systems to be used for quick tests, VMs, etc.

• Put specific language in the OP asking users to post their hardware specs and upgrade outcomes in release threads (or capture in their signatures). This will help identify patterns and build trust among potential upgraders.

Unraid has always thrived through a strong community partnership—revitalizing that effort now could really benefit both users and developers. Just as an example, this is how I shared my last result from my move from 7.0 to 7.1.4.

Example:

Status	Hardware	Plugins
Upgrade path: 7.0 --> 7.1.4 All docker containers and plugins running Syslog is clean System stable so far	M/B: ASUS ROG STRIX Z370-E GAMING BIOS: American Megatrends Inc. Version 0614 CPU: Intel i7-8700K CPU @ 3.70GHz MEMORY: 32GB DDR4 NIC (bonded): Onboard (Intel I219V) Dell Mellanox CX322A Connectx-3 Storage Controllers: Onboard 2x PCI-E ASM1166 (8 port) 1x M.2 ASM1166 (6 port)	Appdata Backup CA Auto Update Applications CA Cleanup Appdata Community Applications Disk Location Dynamix Cache Directories Dynamix Schedules Dynamix System Information Dynamix System Temperature Fix Common Problems FolderView2 Intel GPU TOP	Parity Check Tuning Python 3 for UNRAIDRecycle Bin Sanoid for unRAID 6/7 ssh Plugin Tips and Tweaks Tmux Terminal Manager (TTM) Unassigned Devices Unassigned Devices Plus Unassigned Devices Preclear User Scripts ZFS Master for Unraid

Edited June 23, 20251 yr by cj0r

12 minutes ago, cj0r said:

Just as an example, this is how I shared my last result from my move from 7.0 to 7.1.4.

That's nice, but likely doesn't include anything of actual use for troubleshooting, from what I've seen problems tend to come from unusual setups. You say you have 2 NICs but not how they are configured, what your Docker networking settings are, how specific containers are set up,... and that's where things break.

Posting "it worked for me, here's my hardware" is essentially useless since it's likely fine for 90%+ of set ups, it's the few that don't work where information is needed, and that's much more detailed information than this. I.e. how it's being done now by asking detailed info about non-working setups when someone reports a problem.

I agree about more internal testing on various setups,making RCs even for changes that seem innocuous and giving people resources for testing, but... realistically the number of people wiling to put the effort will as always like be tiny and not end up including those who have the problematic setups. Just how things are.

Edited June 23, 20251 yr by Kilrah

Agreed I should have included that I have opted to bond my NICs, however individual docker issues and configurations have nothing to do with the release itself. Any issues arising there need to be addressed with those relevant teams that have provided the container's template. The release thread should be limited to issues related to the core OS and update in question. I include the Plugin list because certain plugins have historically caused issues with system stability which is why everyone is asked to upgrade or disable incompatible Plugins BEFORE upgrading. Dockers are obviously "contained" and rarely have an affect on the system as a whole because of this.

The reason I'm pushing for sharing hardware is that, for example, if we see a specific NIC included in a build and that user is reporting regular crashes, then another user posts about crashes but with a different build but happens to share the same NIC, we can start to see patterns form. So I disagree, there is absolutely a benefit to sharing the base system specs since it may become very obvious very quickly if that knowledge is clear up front. If more information is needed, that is the purpose of creating a bug report thread and providing logs etc.

Edited June 23, 20251 yr by cj0r

3 minutes ago, cj0r said:

however individual docker issues and configurations have nothing to do with the release itself.

The issues with 7.1.3 were specifically affecting specific Docker/networking configs. It was perfectly fine here and AFAIK not related to specific hardware, only how it was used.

Edited June 23, 20251 yr by Kilrah

I may have misunderstood what the solution was. I hadn't seen that before if that was the case and this may have been a rare exception.

Regardless, let's keep going and workshop something that will address the overall confidence/testing issues.

Edited June 23, 20251 yr by cj0r

My point is that having everyone posting the entire details about their setup and whether it works or not is both too much effort for people to be willing to put into providing and too much effort someone considering an upgrade to go through.

Are you going to spend a whole day reading reports and looking at configs and logs from dozens of people before upgrading? No, you upgrade, if it works then great, if it breaks you downgrade and report the issue, takes a fraction of the time.

Edited June 23, 20251 yr by Kilrah

Well you only have to add your hardware specs to your signature one time and then maintain if you change anything, that saves any future admin work right there and isn't asking much of community members. In fact, it has been recommended to do so for years now but it never fully caught on. I, and I assume a lot of other users, look for success cases with similar builds to mine before I upgrade. It takes a quick glance at the release thread, not reading through logs or reports (that's overexaggerating).

Upgrading and rolling back is a useful fallback feature for a once in a blue moon failure during an upgrade, it's not supposed to be a part of your regular workflow or something you expect you'll need to utilize when upgrading.

Regardless, we don't agree on this suggestion and I get that and am fine with it. What suggestions do you have to maybe help improve the issues Unraid is currently facing in these release threads?

Maybe something simple like renaming Bug Reports to “Bug Reports & Test Releases” might improve visibility?

25 minutes ago, itimpi said:

Maybe something simple like renaming Bug Reports to “Bug Reports & Test Releases” might improve visibility?

Along these lines, my suggestion would be to reorganize the "Stable Releases" and "Prereleases" categories in the "Bug Reports" so that one category houses all bug reports (since we already put the version number in the bug title and bugs may span several releases) and use the other category purely for the pre-release announcement and discussion threads.

I would also be nice if there were a convenient way to tag each issue with all the releases it has been confirmed on.

Ya I think that would be a good first step. Ideally I still feel like all releases should be housed in the same location but I understand the importance of clearly distinguishing between the 2 kinds of releases as to not confuse inexperienced users etc.

Also agree with primeval so there's less bouncing around to find similar bugs.

Another user in the 7.1.4 thread had a next level suggestion of having an option for Unraid to auto capture configuration information (not full logs but a snapshot of a system essentially) in an effort to remove the tediousness of users manually sharing that info. I know this goes beyond a forum enhancement but it wasn't a bad idea.

I'm still on 7.01. I didn't have time for the update to 7.1.0 and a few days later I saw the Patchnotes of 7.1.1 and felt like I dodged a bullet. And the changelogs to 7.1.2 and 7.1.3 didn't really inspire confidence. I don't have a fancy setup, just lots of docker containers and two VMs on pretty standard hardware - I don't think that I have a special case that would break.

What's holding me back is the effort to fall back to the older version if something breaks. It would be nice to have a snapshot of the pre-installed version that I can just choose when booting the server like some Linux distros have (yes I'm using Arch btw... 😅)

Edited June 27, 20251 yr by Atherel

9 hours ago, Atherel said:

What's holding me back is the effort to fall back to the older version if something breaks. It would be nice to have a snapshot of the pre-installed version that I can just choose when booting the server like some Linux distros have (yes I'm using Arch btw... 😅)

Unraid has the option to revert to the previous release under the Tools section of the GUI.

Even easier is to make a backup of the flash drive (by clicking on the boot device on Main and selecting the Backup option) before attempting the upgrade and if any issues are encountered restore the backup to the flash drive to revert.

On 6/28/2025 at 9:49 AM, itimpi said:

Unraid has the option to revert to the previous release under the Tools section of the GUI.

Even easier is to make a backup of the flash drive (by clicking on the boot device on Main and selecting the Backup option) before attempting the upgrade and if any issues are encountered restore the backup to the flash drive to revert.

Downgrading via GUI requires Unraid to be reachable over the network. Reading the threads from the last updates, this wasn't possible for someone users.

Restoring the flash drive without network access means that I have to get the drive from the server and later put it back, and the flash drive is not easily accessible for me.

Being able to fallback to the previous version via boot menu would make it way easier and thus lower the barrier to install the update for me.

Edited July 1, 20251 yr by Atherel
Somehow had text from draft in it

3 hours ago, Atherel said:

Downgrading via GUI requires Unraid to be reachable over the network.

3 hours ago, Atherel said:

Being able to fallback to the previous version via boot menu

If you're able to access the boot menu you're able to use GUI mode to use the downgrade feature.

I'd like to see better posting/updating of discovered/confirmed issues in the release notes.

I'd also like to see development status, rather than the current blackhole question mark of what's going on.

What I mean by that is, right now we have 7.1.4 and we have heard nothing from Lime Tech about whether they're working on bug fixes in a 7.1.5 release, or whether they've given up and are working on 7.2.

i.e. it'd be nice if we could at least have some idea of what's happening/what they're thinking.. e.g. if there's an issue or two in 7.1.4 that are being worked on for a 7.1.5 release, then it'd be nice to know about that so those of us that are more conservative can wait for 7.1.5 rather than wondering if 7.1.4 is stable enough and to try it. If there's not, then it'd be nice to know that too... i.e. we view 7.1.4 as generally pretty stable, we've moved on to 7.2.

My problem is, and this is where the lack of confidence comes from...

I see 7.0 come out with a heap of new features, and think hmm, I'll wait and see how stable it is..

7.0.1 comes with some fixes, but still discussions of issues.

Nope, I'll wait for 7.0.2 and see how that goes.

But no, on to 7.1 which introduces a whole bunch more changes.

Wait for 7.1.1, nope, more issues

Wait for 7.1.2, nope, more issues

Wait for 7.1.3 nope, more issues, almost immediately... sheesh what testing went on here

Wait for 7.1.4 rush fix for 7.1.3, but looks to be starting to get fairly stable now, so.... what is the status????

Here we are over a month later with no communication on whether there's a 7.1.5 to clean up a few more of the outstanding issues, or whether they're going to go to 7.2. Going to 7.2 starts the whole conservative cycle all over again because of new introduced features. My gut feel given the radio silence is everything has moved on to 7.2 and we will see a 7.2 release around this anniversary thing coming up. So that'll start the cycle all over again.

I've been using unraid for a very long time. To highlight my recent upgrade path I've gone from 5.0.5 > 6.1.9 > 6.9.2 > 6.11.5 > 6.12.10 (tried 6.12.11 but had to revert) > 6.12.15. I am still on 6.12.15.

The 7.1.x series is starting to look fairly mature, with the exception of the rush-fix in 7.1.4. But it seems like it's falling just a little bit short if we now move to 7.2.

So I guess my ask here is also that it'd be nice to see a given train worked a bit more toward bug fixes before moving to the new features. Maybe an LTS version, effectively. So perhaps this doesn't need to happen every point release. But perhaps pick a sensible/good one, and keep at it with bug fixes in that release a bit longer for those of us that err on the more conservative side.

Edited July 25, 2025Jul 25 by warpspeed

I have been using unRAID since 2012 and, until last year, never experienced any problems with upgrading. My first failure was shortly after the new upgrade GUI was introduced and I am also anxious to update and still stuck on 7.0.1.

I welcome this discussion and would suggest not to jump to conclusions until someone actually involved in the releasing provides insights and an assessment why releases have, seemingly, become less reliable.

Maybe it is due to the increasing variety of hardware, maybe because of the increasing complexity of the software. These would be harder to fix than a sloppy/rushed release process, for example.

Edited August 7, 2025Aug 7 by tazman
grammar

On 7/24/2025 at 7:42 PM, warpspeed said:

I'd like to see better posting/updating of discovered/confirmed issues in the release notes.

I'd also like to see development status, rather than the current blackhole question mark of what's going on.

What I mean by that is, right now we have 7.1.4 and we have heard nothing from Lime Tech about whether they're working on bug fixes in a 7.1.5 release, or whether they've given up and are working on 7.2.

i.e. it'd be nice if we could at least have some idea of what's happening/what they're thinking.. e.g. if there's an issue or two in 7.1.4 that are being worked on for a 7.1.5 release, then it'd be nice to know about that so those of us that are more conservative can wait for 7.1.5 rather than wondering if 7.1.4 is stable enough and to try it. If there's not, then it'd be nice to know that too... i.e. we view 7.1.4 as generally pretty stable, we've moved on to 7.2.

My problem is, and this is where the lack of confidence comes from...

I see 7.0 come out with a heap of new features, and think hmm, I'll wait and see how stable it is..

7.0.1 comes with some fixes, but still discussions of issues.

Nope, I'll wait for 7.0.2 and see how that goes.

But no, on to 7.1 which introduces a whole bunch more changes.

Wait for 7.1.1, nope, more issues

Wait for 7.1.2, nope, more issues

Wait for 7.1.3 nope, more issues, almost immediately... sheesh what testing went on here

Wait for 7.1.4 rush fix for 7.1.3, but looks to be starting to get fairly stable now, so.... what is the status????

Here we are over a month later with no communication on whether there's a 7.1.5 to clean up a few more of the outstanding issues, or whether they're going to go to 7.2. Going to 7.2 starts the whole conservative cycle all over again because of new introduced features. My gut feel given the radio silence is everything has moved on to 7.2 and we will see a 7.2 release around this anniversary thing coming up. So that'll start the cycle all over again.

I've been using unraid for a very long time. To highlight my recent upgrade path I've gone from 5.0.5 > 6.1.9 > 6.9.2 > 6.11.5 > 6.12.10 (tried 6.12.11 but had to revert) > 6.12.15. I am still on 6.12.15.

The 7.1.x series is starting to look fairly mature, with the exception of the rush-fix in 7.1.4. But it seems like it's falling just a little bit short if we now move to 7.2.

So I guess my ask here is also that it'd be nice to see a given train worked a bit more toward bug fixes before moving to the new features. Maybe an LTS version, effectively. So perhaps this doesn't need to happen every point release. But perhaps pick a sensible/good one, and keep at it with bug fixes in that release a bit longer for those of us that err on the more conservative side.

Thank you for taking the time to write out these thoughts - we really appreciate it. I completely agree that more transparency and better communication around our plans would be ideal. We are actively discussing ways to improve and I hope to bring more transparency in the coming months. Have you checked out our recent Uncast episode where Ed took our listeners behind the scenes of the company with myself and my colleague, Eli? You might enjoy it: https://www.youtube.com/watch?v=1OwCu3T92z4&t=2908s

Thanks again for your thoughts and for being a part of our community!

On 8/7/2025 at 1:20 AM, tiffanyj said:

Thank you for taking the time to write out these thoughts - we really appreciate it. I completely agree that more transparency and better communication around our plans would be ideal. We are actively discussing ways to improve and I hope to bring more transparency in the coming months. Have you checked out our recent Uncast episode where Ed took our listeners behind the scenes of the company with myself and my colleague, Eli? You might enjoy it: https://www.youtube.com/watch?v=1OwCu3T92z4&t=2908s

Thanks for the response Tiffany. I did watch that video, it was a great one.