trurl

Which explains why Mover can't work. It can't make any changes to cache, which is required when you move files off cache.
 
btrfs seems a little fragile when you fill it up.

Looks like this controller
01:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3224 PCI-Express Fusion-MPT SAS-3 [1000:00c4] (rev 01) Subsystem: Broadcom / LSI SAS9305-24i [1000:31a0] Kernel driver in use: mpt3sas Kernel modules: mpt3sas Maybe try reseating it.
 
Is it overheating?

Reformat your flash drive then recreate it from your backup. If you have changed any disk assignments since the backup was taken, edit config/disk.cfg to disable autostart so you can check your assignments before starting the array.

All attached storage devices when the array is started except the boot flash drive are counted. You can attach additional unassigned Devices after starting the array.

Currently, you only have DNS1 set, and it is set to your Gateway.
 
Google DNS is easy to remember so I will give those.
 
Go to Network Settings and set these
 
DNS1 8.8.8.8
DNS2 8.8.4.4
DNS3 192.168.20.1
 

You can delete empty folders on cache. What you don't want to do is delete any files on cache that is not duplicated on the array.
 
User shares are pretty simple. Here is how they work.
 
User shares are just the combined top level folders on array and pools.
 
If you create a user share, Unraid creates a top level folder, named for the share, on array or pools, as needed, in accordance with settings you make for that user share.
 
Conversely, any top level folder on array or pools is part of a user share named for that folder. Other top level folders with that same name on other disks or pools are part of that same user share.
 
So, it is possible to create a user share just by creating a top level folder. Any user share you haven't made settings for has default settings.

Since something seems to have gotten broken, might be better to format that same flash drive and do a new install. Then copy the config folder from your backup, that will have your disk assignments and everything else about your configuration.

My bad, haven't gotten used to looking at df results for ZFS.
 
Should be OK to rebuild on top of the same disk.

No good reason to use UD for this, just create another pool

no

You can probably reinstall your containers from Previous Apps.
https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications

ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 001 001 010 NOW 0 (0 6) SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: unknown failure 10% 18606 0 Both of these are a little unusual. The RAW_VALUE on reallocated isn't a simple count like we usually see, but the FAIL column says NOW, so I would say it has failed.
Extended self-test also says failed, but it doesn't know why. Usually we get something like read failure.
 
In any case, yes, it should be replaced.
 
You are also having problems with disk4, and it has a rather high Reallocated count. In fact, I would say that one needs replacing as well.
 
Do any of your other disks show SMART ( 👎 ) warnings on the Dashboard page?
 
What do you check on the Dashboard on those rare occasions?
 
Unrelated, your system share has files on the array. And you should update your plugins.
 
 
 
 

https://docs.unraid.net/unraid-os/getting-started/manual-install-method/

Not a good assumption. Glad you posted in General Support.
 
Unraid disables a disk when a write to it fails for any reason.
 
 
All that seems like it might be related. Did you notice if the disk got disabled soon after reboot? Have you resolved all these issues?
 
And glad you posted before doing anything since it seems you are unclear how to proceed.
New Config can only rebuild parity and is definitely not the way to proceed if you want to rebuild a data disk. And rebuilding the data disk is what you want to do since it is the one out-of-sync. Parity emulation has the missing write that disabled the disk, and any subsequent writes that might have gone to the emulated disk.
 
SMART for disk4 looks fine. Probably a connection problem but we can't see when the disk got disabled since you rebooted.
 
Emulated disk4 is mounted and has plenty of data. Should be OK to rebuild on top.
 
https://docs.unraid.net/unraid-os/manual/storage-management/#rebuilding-a-drive-onto-itself

Looks like a connection problem

contact support

Check in config/plugins/dynamix on the flash drive for those cron entries. I don't use zfs but I know others are there.

If you include old parity as a data disk when you New Config, then it will already be part of the array that new parity is synced with. Then you can format old parity and it will be ready for access. No need to preclear it or to wait for Unraid to clear it after adding it

Are you sure you don't have a cooling problem?

I didn't think you were going to do a lot of stuff without waiting for advice.

Preclear the disk again to see if you can get rid of that pending sector.

Complete a correcting parity check, then immediately after run a non-correcting check. Don't reboot during any of this so all of it is recorded in the same syslog and you can post the diagnostics after.
 
If the non-correcting check still has sync errors, further investigation is needed.

Your downloads share has Minimum Free set to 390500000 KB, which is 390.5 GB. This is more than the free space on any of the included disks.
 
 

This is a connection problem sometime in the past. You can acknowledge by clicking on the SMART warning for that disk on the Dashboard page, and it will warn again if it increases.
 
I usually just acknowledge the occasional CRC, maybe reseat the connector next time I'm in the case if I remember to. If it increases quickly you need to investigate.
 
The drive firmware validates incoming data by doing a checksum. If the checksum doesn't match, CRC is counted.
 
When this happens, data is resent, so usually there is no other problem. CRC might not even be logged as an I/O error.
 
And some connection problems won't cause CRC because no data was received to checksum.