trurl

That doesn't show your cache anywhere near full. And appdata and system shares are on cache where they belong, and no other shares are currently using any of cache. So there is nothing for mover to do.
 
What are you looking at the makes you think your cache is filling up?

None of your shares are set to be moved. And your cache is probably too small for anything except appdata, domains, system, (and isos if you want those on cache)
 
First thing is to move the other share b----w off cache. Mover won't move any share without a setting for Secondary storage. Set that share to Primary: cache, Secondary: array, Mover action: cache->array.
 
Run mover, wait for it to complete, post new diagnostics then we can try to see if your "default" shares will fit on cache.

For now there must be an array drive. The reason is because it worked that way before ZFS was part of Unraid. There are plans to change that in future versions. 
 
You can just assign a flash drive and not use it for anything if you want 

If you upgraded your basic key to pro then that original basic key can't be used. That's the reason the upgrade is cheaper than buying another key. After you upgrade a key, you still only have that one key. Upgrading didn't get you a free key.

USB not recommended for array or pools

Lots of entries in syslog
 
 
SMART looks OK for those. I think the usual advice for btrfs is to backup and reformat the pool.

Seems like a pretty serious thing to ignore.
 
Check filesystem on disk1
 

Someone or something must be moving or deleting files. 'arr dockers, for example, are often configured so downloaded files will get moved to other shares

Don't know why you couldn't boot memtest86 but you really need to try again and see if you can figure that out.

Primary storage:cache
Secondary storage:none
 
Is cache-only

Shrinking is for when you want to end up with fewer disks, usually with the data from the removed disk already copied to other disks in the array. It definitely is not faster.
 
And there is no way to replace your drives all at once unless you want to start again with empty drives.
 
Your first sentence says you want to replace, so upgrade is what you want to do. You could do 2 at once with dual parity, but simpler and safer to do one at a time as needed for capacity.
 
I always upsize my disks since I have no room for more disks, and I have done it many times. Replacing disks is the whole reason you have parity. Not risky at all if your array is working well. Just keep the original disk intact until you are happy with the rebuild.
 
In any case, you must always have another copy of anything important and irreplaceable. Parity is not a substitute for backups.
 
 

https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/#what-to-do-if-you-have-no-backup-and-do-not-know-your-disk-assignments

Also, USB not recommended for array or pools for many reasons

Not if you don't have it attached when you start the array.
 
Yes

The UD isn't really the problem. It is your mapping /mnt to /mnt. If you map /mnt/user on the host to some path in the container (could even be /mnt/user) then emby will have access to all your user shares.

Pinned to the top of this same subforum:
 

It recognizes it, it just considers it disabled.
 
I guess we could New Config it back into the array. New Config will accept all disks assignments so none are disabled.  Then we can re-disable disk4 so it can be rebuilt (after making sure emulated disk4 is mountable).
 
Before following these instructions, wait a few hours to see if @JorgeB has any other ideas.
 
This process isn't documented, but we have used it many times. It is very important to follow the instructions precisely.
Go to Tools - New Config, Retain All, Apply. Not entirely sure it will keep the disk4 assignment since it thinks it is wrong. If it doesn't, assign disk4 before continuing, leave all other assignments as they are. In Main - Array Operation, check BOTH Maintenance mode and Parity valid checkboxes, then start the array. Stop the array, unassign disk4, then start the array. This will disable and emulate disk4. Then post new diagnostics so we can see if emulated disk4 is mountable.
 
 

yes

If it said the disk was emulated then it must have been disabled and showing a red X. But you don't mention that.
 
There are only 2 ways to get a disabled disk enabled again and no longer emulated. You have to rebuild the disk, or you have to New Config to reset the disk assignments and rebuild parity (by default).
 
But you don't mention that either. Instead you say you did a parity check. Something missing in your explanation.
 
# 1 Extended offline Completed: read failure 10% 25703 96224840 Disk 5 has failed. You should replace it.

No reason to expect xfs_repair to help with windows filesystem. 
 
You can go directly to the correct support thread for Unassigned Devices by clicking its Support link on your Plugins page 

Can't imagine why you think preclear is needed.
 
If you New Config/Trust Parity, you will still need a parity check, so might as well rebuild the disk or rebuild parity. As you say, rebuilding the smaller disk will be faster.

User Scripts plugin