warpspeed

Nope Agree. I've been using unraid for a very long time. Nearly 15 years.

These quick-fire follow up releases because things were changed between RC and final really make me lose confidence in a given release. 7.2.1 should have been released exactly as RC1 with no other changes. If there were known broken things or things that needed fixing then there should have been a 7.2.1 RC2 to test those before releasing as 7.2.1. In part this release seems to have happened because there were surprise changes between 7.2.1 RC1 and 7.2.1 Final that now need to be fixed. Please stop doing this. It undermines the confidence of a given Final release having been tested properly.

That shouldn't happen. If it is, then there should be an RC2. The difference between final RC and release should be zero except for version number.

Thanks for the detailed reply @EDACerton , that all sounds entirely reasonable to me. Portability wise, I wouldn't think that'd be too critical these days aside from making sure folks are aware of it. Worst case it requires a re-auth and changing the IP on the new entry, and perhaps any ACLs or groups. FWIW it's already in use on some other platforms. I've also managed to get it to work inside a VM on unraid by enabling the VM to use the TPM. It's worked okay in there for me so far. But I only did it on the one. All my iDevices seem to be using it, but obviously that's a different platform with a different chip for encryption. App Store version has always had it, but now it can be done with the Standalone too, and that seems to work okay so far from what I've seen.

Can we get this added for machines with a TPM: https://tailscale.com/kb/1596/secure-node-state-storage

Solid release. Ran both RC's with no critical issues. Just updated to final. No issues so far.

Upgraded from rc1 to rc2. No new issues so far. No critical issues in rc1 from my point of view either. All minor niggles reported in the prerelease section.

Just coming back in here after a few days to say generally my server has continued to be stable after the upgrade to 7.2-rc1. The only real point of note that I needed to deal with was the SNMP plugin broke, I had to remove and reinstall the SNMP plugin to get it working again. Other than that my server is working as expected. Hardware transcoding using my Intel 12700 iGPU continues to work, all my NFS mounts work, VMs, dockers, tailscale, etc... all seem ok.

I bit the bullet and upgraded my 6.12.15 primary server to 7.2-rc1. Generally it seems to have gone okay, but I did find a few points of note, some might not be actual issues, I'll open bug reports about the ones that are, but basically: Intel i915 driver had a sad in dmesg on boot... a trace about something haven't yet figured out if that's an actual problem or not Edit: Doesn't seem to be an actual problem, iGPU is happily hardware transcoding without issue There's some junky characters in some logs relating to the API in syslog e.g. root: #033[95m[Nest] 12074 - #033[39m10/05/2025, 2:56:49 PM #033[95m DEBUG#033[39m #033[38;5;3m[ConfigFileHandler:api.json] #033[39mError: Config file does not exist at '/boot/config/plugins/dynamix.my.servers/configs/api.json' SNMP plugin decided to auto update without my interaction and then failed, only option seems to be to remove it and reinstall? e.g. Starting snmpd: /usr/sbin/snmpd: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory Edit: looks like the update didn't completely work, deleting and reinstalling from Apps has fixed it text "starting dockers" on docker page is a serif font instead of sans-serif there's also some funky refreshing going on here that causes the autostart sliders against each docker to animate every few seconds till they all start dmesg kernel complaining about bad command (doesn't appear to be an actual problem) Kernel command line: BOOT_IMAGE=/bzimage initrd=/bzroot nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off Unknown kernel command line parameters "BOOT_IMAGE=/bzimage", will be passed to user space. commented out explanations on the drivers page from limetech/unraid are missing from the right far most field for kvm and mpt3sas... the actual options are still there, just not the comments explaining That's all I've observed so far. Otherwise my server appears to be working okay... bearing in mind I've only had it booted for about one hour :)

Not necessarily that formal/certified. More so a visible flag or tickbox for a plugin author to basically flag that the current version is (to the best of their knowledge) compatible with a given release. e.g. those plugins I've listed, it'd be nice, even without an actual version update, for the author (or maybe the community even) to be able to flag up front that those plugins do indeed work with the latest versions (or not). Right now the only way one can figure that out is to scour the forums for folks having problems, then assume lack of problems means it works.

Over in here: https://forums.unraid.net/bug-reports/prereleases/

I think in code, this might be somewhat already addressed by some plugins being blocked on older versions, etc. but one thing I feel that is sort of missing is a visual and/or code based representation/approval/certification of a plugin being compatible with a given NEW version of unraid. This is one of my concerns when jumping up new versions, especially when there are significant changes.... will my existing plugins be compatible with the new version. Because of this, I always generally wait a while once a new version is released to give a chance for plugin updates to be released to correct any issues relating to the new version. It'd be really good to see some sort of exposure in the web gui of which plugins are confirmed compatible with what versions of unraid. e.g. If I'm sitting (as I am) on 6.12.15, which of my plugins have since had updates that confirm they're compatible/ok with say, 7.0, 7.1, 7.2? without needing to 'upgrade and find out'. Generally I suppose one can assume compatibility if the plugin has been updated after a given release. But it's not necessarily clear if the plugin developer has actively made changes during a beta or rc period to pre-confirm/test/align/correct compatibility. It'd be nice to have some way of that being able too be flagged/displayed to users in the plugin web interface. For example I'm sitting on 6.12.15, and I have four plugins that have not been updated during 2025... I don't really know, without spending a lot of time on the forums, if they're properly compatible with 7.0, 7.1, 7.2. For point of illustration those plugins are: CA Cleanup App Data, dated 2024.11.28 Dynamix System Temperature, dated 2024.07.10 SNMP 2023.04.20, but newer one blocked 2024.11.01 ZFS Master dated 2024.12.09.104 The rest have been updated during 2025, so I can sort of assume/guess that they're compatible with 7.0 and highly likely 7.1... but then 7.2, not sure. Especially since the GUI changes coming in there. It'd be nice, for example, even with those older ones, even if they don't need an update, for there to be some sort of visual representation that they're confirmed functional and working with current stable versions... before upgrading.

RC1: https://forums.unraid.net/topic/193916-unraid-os-version-720-rc1-available/

Thanks @ljm42 , FWIW, both of your posts above, very useful and factual info. The number of systems installed and general low level amount of issues brings high confidence in a good stable release. The summary of changes in the second post is a really useful time saver. Also as others have noted, 7.2 seems to be looking like a good solid release. I still have my main prod server on 6.12.15. I'm confident enough with what's transpired so far in the beta's to try 7.2 on it once fully released.

Related, and I know we've plenty of time for this, but is there any work in unraid happening on guidance to convert V5 filesystem timestamps to last beyond 2038 or whenever it is.

I just figure it might be something some might want to know about as they might want to correct it properly.

I wonder if this is something that fix common problems should flag, along with an explanation similar to what you've written above.

Also worth noting with the Kernel version update, this is likely a useful improvement/fix from Beta 3 for folks having issues with NVMe drives dropping:

Been nearly a month since beta 2, just curious if there's some blocker to an updated beta?