warpspeed

I'm just doing a manual move now, only just enabled the setting because I didnt realise I would need to enable a setting for this to happen. Not sure if the setting takes effect while Mover is running, but I see no status anywhere, nothing different from the previous version. Not exactly intuitive at all.

Can confirm this issue is happening. Bit odd not to include this fix in the final release given the bug report thread has been open for a while too. This needs to be fixed and/or at least acknowledged with workarounds noted.

We also need the TLS certs revoked (including other relevant packages that use an independent store updated) and the VM issue dealt with (kernel update). Tailscale also needs a related update. All three of these issues need to be dealt with ASAP.

7.3.2 to 7.3.3, working fine here so far. It may have solved an NFS/SHFS issue I had with some large files being moved around causing fuse_hidden files to stay around and not clear

Thanks for your efforts, your experience and contributions will be missed.

So how are these going for people, anyone using them yet?

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