itimpi

What have you set the network card to emulate at the VMWare level? Sounds as if it is not one for which Unraid includes drivers. You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

@Vilaran You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback when you next encounter this issue. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

You will need to make sure that the new board posts correctly before trying to plug in extra cards or even trying to Unraid It is very unusual for two motherboards to both fail to post. Could it be something less obvious like a power issue?

Aren’t the last two just temporary files that are not present if the container is not currently running?

Support is US based so response time can vary according to the time you try. are you saying you retried the download link and got your key file that way so are good to go? Just put it into the config folder on the flash drive. it is always a good idea to make a periodic backup of the flash drive. If you can boot Unraid then you can easily do this by clicking on the Boot device on the Main tab and selecting the backup option from there. You can also simply put the flash drive into another computer and copy its contents (the config folder is all that is really needed as it contains all user specific information).

Are you saying that you cannot even get the system to POST and the BIOS screen to come up? That would strongly suggest some fundamental hardware related issue, although no idea what.

Unexpected restarts strongly suggest some sort of underlying hardware error. It could be something like a PSU problem or perhaps a cooling issue if it is not RAM related. unfortunately the logs in the diagnostics restart after a reboot as they are purely in RAM.so do not show what lead up to the reboot. To get a log that survives a reboot you need to enable the syslog server.

You do not mention how you are measuring this and what the transfer is to/from. If it is the PC then that has a theoretical maximum of around 250MB/sec if your LAN is 2.5 Gb/sec.

You normally get a response in hours, not days! Are you sure you have not got a copy of the licence file somewhere? If so you just need to insert it into the config folder on the flash drive and you are good to go.

You will need to contact support to get this resolved as the automated licence transfer requires you to have the original licence file.

If a drive will not pass a Preclear then you should not use the drive. If a drive fails during normal use of the array then Unraid requires all the remaining drives to be able to read error free to recover the contents if a failed drives. Pending sectors are never a good sign although it is possible that they can get reset to 0 during the Preclear process. as an alternative to pre-clear you can run the extended SMART test on the drives. If this fails a drive should not be used.

Functionally they are identical. In one case you do not tick the Parity is Valid box after New Config so Unraid knows it has to rebuild parity with the new drive set and starts doing this as soon as you start the array. In the other case you incorrectly check the Parity is Valid box so Unraid thinks it does not need to rebuild parity when you start the array, but when you run the correcting check it ends up having to correct sectors that do not agree with parity. I have a feeling that there may be a slight performance difference in that the sync is likely to be slightly faster. In both cases until you have valid parity your are not actually protected against a drive failing.

You do not always have one if the repair process has had no issues. If you have one it will be on the drive that you repaired. It also then normally shows up as a User Share as well because it is a top level folder.

If you read @JorgeB answer he recommends a sync (which is effectively a correcting check) followed by a non-correcting check to make sure everything is now good.

You now need to check if you have a lost+found folder as that is where the repair process puts any files of folders for which it could not find the directory entry to give them the correct name and gives them cryptic names. Unfortunately if you do have lost+found then sorting it out is a manual process although the Linux file command can at least give you the content type for any file. In practice if you have reasonable backups it is easier to restore from them.

I am surprised you do not simply run Windows natively as it has a built-in hypervisor (Hyper-V) as that by-passes the issue of requiring drivers that most users do not need. You can then even run Unraid in a VM if you want it for its NAS capabilities or run docker containers under Docker Desktop.

The repair is looking for a superblock which it will never find since you used the wrong device name so you should abandon it.

The device name always includes the partition number, and the exact name can vary according to the Unraid release and whether you are using encryption or not. I suspect that the format is set to 'auto' which is why no option is offered via the GUI. Explicitly setting the format to be XFS would give you the option. If you want to to do it via the CLI then the correct device name would be /dev/md3p1 which maintains parity since you appear to be using Unraid 6.12.4 without encryption. Going via /dev/sdc1 would invalidate parity.

That is the wrong device name. Is there any reason you are not doing it via the GUI by clicking on the drive and then using the check/repair from there? That way you automatically get the correct device name.

This is not a supported scenario unfortunately. I think the closest you will get is if you are using a ZFS pool and the ZFS arc is being used to cache recently accessed files. However the ZFS support is new and still evolving with Unraid so no idea if there are 'gotchas' that I am not aware of.

Yes (as you also will not have valid parity at that point).

Have you tried running without Docker started? I noticed that there appeared to be a container continually restarting although this should not stop everything from running. I also noticed that the 'system' share had files on disk1 as well as cache. if this is the docker.img file then it would be expected that performance would be badly degraded while the operations you mention are running. Your current settings for this share do not allow mover to transfer files from array->cache. In addition since all the files are not on the cache you will not be able to enable Exclusive mode on the share to get better performance. You also have a share anonymized as 'd-------s' that has files or folders on the cache but the settings do not allow mover to transfer the files off the cache to the array - is this intended? One thing that occurs to me is there any chance that you have a power related issue? An operation like Parity Check starting would put maximum load on the power supply. It can also sometimes cause an issue if you make use of power splitters and connect too many drives to a single power supply line.

If you set the Use Cache setting to No then that applies to new files and any files/folders for that share are left there as mover takes no action in such a case (as the GUI mentions). In other words this does not automatically cause them to be transferred to the array. It needs to be 'Yes' to get files moved to the array, although once this has been done then you can change it to No to stop new files going to the cache. Mover should not leave behind empty folders, although if for some reason they are there it should be safe to remove them.

If you had a cache drive failure then appdata would have started being written to the array so this is where you might get files on the array. Mover will also never move open files so you may need to to temporarily disable the docker (and VM) services to allow mover to take action on files that would otherwise be open. The other point that is relevant is that mover never overwrites an existing file so if the same file exists on both the pool and the array then no action is taken. It is then up to you to remove the copy that is not wanted. Typically this would be the copy on the array as if both exist the pool copy takes precedence but you have to make that determination.

Have you enabled it under Settings->Global Share Settings?