trurl

You could use the NVME as cache and not use the SSD. That will be plenty for both dockers/VMs and general caching. I don't recommend trying to combine the NVME and SSD into the same pool, mostly because they aren't the same size, but also because the SSD is probably slower.

Is everything using DHCP?

Why do you have multiple subnets?

First we need to figure out what is on disk1 in the system share. You really want all of that share on cache but diagnostics is showing some of it on disk1. Do you know how to examine the disks? Do you have any VMs?

Actually this is the first time the word "formatted" has appeared in the thread. That word always worries me when I see a user mention it. How exactly did you do this "format" and why?

The latest beta has multiple pools for SSDs, etc. You could use the NVME as fast storage for dockers/VMs and use the SSD in a separate pool for normal caching. That is basically what I do except I have 256GB NVME as fast storage and 2x500GB SSD as cache. You won't get all that speed with parity.

I'm thinking what may have happened is you had the root of user shares /mnt/user as the destination for restoring appdata, with the result that they were all replaced with only the restored appdata.

Perhaps you really meant to say "cache disk" instead of "flash disk". There is no "flash appdata". And you really don't want any data on flash. Flash is just the archive of the OS, and settings from the webUI. The OS archive is unpacked fresh into RAM at each boot, and the OS runs in RAM. Saved settings from the webUI are loaded into RAM, and updates to these settings are saved to flash so they can be reapplied at boot. These are normally the only way flash is used, and you don't want to even attempt to save anything to flash yourself, and flash shouldn't get a lot of read/writes so it will last. appdata is a user share. That user share, along with system and domains user shares, are used by your dockers/VMs, and it is best if these user shares are kept on cache so dockers/VMs performance will not be impacted by slower parity updates, and so these won't keep array disks spinning. Your user shares are on cache and array, and have nothing to do with flash beyond the settings for each user share which you make in the webUI. User shares are simply the aggregated top level folders on cache and array. In addition to a backup plan (make one now), another lesson you might consider is asking for advice before doing the wrong thing.

Maybe he means his internet service only provides 100mbps. Combining NICs won't help with that.

But there is almost no data on his disks. Flash backup will not help with that.

Instead of a photo of the Dashboard, what you want is a printout of Main. That will show all the disk assignments with their serial numbers. Only the serial number assigned to a slot is important, doesn't matter which port it is plugged into.

Have you done memtest?

Post your diagnostics

Unrelated to your issue, except as it relates to the difficulty of making sense of your syslog. Your syslog goes back a few days, I guess this is when you booted back up after So whatever happened we don't have any record of. And many things don't show up in syslog anyway, such as User error of some kind seems the most likely explanation. A little unclear about this part. Appdata Backup makes a backup of appdata, and it can make a backup of flash. The "appdata settings", the way I would interpret that, is the settings for the user share named appdata. Those would be on flash along with a lot of other things, and could be restored from the flash backup if you had that set up. Did you restore the data for the appdata user share? If so, I don't see why this would have been needed, since replacing flash should have no effect on the data on your drives, such as the appdata user share. Or did you restore the flash backup? Or both? Maybe a screenshot of your settings for CA Backup plugin would have a clue what happened, though it won't help now. This is probably your only hope. You must have a backup plan. You absolutely must have another copy of anything important and irreplaceable.

On mobile now so can't look at Diagnostics. There isn't anything called "repair array ". Can you can explain that part better?

169 IP just means you aren't getting DHCP. /dev/sda isn't necessarily /boot. Try another USB port preferably USB2.

Maybe you have a more general docker setup issue. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. If it appears you have an issue not specifically related to this container I may split these posts into their own thread.

Latest beta has a different alignment for SSDs which may improve performance with some devices.

Many are already using latest beta. In addition to new kernel there are some very interesting new features. I seldom hesitate to run betas because I have a good (enough) backup plan.

You should follow the correcting check with a noncorrecting check to make sure there are no errors. If there are still errors then you may have some hardware problem. Also, those lines you posted from the log were about your cache and have nothing to do with the array or the parity check. Possibly you will still have something to deal with there as well.

The disk is disabled so it needs to be rebuilt. Unraid disables a disk when a write to it fails. But that write still updates parity, so that write can be recovered from a rebuild. After a disk is disabled, Unraid doesn't use the disk anymore. Instead it emulates the disk using all other disks from the parity calculation. The emulated disk can be read, and it can also be written by updating parity. So any subsequent writes are also in the array and can be recovered. The actual disk itself is out-of-sync with parity. The only other possible course of action would be to New Config and rebuild the parity disk instead. But since the data disk is out-of-sync and missing those writes, it really makes more sense to rebuild it.

From diagnostics it looks like that drive is still on 4K alignment though so should be OK with 6.8.3. Doesn't look like anything wrong with drive, and cache is mounted. Let's see if @johnnie.black has anything to say.

yes. Assuming the controller presents the disks as before the drives should be recognized so nothing to reconfigure there. If you have any VMs using passthru might need to tweak those. Many of us have done this. Here is my recent rebuild thread:

Not sure what you mean by "re-import". If the original is the same size as the replacement then you should be able to rebuild to the original instead.

Latest beta is kernel 5.7