itimpi

The diagnostics from before the reboot showed that the parity disk dropped offline and therefore no SMART information available. Since you say you have checked the sata cabling you might also want to also check the power cabling (note that Power splitters can sometimes cause problems). The diagnostics from after the reboot show the drive back online, and no obvious errors in its SMART reports.

Never heard of this before. Are you sure that the Shutdown and Reboot options are not at the end of the Main tab? It might be worth providing a screenshot to show what you mean.

The test only increments in 10% amounts so it is quite normal for it to stick for a while at each value. I normally estimate something up to 2 hours per 10% increment, but if it is taking longer than that it may not be a good sign. You could check to see if anything is showing in the syslog.

If you have not done a licence transfer within the last year then you should be offered the option to do an automated transfer withut the need to contact support. Unraid will recognise data drives that have previously been used by Unraid and leave their contents intact. If you are not ABSOLUTELY certain of which drives are parity1 and/or parity2 then you could initially leave them unassigned as getting those wrong at this stage wipes their content, Once you are happy you can assign them later to build new parity based on the current data drive set.

You can always delete the docker.img file and let Unraid recreate it and use Apps->Previous Apps to get containers back with their previous settings. however that message looks a little concerning as I would have expected the repair process to fix anything like that. It is possible there really is a problem with the disk. You might want to consider running an Extended SMART test on it to check it can complete that without error.

you might want to try removing the Mover Tuning plugin and then rebooting as it seems to have recently been causing problems with mover operating as expected.

It looks like your ‘system’ share has files on disk3, This means that if the docker or vm services are enabled disk3 and parity will be spun up most of the time. You want to get all the contents of this share onto the ‘cache’ pool to avoid this and to maximise performance. you also have a lot of .cfg files in the config/shares folder on the flash drive for shares that currently do not exist. Deleting these will tidy up that part of the diagnostics and make it easier to spot relevant information.

Unless you have a very old CPU then there is no reason parity2 should be slow. It might be worth attaching new diagnostics to see if any reason can be spotted.

This is the normal action at this point as Unraid has already failed to mount the drive. Normally the -L option causes no data loss, and even when it does it is only the last file being written that tends to have a problem. The section of the the online documentation accessible via the Manual link at the bottom of the Unraid GUI has this section covering repair and it mentions you should use the -L option in point 5.

Do not believe that such an setting exists. You have the option to click the Log button at the top right of the GUI and that will show you the latest entries as well as updating in real time as new ones are added.

This is an extra layer of code above Samba that Unraid uses to manage presenting the Unified view of a User Share that spans multiple drives. Bypassing this means that there is less code executed during file transfers, and also means that Unraid does not need to check other drives for any particular file.

That would be explain things as changing settings can cause the Samba sub-system to be restarted thus causing any transfers in progress to be aborted.

The last thing before the crash appears to be a macvlan related crash and such crashes seem to eventually crash the whole server. Either switch docker to using ipvlan or make sure you have macvlan set up as indicated in the 6.12.4 release notes.

I suspect the docker.img file that holds the container binaries got reset somehow.

Instead of USB Creator have you tried the Manual install method as described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

You can go to Apps->Previous Apps to reinstall docker containers using their previous settings

You need to be in Maintenance mode for xfs file systems and normal mode for btrfs ones.

You can enable the syslog server to get a log that survives a reboot.

Those errors normally suggest a cabling issue (power or sata). You can run an extended SMART test on the drive to see if it fails that the drive is probably faulty.

Another possibility might be power issues. This could be a PSU problem, but can also occur if you use power splitters to get the number of connections you need.

Parity is updated in real time - the check is just a housekeeping task to confirm that it really is good. I am about to be tied up for most of today so wait for @JorgeB to give you guidance on the way to get your data back as it should still be intact.

There should be messages in the syslog about mover starting and finishing. Having said that probably the easiest in this case will be that the 'system' folder disappears from disk6. You can just set up a drive in a new pool, and then set up the share to have this as the primary storage and the array as the secondary storage. and mover direction to be array->Pool As before running mover would transfer the files to this new pool. Once it has all transferred then you can remove the secondary storage option from that pool. It would definitely improve performance as writing to a parity protected array has large overheads as described here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. It is now not going to interact with accesses to the array or to the cache pool. As long as your downloads go via the User Share and do not explicitly name disk6 this should be all that is required. Another option to improve performance would be to enable Exclusive mode under Settings->Global Share settings. For shares that have all their content on a pool this can improved performance as it bypasses the fuse layer in Unraid that is used to handle User Shares.

Anything writing to the array will adversely affect the performance of other applications using the array. You could definitely put your downloads on a separate drive (in a new pool) to get it out of the array. Having said that I have no idea how large your downloads share is - if it will fit you are likely to get a good performance increase by putting on your existing cache drive. Another think I notice is that the 'system' share has part of its contents on disk6. You will get better performance from docker containers if it is all on the cache. You have your mover setting correct for it to be transferred to the cache, but since mover will not move open files you can fix this by temporarily disabling the VM and Docker services under Settings so they do not keep files open in that share and then running mover from the Main tab. When that completes you can re-enable these services.

It looks like the second SSD in that pool dropped offline as indicated in your screenshot which is saying it is missing as you started getting I/O errors on it and it does not show up in the SMART reports. You might want to consider power cycling the server to see if that gets it back. It could also be worth checking that it is properly seated. There is always the chance it really has failed.

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.