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.