trurl

Assuming no RAID controllers involved in old or new system (and no assigned disks using USB connection), Unraid should be able to identify the drives. Unraid keeps track of disk assignments by disk serial number.
 
If you had any hardware passthru to VM, you might have to reconfigure that.

system and domains shares still have files on the array.
 
Mover won't replace files, so if there are duplicates you will have to clean those up yourself.
 
You will need to recreate docker.img and reinstall from Previous Apps.
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications
 
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks
 
 

The relevant shares
appdata # Share exists on cachefast, cache domains # Share exists on cache isos # Share exists on disk1, disk6, disk7, cachefast system # Share exists on cachefast, cache Set appdata, domains, system to
Primary:cachefast; Secondary:cache; Mover action:cache->cachefast
 
Doesn't really matter where you put isos, but for consistency, you could do
Primary:cachefast; Secondary:array; Mover action:array->cachefast
 
Nothing can move open files. Disable Docker and VM Manager in Settings
 
Then run mover, wait for it to complete, post new diagnostics.
 
 

That screenshot doesn't serve to illustrate there are no files since you haven't drilled down into any disk.
E---e shareUseCache="no" # Share exists on disk1, disk2 M--e shareUseCache="no" # Share exists on disk1, disk2 a-----a shareUseCache="no" # Share exists on disk1, disk2 d--a shareUseCache="no" # Share exists on disk1, disk2 s----m shareUseCache="no" # Share exists on disk1, disk2  
These latest diagnostics show you have several user shares
 
You can see how much of each disk is used by each user share by clicking Compute... for the share on the User Shares page.
 
Since both disks are identical as mentioned, they are expected to have the same files.
 
You would have to New Config to get one of them reassigned as parity. Parity might even be valid without rebuilding it, but I would do a parity check anyway, it would be a good test of how well things are working.
 

Your log is filling up with these many times per second.
Feb 12 05:26:09 Tower sshd-session[11597]: Starting session: command for root from 192.168.100.143 port 55868 id 1 Feb 12 05:26:09 Tower sshd-session[11597]: Close session: user root from 192.168.100.143 port 55868 id 0 See if you can figure out how to stop that.

You don't have it set to autostart. Settings - Disk Settings
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications
 
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

The default shares get created when you enable Docker and/or VM Manager. 

which is just like it says in the docs
 
https://docs.unraid.net/unraid-os/manual/storage-management/#rebuilding-a-drive-onto-itself
 
I don't see any point in the 7. (optional) start in Maintenance mode. It just means the server can't be used for anything until rebuild completes.

Did you try clicking the Apply button on that Docker page?

Minimum Free settings for cache and for each user share. And probably mover schedule.
 
Unraid decides where to put a file before it begins writing it.
 
For pools, if Primary pool (cache in your case) has less than Minimum Free for the pool, it will go to Secondary instead. This is known as overflow.
 
For user shares, if a disk has less than Minimum Free for the share, another disk will be chosen.
 
For example, Minimum is set to 20G, pool has 25G free. Since this is more than Minimum, the pool can be chosen. If you write a 15G file, after writing the pool will have 10G free, which is less than Minimum, so further writes will overflow.
 
Another example, Minimum is 20G, pool has 25G free. Since this is more than Minimum, the pool can be chosen. If you write a 30G file, it will fail when it runs out-of-space.
 
Default mover schedule is once-per-day in the middle of the night.
 
If you need to write more at one time than cache can hold, don't cache.
 
For initial data load, unassign parity, set shares to Primary:array, then build parity after initial load is complete.

Preserve all, then you have to check the Yes, I want to do this box, then it will enable the Apply button which you have to push.
 
That will get you to the disk assignment page with the array stopped. You can make any changes needed, such as reassigning disk3. Main thing is to not assign a data disk to any parity slot or it will be overwritten by parity.
 
Then start the array to begin parity rebuild (don't check the Parity Valid box).

Looks like all files for the ssd share is on cache.

Did you mount it using Unassigned Devices?
 
Parity is maintained when writing any disk in the array, doesn't matter if writing directly to disk or to user share.
 
How fast?
 
Attach Diagnostics to your NEXT post in this thread. Might save some questions back and forth.

1 parity drive would be enough to recover 1 disk failure. But, there are plenty of much more common ways to lose data than a disk failure.
 
Parity is not a substitute for backups. You must always have another copy of anything important and irreplaceable.

https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications
 
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

SSDs in the parity array cannot be trimmed, and can only be written at parity speed. Usually you would put SSDs in a pool (such as cache) separate from the parity array.
 
Attach Diagnostics to your NEXT post in this thread.

# 2 Extended offline Completed: read failure 90% 35024 64312740 That disk should be replaced

before you transfer the data.
 
I think Unbalanced only works with array drives.

You could do that with New Config

User Shares are the combined top level folders on array and pools. If you have no data, you have no shares by definition.
 
The default shares
https://docs.unraid.net/unraid-os/manual/shares/user-shares/#default-shares
will be created when you enable Docker and/or VM Manager.
 

See if you can recreate it on the same flash drive. If you have to use a new one you would have to transfer the license.

https://docs.unraid.net/unraid-os/manual/tools/#new-config

That's not correct for cache. Looks like cache was unmountable when you booted (and still is).
 
Since Docker and VM Manager were enabled, their related shares (appdata, domains, system) got created on the array. Then probably some container or something specified a host path of /mnt/cache when it didn't actually exist, so it got created in rootfs.
 
Disable Docker and VM Manager in Settings, and leave them disabled until you get cache fixed.
 
 

You would need to New Config without the disk and rebuild parity. That is what I recommend.

The OS is contained in archives on the flash drive. Those archives are unpacked fresh into RAM at each boot, and the OS runs completely in RAM. Think of it as firmware.
 
Unraid is not intended to be a general purpose Linux. It is a NAS OS that can host docker containers and VMs. Probably better if you don't try to do anything complicated at the command line until you are more familiar with Unraid and how it works and how it is different from a general purpose linux.
 
If you need a general purpose Linux, install a VM.