warpspeed

They don't have to do them instantaneous, what I'm saying is they should sync the releases, especially when it comes to security releases. If one is ready first, hold it back till the others are ready. Then push them all out at once. It will also help reduce confusion for those that are on older release trains that can't upgrade to the very latest, and those that are on the latest that don't understand the releases and scratch their heads wondering which release is the latest/best to be on.

Ahh that's interesting, and quite a gap the opposite way around then. My point still stands, it's just inverted. 7.2 should have seen a release at the same time as 7.3, with the same security patches. :)

It's a release candidate, so clearly testing is not entirely complete or it'd be a final. and if for some reason they cannot release 7.3.x release candidate at the same time, then they shouldn't disclose details about security vulnerabilities until such time that all releases are available - though that is hard when it's upstream packages, or if already disclosed - which is even more reason to get all the releases out. Reality is they should have held this RC until the 7.3.x RC was also ready... or if they were working on some other features that aren't ready yet, but needed to get this RC out, then they should have also rolled an interim RC for 7.3.x including the same security patches as 7.2.x.

From a security patch posture point of view, it's not a good look to remediate an older release and not the current release at the same time. Basically like announcing that 7.3.2 now has exploitable vulnerabilities that are not patched. This is why others generally release patches for all supported OS versions at once. Releases that include security fixes should ideally be done at the same time.

Shouldn't 7.3.3 also be available at the same time?

The kernel change section seems incomplete/lacking formatting. i.e. From/To versions Why is the usb auto suspend bit there on the same line,

What about the NFS version setting in the NFS settings in the unraid GUI?

Perhaps the variant of Android you're using only works with NFSv3. I'm using Kodi on Debian based systems. i.e. not a fault of unraid, but rather an Android system limitation

As I've previously posted, I'm using NFSv4 just fine with Kodi. What I'm doing: Using autofs or fstab directly on the host, don't configure NFS directly from Kodi itself. i.e. do not do it in the GUI, do it from the command line using fstab or autofs (autofs recommended, it's more resilient) Then set Kodi to use the NFS mounted path for media Set unraid NFS Max Protocol setting to NFSv4. I have my unraid shares using 'sec=sys,anonuid=99,anongid=100,all_squash' Using fstab, I have the mounts basically using defaults Using autofs, I found I had to add 'fstype=nfs4' to the NFS config Exclusive Shares disabled

I'm having none of those problems. The only issue I have right now is when I turn on Exclusive Shares, they don't show up in NFS. But that's easily mitigated by turning off Exclusive Shares.

7.3.0 > 7.3.1 working fine here so far

Use autofs or fstab rather than doing it in Kodi autofs is best

How are you mounting in Kodi? I had some similar issues a long while back with some NFS hosts connecting to unraid. It might not be the same, but I found I had to add "fstype=nfs4" to the mount point configs.

Updated from 7.2.6. Uneventful so far. No issues observed so far.

Thanks, did that and it did come back as precleared.

I have a disk I precleared some time ago, but it's no longer showing as precleared. Is there a way to a. do a recheck to make it show precleared and/or b. verify that if i add it to the array it's not going to try and clear when I add it to the array.

Great stuff keeping on top of these security updates. Well done.

Great work getting this out so fast and including CVE-2026-31431 Up and running fine here so far from rc2.

Can we get 7.2.5 patched for CVE-2026-31431

Will CVE-2026-31431 be addressed in 7.3.0?

I've been running this version for several days and it's been a complete non-event for me. Everything appears to be working fine.

Possibly this: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.83&id=ba4811c8b433bfa681729ca42cc62b6034f223b0

Since upgrading from 7.2.4, I've seen this in my log files, not sure if it's an issue or not: 20:43:03 <hostname> nfsdcltrack[484481]: Unable to write to /proc/fs/nfsd/v4_end_grace: Device or resource busy 20:52:38 <hostname> nfsdcltrack[526390]: Unable to write to /proc/fs/nfsd/v4_end_grace: Device or resource busy 21:10:07 <hostname> nfsdcltrack[603065]: Unable to write to /proc/fs/nfsd/v4_end_grace: Device or resource busy

Thanks, nice to see the Kernel update too

It's great to see a stability release for 7.2.x ahead of 7.3, also great to see an RC ahead of releasing it. 👍