trurl

Your appdata and system shares have files on the array. Probably just as well for now until you get a bigger cache. Just a couple of other things I like to add when people are new. Maybe I already asked them on this or other thread. Do you have backups of anything important and irreplaceable? Do you have Notifications setup to alert you immediately by email or other agent as soon as a problem is detected?

Post new diagnostics.

I don't see how it could matter but I have deleted the screenshot. I can look at the edit history if I want to see it again. Can you go to the emailed URL directly in your browser and download the key instead of pasting it into that page?

I have never needed to deal with keys since before there was a Registration page. Go to Tools - Registration and post a screenshot.

The only way you might lose data is by assigning a disk with data on it to a parity slot so if you're sure you got parity right you should be good. It is going to (re)build both parity when you start the array. I put (re) because Unraid doesn't know either of those disks ever had parity based on the old super.dat. Probably just as well then you will know parity is indeed valid. Then you can do whatever with those other new disks and the old parity(1). Do you have a license .key file in the config folder on the new flash?

The drives I listed above were exactly those, except for parity2 was not in that backup. And parity2 I listed above is 3TB, but parity is that same 2TB in your screenshot. Here is the inventory from the diagnostics you posted today, with (notes) of where they go: May 13 10:51:32 Tower emhttpd: WDC_WD2003FYYS-02W0B0_WD-WMAY02808875 (sdg) 512 3907029168 (old parity) May 13 10:51:32 Tower emhttpd: WDC_WD30EFRX-68AX9N0_WD-WMC1T2997291 (sde) 512 5860533168 (parity2) May 13 10:51:32 Tower emhttpd: ST2000DL001-9VT156_5YD61CB9 (sdk) 512 3907029168 (disk1) May 13 10:51:32 Tower emhttpd: ST2000DL001-9VT156_6YD1825K (sdl) 512 3907029168 (disk2) May 13 10:51:32 Tower emhttpd: WDC_WD20EFRX-68AX9N0_WD-WMC300536978 (sdh) 512 3907029168 (disk3) May 13 10:51:32 Tower emhttpd: WDC_WD20EFRX-68AX9N0_WD-WMC300542396 (sdi) 512 3907029168 (disk4) May 13 10:51:32 Tower emhttpd: WDC_WD20EFRX-68AX9N0_WD-WMC300684093 (sdj) 512 3907029168 (disk5) May 13 10:51:32 Tower emhttpd: OCZ-VERTEX2_f08a40351 (sdb) 512 195369455 (cache) May 13 10:51:32 Tower emhttpd: Force_MP500_17127956000123380552 (nvme0n1) 512 234441648 (new disk, cache or UD) May 13 10:51:32 Tower emhttpd: WDC_WD30EFRX-68AX9N0_WD-WMC1T2906580 (sdd) 512 5860533168 (new disk) May 13 10:51:32 Tower emhttpd: WDC_WD30EFRX-68AX9N0_WD-WMC1T2905903 (sdf) 512 5860533168 (new disk) May 13 10:51:32 Tower emhttpd: WDC_WD30EFRX-68AX9N0_WD-WMC1T2916287 (sdc) 512 5860533168 (new disk) One of the new disks listed at the bottom must be parity, do you know which? Don't know what you intend for the old parity and the other 2 new disks, or for the new nvme.

I think that might be it. The backup plugin probably names it that way so it doesn't get used accidentally. There have been cases of people using an old backup from before they changed parity drives and reused parity as a data disk. Since super.dat said that data disk was parity it overwrote the data. I was preparing a much longer response before you posted that. It is below: I just reviewed your post history, and found this one from just after you added parity2: https://forums.unraid.net/topic/92158-docker-fatal-error/ The diagnostics in that post will make it easy to assign your disks as they were, except for any you added since that time. Here are the important lines from syslog: May 7 20:26:07 Tower kernel: md: import disk0: (sdc) WDC_WD2003FYYS-02W0B0_WD-WMAY02808875 size: 1953514552 May 7 20:26:07 Tower kernel: md: import disk1: (sdh) ST2000DL001-9VT156_5YD61CB9 size: 1953514552 May 7 20:26:07 Tower kernel: md: import disk2: (sdi) ST2000DL001-9VT156_6YD1825K size: 1953514552 May 7 20:26:07 Tower kernel: md: import disk3: (sdd) WDC_WD20EFRX-68AX9N0_WD-WMC300536978 size: 1953514552 May 7 20:26:07 Tower kernel: md: import disk4: (sde) WDC_WD20EFRX-68AX9N0_WD-WMC300542396 size: 1953514552 May 7 20:26:07 Tower kernel: md: import disk5: (sdg) WDC_WD20EFRX-68AX9N0_WD-WMC300684093 size: 1953514552 May 7 20:26:07 Tower emhttpd: import 30 cache device: (sdb) OCZ-VERTEX2_f08a40351 May 7 20:26:07 Tower kernel: md: import disk29: (sdf) WDC_WD30EFRX-68AX9N0_WD-WMC1T2997291 size: 2930266532 disk0 is parity and disk29 is parity2. Note that it is the serial numbers that are important and not the device letters (sdX). Those device letters can change but Unraid keeps track of your disk assignments by the serial numbers. After reviewing your post history, I am concerned about the problems you are having with flash. Until you get that resolved you won't make much progress on getting your system stable. You had said you started with a POS flash drive. Is that the one you are replacing now, or had you already replaced it and are still having trouble? Is the motherboard in your sig correct? The specs say it has 6xUSB2 ports on the board.

