trurl

Do you have any record of your disk assignments? A recent screenshot, diagnostic, or syslog is all it would take. And even if you don't have any record of your disk assignments, as long as you don't accidentally assign a data disk to a parity slot then you should be able to boot up in Unraid without affecting your data. Just don't assign parity if you don't know which disk is parity, simple as that.

I have split your post into its own thread. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

I have split your post into its own thread. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

yes

/sbin is in RAM like the rest of the OS, so any changes you make there will not survive reboot. The flash drive contains the archives of the OS, and those are unpacked fresh at each boot into RAM. The OS runs completely in RAM and all the usual linux folders are in RAM. With your ls command I get this: root@unSERVER:~# ls -larth /sbin/init -rwxr-xr-x 1 root root 48K Sep 12 2019 /sbin/init*

Do you have a good backup plan? You absolutely must have another copy of anything important and irreplaceable. Parity is not a substitute for backups. Maybe those other disks could be part of your backup plan. I have smaller disks I no longer use in the array and use them to make offsite backups.

Use them for other things. I don't recommend using "random disks" in the array just because you have them. Especially smaller ones that don't give much capacity. Each additional disk is an additional point of failure. Smaller disks don't perform as well as larger disks due to density. And just any old disk shouldn't be used anyway. Every bit of every disk must be reliably read in order to reliably rebuild every bit of a missing or failed disk. So if you have some "random disk" that may not be trustworthy, it could compromise your array.

If you plan to end up with 4x8 plus 2x4, then the way to do that is to keep those 2x4 good disks (disk1,3) as they are. After rebuilding parity1 onto 8TB, remove parity2 and use that disk to rebuild disk2. Then you can add other 8TB to new slots. Regardless, there isn't any need to transfer files from one disk to another. The whole point of parity is to allow you to rebuild the contents of a disk to a new disk. No need to move files around or empty drives so you can replace them, etc. Let me know if you need more on how to get to your desired result. Moving files around should not be necessary.

Nothing obvious, except you are using 16G of 50G docker.img. 20G should be more than enough and the fact that you are already using 16 makes me wonder if you don't have some application writing to unmapped storage. I have 17 docker containers, and I am using less than half of 20G. Also, there is a new alignment available on the latest beta that might give better SSD performance.

Yes, that disk2 definitely needs replacing: Serial Number: Z304EEQX ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 096 096 010 - 4680 187 Reported_Uncorrect -O--CK 001 001 000 - 109 197 Current_Pending_Sector -O--C- 092 092 000 - 1408 198 Offline_Uncorrectable ----C- 092 092 000 - 1408 You should have been seeing warnings for that disk on the Dashboard, and also getting Notifications for it. You should set up Notifications to alert you by email or other agent as soon as a problem is detected. And you should deal with problems as soon as they arise and not let them turn in to multiple problems and data loss. Do any of your other disks display SMART warnings on the Dashboard page? I did notice a few CRC (connection) errors on disk3. You can acknowledge those by clicking on the warning and it will warn again if they increase. Parity also has a few Uncorrected but you are replacing that next anyway. Since you have dual parity, it is OK to run with that disabled disk2 while you upgrade parity1. Assign a new 8TB disk to parity1 slot (the disk already installed or another if you prefer) and let it rebuild. Be very careful when mucking about in the case. Disturbing connections is by far the most frequent cause of problems with rebuilds/replacements.

Virtualizing Unraid is officially unsupported, but we do have a subforum for other users to support each other. I will move this to Virtualizing Unraid, which is the appropriate subforum for your questions. Maybe someone there will help Looks like someone else beat me to it.

There is Help in the webUI. You can toggle Help for the entire webUI using the Help (?) button, or toggle help for a specific setting by clicking on its label. Each user share has settings which control how it uses the disks. These are Allocation Method, Split Level, and Minimum Free. You can also Include or Exclude certain disks for each user share. The default Allocation Method of High-Water is a good compromise between using other disks (eventually) without constantly switching disks just because one might temporarily have more free space as you might get with Most Free allocation.

The 8TB parity2 is OK. Just unassign the 8TB data drive since you can't have any data disk larger than any parity disk.

no the 2nd is a mirror of the first and the first can be replaced without losing data. Sounds like you may not have your dockers using cache correctly. Post your diagnostics.

After looking at those diagnostics I realized I didn't look closely enough at your screenshot. You can't add a disk larger than parity, and you shouldn't attempt to add a disk when you have a disabled disk anyway. Unassign that new disk and see if you can start the array. Then post a new screenshot and new diagnostics.

Move all data from disk to be removed to other disks using unBALANCE or otherwise. Some haven't had success with the clear and remove method mentioned in that link and it doesn't save any time, but if it works for you it does maintain parity. And no harm to try it. If it doesn't work you can just New Config without the disk and rebuild parity instead. Either way a good idea to check parity after.

this

You can have multiple disks in the cache pool. Not really "parity" though. The default is for btrfs raid1 mirror. Be sure to use SSDs of the same size in this case. I am doing this also. I have a single NVMe as my "fast" pool with appdata, domains, system on it, no redundancy since CA Backup takes care of the important things from those. And another "cache" pool with 2x500G SSDs for normal caching.

Also, go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Read this and come back with any questions: https://wiki.unraid.net/The_parity_swap_procedure

We already had that one. The point was to get a new one that showed the new parity check, since it already has some sync errors that we might compare to the earlier parity check.

And of course your logs are not full in those since syslog starts over when you reboot.

This is the most important advice. You must always have another copy of anything important and irreplaceable.

Also see this wiki: https://wiki.unraid.net/UnRAID_6/Docker_Management

Understanding volume and port mapping is 99% of knowing how to set up any docker. Take a look at the Getting Started section of the Docker FAQ: https://forums.unraid.net/topic/57181-docker-faq/