trurl

https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself
 
Not exactly. There is no Minimum Free setting for array disks.
 
Each of your user shares has a Minimum Free Setting. When writing to a user share, if an array disk has less than Minimum, Unraid will choose another if allowed by other settings. Note that it does this choosing before knowing how large the file you are writing is, and in general, it can't know how large a file will become.
 
For example, a disk has 15G free, Minimum is 10G, you write a 10G file. Unraid can choose the disk since it has more than Minimum. After writing that 10G, disk will have 5G free and won't be chosen again.
 
Another example, a disk has 15G free, Minimum is 10G, you write a 20G file. Unraid can choose the disk since it has more than Minimum, and the write will fail when it runs out of space.
 
There is also Minimum Free setting for each of your pools (cache) that works in a similar manner. If a pool has less than Minimum, Unraid will choose an array disk instead (overflow), but only for cache:yes and cache:prefer shares.
 
 

Use the SSD as cache and the 2xM.2 as a btrfs raid1 pool for Docker/VM related shares appdata, domains, system.

Ideally, you need to transfer your whole config (config folder from flash), which is all settings from the webUI including disk assignments.
 
Do you have a current backup of flash?

appdata, domains, system shares should ideally be all on fast pool and set to stay there so Docker/VM performance isn't impacted by slower array, and so array disks can spin down since these files are always open. Leave these cache:prefer.
 
Nothing can move open files. You have to disable Docker and VM Manager in Settings then run mover to get these moved. Also, mover won't replace files so there may be some manual cleanup to get these all off the array.
 
No need to backup docker.img since it is easily recreated. You can backup appdata and libvirt.img using that same plugin. You will also need a way to backup VM vdisks. There is a plugin for that too.

See if mover tuning plugin will work for you

No, the part I requested is below those parts you posted.
 
 
 
Are you sure you did New Config?

I never suggested that specific file. That file is not plain text. But that is the file Unraid will read to get your disk assignments. Edit config/disk.cfg to disable autostart, then
 
 
and check your disk assignments before starting the array.
 
Also, this post from a few months ago has your diagnostics, and plenty of ways to see disk assignments in those. Of course you may have changed them since then.
 
 

Since you have already formatted the new disks as XFS, just copy from the Unassigned Device originals to the new disks. Changing filesystems is going to require copying data so you can reformat anyway.
 
Some additional details I hope will help you avoid future mistakes that might be more costly.
 
When rebuilding a disk to a new disk, the result will be the same filesystem as the original. Rebuild is just a bunch of bits, parity knows nothing at all about files and filesystems. Those bits represent the files and filesystems, so the original filesystem is what will result.
 
Format is NEVER part of rebuild. Format is a write operation.
 
Format means "write an empty filesystem (of some specific type such as XFS) to this disk". That is what format has always meant in every OS you have ever used.
 
Unraid treats that write operation just as it does any other, by updating parity. So when you format a disk in the parity array, the only thing that can be rebuilt is an empty filesystem.

Check connections, SATA and power, both ends, including splitters. Don't put more than 4 disks on a single power cable. Don't bundle data cables. Make sure all cables have enough slack so they can sit squarely on the connection without any tension. Try a different cable if the same one keeps causing problems.

https://wiki.unraid.net/Manual/Changing_The_Flash_Device#What_to_do_if_you_have_no_backup_and_do_not_know_your_disk_assignments:

You can only replace one disk at a time. No data disk can be larger than parity, so you have to replace parity and let it rebuild before you can use the other 8TB
 
Attach diagnostics to your NEXT post in this thread.

Don't think of array and cache separately. Cache and array are both included in user shares. Just work with user shares and everything will look the same whether files are on cache or array. 
 

I would put those 2x1TB in a new pool for Docker/VMs to use and keep the original SSD cache for caching user share writes.

Might as well disable Docker and VM Manager in Settings until your array is stable again. Maybe even use SAFE mode when you reboot.

It's not about "where the old one was connected". It is only about where the disk is assigned. Assign the disk to the same slot as the missing disk (disk1).

Try Tools - New Permissions on only the user share(s) in question (not appdata) and see if that makes any difference.

https://www.linuxatemyram.com/

You need to get zero errors from memtest. Whether new RAM or something else.
 
You shouldn't even attempt to run any computer unless memory is working perfectly. Everything goes through RAM, the OS and other executable code, your data, everything. The CPU can't do anything with anything until it is loaded into RAM.

/user and /volume are not persistent paths in Unraid, and /volume is not a path to any disk or user share.
 
Perhaps you mean a user share path such as /mnt/user/system vs. a disk path such as /mnt/disk1/system. Either should work.
 
Do you have a link for that? Even if true, the rest of your explanation doesn't make any sense since parity doesn't contain any data.
 
Any huge dataset should be mapped to host storage and not created inside docker.img . Lots of people get by with 20G docker.img whatever they are doing.
 
That was the reason for my question
since those templates are where previous apps gets the information for the create/edit container page to recreate your dockers.

Jan 9 04:40:59 Tower root: Fix Common Problems: Warning: NerdPack.plg Not Compatible with Unraid version 6.11.1 Jan 9 04:41:05 Tower root: Fix Common Problems: Warning: Legacy certificate detected Jan 9 04:41:05 Tower root: Fix Common Problems: Warning: Share appdata set to use pool dualssd, but files / folders exist on the cache pool Jan 9 04:41:05 Tower root: Fix Common Problems: Warning: Share appdata set to use pool dualssd, but files / folders exist on the ssd pool Jan 9 04:41:05 Tower root: Fix Common Problems: Warning: Share system set to use pool dualssd, but files / folders exist on the cache pool Jan 9 04:42:53 Tower shfs: share cache full Filling cache could be part of the problem. And you should take care of those other FCP warnings. Such as
NerdPack.plg - 2021.08.11 (Up to date) (Incompatible) Remove and install NerdTools instead, if you really need it.
 
Mover only moves cache:yes shares from the designated pool to the array, and moves cache:prefer shares from the array to the designated pool. Mover ignores cache:no and cache:only shares, and won't move files between pools.
 
Also, be sure to check your dockers and make sure they aren't specifying the wrong pool for appdata. /mnt/user/appdata is OK and should be what you specify at least until you get all of appdata on the pool you intend.
 
Why are you still on 6.11.1?

Just rebuild the disk to a new disk, preclear optional.

That is the usual method
 
mount -o remount,size=384M /var/log  

Looks good. Nothing even got lost+found. This was an easy one

from syslog
Dec 28 10:55:30 Tower emhttpd: unclean shutdown detected exactly zero is the only acceptable number of sync errors. The few you have is typical of unclean shutdown. You must run a correcting parity check.