The memtest provided as standard with Unraid will only work if booting in 'legacy' mode. If booting in UEFI mode then you can download a UEFI compatible version from memtest86.com
Not yet had the chance to look at your diagnostics but thought it worth mentioning that this is covered here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.
FYI: SMART for all disks is already part of the diagnostics so no need to normally provide it separately.
You can never assume that the /dev/sdX type device names will not changed as they are assigned dynamically by Linux during the boot process. If you want invariant names use something from the ‘dev/by-* family.
You need to run without the -n flag or no corrections are ever made.
I wonder if there us some hidden (unprintable) character in the name of the folder (or a file it contains) and that is upsetting Sambz.
Disks are allocated using their serial numbers and where they are connected is not relevant (unless it somehow results in presenting a different serial number to UnRaid)
Could not see any obvious sign of a disk failing, although there were signs of what might be cabling issues on disk2 and disk4..
I would suggest that running long SMART tests on all drives might be a good idea.
An easy solution is to set the User Share concerned to Use Cache=Yes and then invoke Mover manually from the Main tab which will sort this out for you without any risk of making a mistake that could lose data. Afterwards you can set the share's Use Cache setting back to the behaviour you want going forward.
That is a 6.8.3 issue due to a change at the remote end. It is fixed in 6.9.2 (although if for some reason you cannot upgrade to that release there is a workaround posted in the forums).
Yes you need to reinstall them.
if you go into Apps -> Previous Apps then you can tick of the ones you want reinstalled and they will then be put back with the same settings that you had earlier.
Normally if you are over-writing an existing file it is updated ‘in-place’ which can mean that if they are spread across multiple drives you end up with multiple drives receiving writes.
Fair enough. I tend to think that since a parity check (assuming it is going to return the expected 0 errors) is basically just system housekeeping and avoiding impact on other usages of the system is far more important than elapsed time.
One problem with you original question is that as far as I know there is no reliable way to detect if an application such as Plex is being actively used. This applies to other usages that I can think of as well.
A good rule of thumb is that it will take about the same time as it does to do the first 8TB of a parity check on your system.
After all a rebuild has to write every sector on the drive as fast as possible and the parity check reads every sector as fast as possible so they tend to be comparable.
If you bind the GPU to vfio then this will hide the GPU from Unraid and stop UnRaid from being able to use it for GUI mode display. If you start the VM does the VM see it? If so then setting the VM to auto start might be the best way forward?
Thinking about it you are correct. When I started with UnRaid I wanted to use 3TB disks so had to go with the v5 beta at the time to be able to use them.
With UnRaid it is simple - add up the sizes of the data drives
the only rule to remember is that any parity disks cannot be smaller than the largest data drive, and parity drives do not add to the useable space.