itimpi

Which method did you use? Going via the contact support form seems to work reliably but other routes are less reliable for some reason. If you did not get the automated acknowledgement then the request almost certainly did not get through. If necessary/easier you can do a manual upgrade to 6.12.10 by following the procedure documented here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.

You can do a manual upgrade to the current 6.12.10 release by following the procedure documented here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. The Unraid OS->Manual section covers most aspects of the current Unraid release. Having done that the purchase option should now work. If you still encounter problems you will need to contact support as they handle all licencing issues.

It is always possible that disk7 is not really dead as the fact it is disabled simply means a write to it failed. This can be caused by external factors such as cabling or power. It is not showing up in the SMART information in the diagnostics so at the very least it is currently offline. Have you taken any action to confirm it is dead? @JorgeB mentioned using ddrescue with the parity drive. It might also be possible to do it with the disabled drive as an alternative way of recovering its data. I have succeeded in the past with ddrescue on drives that would fail their smart TESTS. Regardless I would keep both of those drives intact until one of the approaches has worked to maximise recovery chances.

The top level is the Share name (which maps onto a folder at the disk level). Each additional folder in the files path adds another potential level. Looking at your examples you would need '2' to keep all of Breaking Bad on the same drive or '3' if you are happy for each season to potentially be on a different drive. Your second example has an extra folder in the path so not sure what you want to keep together there?

That is the location from within Unraid (/boot is where the flash drive is mounted). If you have the Dynamix File Manager plugin installed then it has built-in capability to view/edit such files which might be the easiest way to do it.

They should not be, and often cause problems. Your initial results suggest at that point you might be getting a 10Gb link in one direction and something like 2.5Gb in the other.

I would certainly recommend removing stopping the array as with disk4 playing up it will take forever 😞 It is your choice as to whether you want to try and resolve why disk4 is having issues or initially just get disk3 up and running? It is possible that disk4 just has a cabling issue (power or SATA) and the drive is physically OK.

Not without some sort of custom script to handle this. Normally it the job of parity to provide some level of hardware redundancy. Having said that you should still be backing up critical files elsewhere off the server as even parity does not protect against certain types of errors that can result in lost files.

That might suggest a PSU overload issue when the server tries to spin up all drives simultaneously? What PSU do you have? Since you have not provided the diagnostics for us to look there perhaps more information about your configuration would help.

Do you mean pre-clear (which happens before you add a drive to the array) of Clear which is what Unraid does by default when adding a new drive if it was not previously pre-cleared? There is a discussion of the difference here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. I am guessing from the diagnostics that you mean Clear on disk4? If that is the case you are getting lots of write errors and resets on that drive and in the diagnostics and it appears to have gone offline. I would suspect a cabling issue (power or SATA) but it could be the drive itself but as it is offline we cannot see any SMART information. You will almost certainly have to power-cycle the server to get that drive back online.

Did not spot anything obvious in the diagnostics. The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

That will almost certainly be hardware related (in which case there is nothing in the log). I looked and could not spot anything. The most likely culprits would be PSU not coping with the load or something thermal like the CPU overheating.

Those look fine from a scheduling perspective. We do normal, however, recommend that the automatic scheduled checks are set to be non-correcting so that if you have a drive playing up it does not end up corrupting parity before you realise there might be an issue. Then it is only the manual checks that are set as correcting after you have fixed any hardware related issues that might have caused parity to be partly invalid in the first place. You can get to the flash drive by clicking on the Boot device on the Main tab. If you want it to be visible over the network (by default it is not) then you need to set the SMB settings to allow this (in which case if shows up as the 'flash' share.

The log you mention is missing! Having said that the syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field. When you say 'rebooting' to you mean it actually reboots by itself or do you mean it 'freezes' and you have to manually force a reboot? Asking because if it spontaneously reboots this suggests a hardware issue.

I suspect that it is not the verification that takes the time, but simply uncompressing the archives and loading them into RAM to run Unraid. Having said that If it really does speed up the Unraid boot time by any appreciable amount it would be good to know.

It is something that has been asked for before but I have never seen a commitment to it being possible. At the moment starting up the services (e.g. docker) is tied to the main array starting. It is possible that something might materialise in the Unraid 7 timescale when the need to have the main Unraid array is likely to be removed but until we see how that is being handled no idea of the side-effects.

If you have not tried it already running with less RAM sticks can sometimes help as it puts less load on the RAM controller.

No - it is that less RAM sticks can sometimes help as that puts less load on the RAM controller, and it also eliminates the case where one stick is faulty/borderline and the other is OK. It is at least an easy test to carry out to see if it helps pinpoint an issue.

That definitely looks like a network issue as you would expect an iperf3 test to give the same results in both directions. What can cause the different speeds depending on direction I have no idea I am afraid.

It is not clear from your description but steps 1 to 5 were running against the 'emulated' drive and would be fixing an 'unmountable' status. Steps 6 to 12 are rebuilding the emulated drive contents back onto a physical drive to clear the 'disabled' status.

Yes - but the way Unraid works the free space is the sum of the drives that actually have part of the share on it - not the disks that could potentially have it. In this case the System share is only on disk1, It is set to use cache for all NEW files, but as there is no secondary storage set then you will see that it says mover will take no action, and thus existing files on the main array are left there. If you want all the files to end up on the cache you need to temporarily set the array as secondary storage, run mover to get all files transferred to the cache and then only then remove the secondary storage settings. You may need the docker stopped while doing this as mover will not move open files. There are benefits to doing this in that once all of 'appdata' is on the cache it can be an Exclusive share which gives better performance. Actually setting docker to use a folder rather than a docker.img file is NOT the default so you must have changed it at some point. With that setting the docker.img file is not being used.

If the parity checks are starting on boot (due to unclean shutdowns) then you may find this page from the the online documentation accessible via the Manual link at the bottom of the Unraid GUI to be of use in troubleshooting Unclean shutdowns. If it is not just at boot time but while already running then perhaps you should post a screenshot of Settings->Scheduler->Parity Check in case you have not got it scheduled as you think.

If it is a time issue, then you should go to Settings->Date and Time and ensure that it is correct there.

You can try backing up the flash drive and recreating it from the backup to see if helps. That might help if for some reason the system is having trouble reading the flash drive. You could also try posting your system's diagnostics to see if we can spot anything in there. Failing that you will need to contact support to get this sorted as they are the ones who deal with any licencing issues. If you go this route make sure you get an automated acknowledgement to confirm your request was received.

I would suggest doing an iperf3 test in both directions to see if there is any network issue.