itimpi

If when you got the original failure once you had described your problem and posted diagnostics so we could confirm there was nothing else obviously wrong we could have given you the steps to get Unraid to accept the original parity disk so that you could then probably get an error-free rebuild of disk3. In principle it is a good idea to ask for help before letting Unraid do anything you are not sure about.

In most cases sorting out a lost+found folder is more effort than is worth it. The items in there are ones where the directory information giving their names is what was lost. Sometime using the linux 'file' command to determine what type of content is in a file can help - but in your case it sounds as if that might not be much help. It just emphasises that you still need backups of anything that you deem important as things can go wrong that are outside your control. Just as a check are you saying that the drive is NOT disabled (i.e. has a red 'x') against it. Just asking as if it was disabled the repair would have run against the emulated drive, and if that is what happened a repair of the physical drive might be more successful.

It is possible for RAM, CPU and motherboard to go wrong so a failure does not pinpoint the failing item. My guess is it happens more frequently with RAM but that guess is not based on any hard evidence. It can sometimes be worth simply reseating the RAM in its motherboard slots in case it has worked slightly loose. It is possible for each RAM stick to test out fine individually but you still get failures when you have multiple sticks plugged in due to overloading the motherboard memory controller. Carefully check in your motherboard manual the maximum RAM speeds your motherboard+CPU combination can support and remain stable - it is often lower than the rated speed of the RAM sticks, and can vary according to the number of sticks you have plugged in. Anything other than 0 failures means the system will be unreliable. In terms of how long to run the test the general answer is at least for a complete pass, and ideally for longer (e.g. overnight) as long as you are getting 0 errors. No point in continuing a test once you start getting errors reported other than perhaps seeing if it points to a particular RAM sticks/slot.

It looked to me as if you only did the short SMART tests on the drives. Drives can easily pass this test and still not be reliable. You should carry out the Extended SMART test on any suspect drives and any that do not pass this should be replaced. Note that when carrying out the Extended test it can take many hours (with progress only reported in 10% increments) and you should temporarily disable any spindown on the drives being tested.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

One way you can get the symptoms you described is mentioned here in the online documentation accessible via the 'Manual' link at the bottom of the GUI. If this was the problem, though, it would not be as a result of the upgrade.

were you replacing the drive as part of an upgrade process or because you thought it had failed? in other words do you think the contents of the drive you removed are intact?

Sounds as if you are seeing a manifestation of the behaviour described here in the online documentation accessible via the 'Manual' link at the bottom of the GUI. If you are on Unraid 6.10.x or later you could install the Dynamix File Manager plugin and use that to move files instead of Krusader. This plugin is aware of the issue and will use a copy/delete strategy to avoid it.

From the description you give it sounds like has to be something in your laptop or router that is limiting the speed. You have confirmed that Unraid can getter speeds when the laptop is not in the equation.

Have you disabled the docker and VM services and then run mover? It does not look like you have because the diagnostics show: appdata shareUseCache="prefer" Exists on c-------d, disk1 domains shareUseCache="prefer" Exists on disk1 isos shareUseCache="prefer" Exists on disk1 system shareUseCache="prefer" Exists on disk1

I believe this a restriction built into the hardware (although I could be wrong).

The check runs through the extra space to ensure it is still showing as all zeroes so that if you later add another disk to the main array that is larger than existing ones the add process works correctly.

That does not sound like a real fix. Samba does not normally write much to the syslog so if it is Samba that is filling it you need to determine why (e.g. have you turned on some sort of diagnostic or audit logging in Samba).

Click on the shares on the Shares page and change the Use Cache setting for the those shares you want to stay on the cache to Prefer Disable the VM and Docker Services to make sure they are not keeping files open Click on the Mover button the Main tab to run mover When mover completes you can re-enable the Docker and/or VM Services if you want to use these. After that I would suggest reposting diagnostics so we can check that nothing further is needed.

You might also find this part of the the online documentation accessible via the ‘Manual’ link at the bottom of the GUI to be of use.

This is a case where you would need to read the licence terms carefully. My suspicion is that if Windows is not the host then you need the same number of licences for the VMs as you would if they were each physical PCs.

You only want the Yes settings for shares where new files temporarily go to the cache, and later get moved to the array. For shares where you want them to end up on the cache and NOT be moved to the array you need the Prefer setting. The help built into the GUI will help understand why.

There is one main array using Unraid's proprietary mechanism, but you can have up to 30 pools each of which can be an array if you want using the btrfs variants of RAID

you can get the diagnostics from the CLI by using the 'diagnostics' command (as mentioned in the link).

Unraid only issues that command if it thinks the drive is NOT spundown.

It could also be worth checking that any HBA you have is properly seated in the motherboard.

Since you are on Unraid 6.1.3 then installing the Dynamix File Manager plugin and using that is probably the easiest and least error prone way to do this.

How are you splitting it? You can split a single SATA connection into 2 but more than that is likely to cause problems. If you have (or can borrow) a better power supply for testing purposes to see if it help it will be worth trying.

I think one reason to set up multiple shares is the fact that in Unraid settings such as security, file distribution across array drives, cache/pool usage, etc are all set up at the share level and most users want different settings for different types of content.

The fact that the server has been crashing when parity checks start makes me wonder if you have a Power issue as that would be a time of maximum stress on the power supply. What PSU are you using? Are you using splitters on the PSU lines?