Delete the one on disk1 since it doesn't seem to be current. You can try to get the one on cache moved if you want, or you can just forget about it since docker image is easily recreated. appdata and the docker templates on flash are all that's required to get your dockers going again exactly as they were. The templates contain all the mappings, etc of your dockers, and the Previous Apps feature of the Apps page will use those to download the dockers again with all of their settings, and the appdata contains any settings or other data the applications themselves have.

And which of these docker.img files has the most recent date?

Waiting to replace disks until they die isn't the best idea. Unraid monitors drive health through the SMART attributes. You should setup Notifications to alert you immediately by email or other agent as soon as a problem is detected. Parity by itself cannot rebuild a disk. Parity is just an extra bit that allows a missing bit to be calculated from all the other bits. Parity PLUS ALL remaining disks are required to rebuild a disk. So if you have other questionable disks in the array when a disk needs replacing, the rebuild may not succeed.

And what is in the system/docker folder of disk1?

The disk assignments are in the file config/super.dat on the flash drive. If you got a good copy of that file from your backup then all your drives should already be assigned, or at least all the drives that were assigned when the backup was made. If you have to assign them yourself then Unraid doesn't remember how they were assigned because config/super.dat is missing or unusable. For example, if you click on any of those dropdowns for your disk assignments, it will probably allow you to choose any attached disk. If you are sure you know which disks are parity then make note of their serial numbers so you can assign them correctly. The main thing you want to avoid is assigning any data drive to a parity slot since the data would be overwritten with parity. Also in the config folder is your license .key file. When you boot up with the .key file for the old flash, then it is going to make you get a new .key file for the new flash on the Tools - Registration page. Also, since it seems you may still be having some issues with flash, make sure you are booting from a USB2 port. Before taking any further action though, Go to Tools - Diagnostics and attach the complete Diagnostis ZIP file to your NEXT post.

I am guessing you meant the config folder here. But the rest of your post suggest there was some problem with that, since your disk assignments should have been part of that config folder. Of course you have no shares since you have no disks for them to be on yet. Do you know how your disks were assigned?

Also, you will have to transfer your license to your new flash drive.

Clear drives must be formatted in the array before they will have a filesystem. And in general, unmountable is unlikely to be fixed by reboot. If you ever get an unmountable disk that has data on it, be sure to ask for help. If your backup didn't have those new disks assigned then you will have to add them again (and format them). Not entirely sure Unraid will still consider them clear or not but if they weren't formatted them maybe so.

All your settings are in the config folder on flash, so you can copy the backup config folder to a new install and everything should be good assuming the backup is up-to-date. Not entirely clear from your description, does your backup have the current disk assignments?

From your PC, access the Unraid webUI then go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post.

Do you actually have any VMs?

You are using the deprecated limetech Plex which is no longer supported or updated. See here:

Instead of hijacking this thread you should start your own. Even better, if it is only a problem with a specific docker you should post on the support thread for that docker. You can go directly to the correct support thread for any docker by simply clicking on its icon and selecting Support.

Are you sure the disks failed? Bad connections are much more common reasons for a disk to become disabled.

What do you get from the command line with these? ls -lah /mnt/cache/system ls -lah /mnt/disk1/system

Have you done memtest? Also see here:

Unclear what you don't understand. Unraid is a NAS (Network Attached Storage) that can host VMs. As a NAS, you can access it from other computers on your network and transfer files to it. There is a share (a folder available on the network) on Unraid named 'isos' and you copy the ISO to that folder in the way you usually copy files over the network. All I have said may seem obvious to you, it certainly seems obvious to me. If you already know all that and it doesn't help, see if you can take it from there and explain exactly what part of that you are having problems with and what exactly the problem is.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post.