trurl

Do you have a current backup of the config folder from your flash drive? The config folder is all you need to get going again with your configuration on a new install.
 
Prepare a new install of whatever version on a good flash drive and see if that will boot.

Simply changing that setting just controls what it will do with new files, and mover ignores cache:only
 
You have to set it cache:prefer to get mover to move it to cache.
 
And nothing can move open files, so you have to disable Docker and VM Manager in Settings so it can be moved.
 
Also, mover won't replace files, so if anything is already on cache you will have to decide whether to keep those or the system files on disk1.
 
Install Dynamix File Manager plugin it will let you work with files directly on the server.
 
What do you get from command line with this?
ls -lah /mnt/cache/system and this?
ls -lah /mnt/disk1/system  

Recreate flash drive as a new install of whatever version. Copy config folder from your backup.
 
Not clear the guacd segfaults are related.
 
Have you done memtest lately?

This means the server is not getting DHCP from the router. Check network connections
Also, link to diagnostics instructions

setup syslog server
 
also
 

Jan 5 09:50:20 PlexNAS kernel: mdcmd (61): nocheck cancel Jan 5 09:50:20 PlexNAS kernel: md: recovery thread: exit status: -4 Jan 5 09:50:39 PlexNAS kernel: mdcmd (62): check correct Jan 5 09:50:39 PlexNAS kernel: md: recovery thread: recon P ... Jan 6 03:40:01 PlexNAS crond[1122]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Jan 6 05:09:29 PlexNAS kernel: md: sync done. time=69530sec Jan 6 05:09:29 PlexNAS kernel: md: recovery thread: exit status: 0 Looks like it was restarted and completed 

I would say you can just move the disks over, but things get more complicated if there are RAID controllers involved on either server. One of many reasons RAID controllers are not recommended. And it might also be more complicated if you have USB drives, as it sounds like you do. One of many reasons USB connections are not recommended.

How will you access the 8TB if the array is stopped?
 
With the array started, you can mount the old 4TB disk as an Unassigned Device and copy files to it.
 
Then you can New Config with the 4TB in place of the 8TB and rebuild parity.

Tools - New Permissions on only that share.

You can usually go directly to the correct support thread for your docker by clicking its icon and selecting Support.
 
 

You will have to New Config before it will let you reassign parity 2

You should go to each for your WD disks and add attributes 1, 200 for monitoring. Disk1 has a large number of attribute 1.
 
You should replace disk1 which I assume is what you intended. Do that before adding parity2. Dual parity is probably overkill since you only have 5 data disks.

Doesn't matter at all what is on the disk you are going to rebuild to. It can be a clear drive, it can be a drive formatted as XFS or as anything else. It can even be an NTFS drive from Windows full of pron. Rebuild is going to overwrite the entire disk.
 
Parity doesn't know anything about filesystems and files. It is all just bits.
https://wiki.unraid.net/Manual/Overview#Parity-Protected_Array
 
The bits on a disk represent a filesystem with its files, but parity is just going to rebuild the bits. The rebuilt bits will represent the same filesystem with its files as were on the original disk.
 
That will get the disk to the correct filesystem, but it will be an empty filesystem. So first
Then after reformat you can copy to the empty filesystem.

Doesn't really matter at this point what is assigned as disks 5, 6 since we aren't going to actually try to access those disks for a while
Go to Tools - New Config, Retain All, Apply Might as well assign the new disks as disks 5, 6. You don't really have to, but if you go ahead and assign them now you won't have to later. Don't change any other assignments. Very Important! Check BOTH Parity Valid and Maintenance Mode checkboxes, then start the array. This will accept all disks just as they are without accessing any disk and changing any contents. Then, post a screenshot of Main - Array Devices and new diagnostics.
 

Diagnostics includes the current syslog, which is in RAM like the rest of the OS. Diagnostics can tell us how things are now, but can't tell us anything about what happened before boot.
 
Disk3 has
199 UDMA_CRC_Error_Count -O-R-- 200 200 000 - 1347 These are recorded by the drive when it receives inconsistent data as determined by checksum. These are almost always connection problems. Often these won't cause a problem because the data is resent. And connection problems often don't result in CRC errors since the drive never receives any data to checksum. You should be getting a SMART warning ( 👎) for this disk on the Dashboard page. You can click on it to acknowledge and it will warn again if it increases.
 
Other than that, SMART for disk3 looks OK, and SMART for parity looks OK.
According to SMART reports, parity has had no self-test run. Disk3 did pass some short tests, but that was a couple of years ago. Neither have had extended tests.
 
Unraid disables a disk when a write to it fails for any reason. But the failed write updates parity so it can be recovered by rebuilding. And even though one of the disabled disks is parity, parity2 was updated. So the disks are now out-of-sync with the array and have been "kicked out".
 
After a disk is disabled, it isn't used again until rebuilt. It is instead emulated by parity. Reads from the disk are emulated from the parity calculation by reading all other disks, and writes to the disk are emulated by updating parity so the emulated write can be read. The initial failed write is emulated, and any subsequent writes are emulated, and these can all be recovered by rebuilding. (In your case, the only parity still being read or updated is parity2 since parity is disabled).
 
Bad connections are much more common than bad disks, and that is probably what happened here, but unless you have syslog from before reboot, can't say for sure. No obvious problems currently.
 
Emulated disk3 is mounted and has plenty of data, so that's all good. The emulated contents is what you will get when you rebuild.
 
Your configuration looks good. Most people would consider dual parity overkill since you only have 3 data disks in the array.
 
It's usually safer to rebuild to spares and keep the originals in case of problems, but it should be OK to rebuild onto the same disks after checking all connections.
 

I'm not sure that name is allowed

yes

Not ADD, REPLACE.
 
Preclear if you want to test the new disk. A clear disk is only required for ADD, not for REPLACE. Rebuild will be a test of sorts anyway.
 
Since the new disk is already installed, all you need is...
 
Stop array, assign new disk as disk1, start array to begin rebuild.

There is no complete list of corrupted files.
 
Recreate flash drive as a new install of whatever version, copy the config folder from your backup.

setup syslog server

https://en.wikipedia.org/wiki/Standard_RAID_levels#General_parity_system

Rename or delete config/smb-extra.conf on the flash drive and reboot.