trurl

Did you let Unraid format your disks yet? Doesn't look like you have any filesystems for docker to live on.

You can always replace parity with a larger disk when needed and reuse old parity for Data.
 
Have you tested your old drives? Each disk in the array must be reliably read to reliably rebuild a disk. Parity by itself can recover nothing. 

Does your server have more than one ethernet port? I'm thinking you are seeing the IPMI port instead of the port Unraid would be on.

There must not be any RAID controllers involved in either system.
 
Assuming you only use the diskUnraid disks for array drives in dockerUnraid, and don't keep any existing dockerUnraid array drives, then New Config as linked above should work and your parity will still be valid if all array drives are assigned exactly as they were in diskUnraid. So you can check the parity valid box before starting the array and it won't rebuild parity. A parity check after would be a good idea just to confirm.

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.