trurl

Those errors are from your boot flash drive.
You must always have a current backup of the boot flash drive. It contains ALL of your configuration (ALL settings from webUI including disk assignments, docker templates, share settings, your license. ALL)
 
Unraid Connect plugin will keep a current backup of flash on Unraid Cloud. You can always manually download a zipped backup of flash from MAIN - Boot Device - flash - FLASH BACKUP. Any time any significant change is made in the webUI (your configuration) it needs to be backed up.
 
So now what to do...
 
The config folder from flash (if good enough) or flash backup are all you need to get going again with all of your configuration on a new install.
 
You should backup (in other words, copy) config folder from your boot flash to somewhere on your PC or wherever, format flash, and try to create a new install on that same flash drive. If that boots OK you can copy your config folder backup onto it.
 
If the new install doesn't boot, you might have to replace flash, but that also require transferring your license.
 
 
 
 

Most use parity array for large storage and pools for fast storage. 
 
You can have many array disks protected by one or two parity. 
 
Data loss is not inevitable at all. Actual disk failures are more rare than other causes of data loss, including user error. 
 
Parity and even mirrors are not a substitute for backups. You must always have another copy of anything important and irreplaceable. 

Parity is basically the same concept wherever it is used in computers and communications. Parity is just an extra bit that allows a missing bit to be calculated from all the other bits. The parity disk provides the extra bits that allows the missing disk to be calculated from all the other disks.
Parity contains none of your data. It doesn't even know anything about files. It is all just parity bits.
 
Parity is not a substitute for backups, whether Unraid or some other parity implementation.

maybe not relevant to your particular container, but in general (from that earlier link)
many applications won't use a different port internally. That is why we have port mapping.
 
edit container in advanced mode

OK, let's see if parity can emulate disk2 without that other disk you "didn't" add.
 
You must follow these instructions very carefully.
Go to Tools - New Config, Retain All, Apply. Check that all disks are assigned correctly. Assign new disk2. Check BOTH Parity valid checkbox and Maintenance mode checkbox, and start the array. This will accept all assignments, but won't change any disk. Stop the array, unassign new disk2, start the array in normal mode. This will disable disk2 so we can decide if it can be rebuilt. Then post diagnostics.
 

How are you backing up your data?

Your system share has all of its files on disk1. This share is the most important for allowing your disks to spindown.
 
appdata would have open files for specific running containers, domains would have open files for specific running VMs.
 
system share has open files when Docker or VM Manager is enabled in Settings. It is configured to be moved to cache_nvme, but nothing can move open files.

If you want the "standard" mover to skip some shares while you use it to move appdata from disk1, you can just set those other shares to Secondary:none.
 
Or you can move appdata from disk1 to vms_dockers yourself using Dynamix File Manager. Might even better to try that since mover won't overwrite files. That way you can clean up any duplicates there might be between appdata folders on disk1 and vms_dockers.

You have appdata and system all on cache. I usually recommend to also have domains all on cache.
 
appdata, domains, system are the default shares used by Dockers/VMs. If these are on the array, Docker/VM performance will be impacted by slower array writes and reads, and array disks won't be able to spin down since these files are always open.
 
If you do want to move domains to cache, VM Manager in Settings has to be disabled (already is) since nothing can move open files. Set domains share the same way you have appdata and system shares for Primary, Secondary, Mover action.
 
Mar 15 20:51:08 Slash root: Fix Common Problems: Other Warning: Mover logging is enabled I'm sure you are aware of this since you were trying to figure out mover. All the files mover logs are in your syslog, and so in the Diagnostics you posted, so you don't want to leave it on all the time.
 
Diagnostics says all of your plugins are unknown. Must be something with Community Applications not working with your server when the diagnostics were taken. Have you had problems with CA?
 
d-------s shareUseCache="no" # Share exists on cache, disk1, disk2, disk3 This share has files on cache, but mover ignores shares without any Mover action specified. Should probably be Primary:cache; Secondary:array; Mover action:cache->array
 
I see you already fixed your docker.img size.
 
You should set Minimum Free for cache
https://docs.unraid.net/unraid-os/manual/storage-management/#minimum-free-space-for-a-pool
 
And Minimum Free for each of your User Shares
https://docs.unraid.net/unraid-os/manual/shares/user-shares/#minimum-free-space

All you need from your backup is the config folder. If you copy the config folder to a bootable OS you will have all of your configuration.

Typically those will require a SATA port for one of the drives. There are some that don't, but will only work if your motherboard can split the slot (bifurcation).

Connection problems with disk2.
 
That seems like particularly bad advice, or maybe a very bad paraphrase of whatever that advice was.
 
If you truly have RAM errors, you shouldn't even be attempting to run your server. 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.
 
memtest is on the boot menu.

Disabled and Unmountable are different, and often independent conditions. And require different solutions.
 
Unraid disables a disk when a write to it fails for any reason. After a disk is disabled, the disk is no longer used by Unraid because it is out-of-sync. Instead, it is emulated by parity by reading all other disks. Reads from the emulated disk read all other disks and get the data from the parity calculation. The initial failed write, and any subsequent writes to the emulated disk, are emulated by updating parity so those writes can be recovered.
https://docs.unraid.net/unraid-os/overview/nas/#parity-protected-array
A disabled disk is enabled by rebuilding.
 
A disk is unmountable when its filesystem is corrupt, and so the OS can't load it for access. The filesystem needs to be repaired
 
A disk can be disabled, but the emulated disk is mountable. OK to rebuild assuming everything is working well (why did it get disabled? Bad connections are often the cause)
A disk can be enabled, but the disk is unmountable. No rebuild required, repair needed.
A disk can be disabled, and the emulated disk is unmountable. This is what you have. Repair and rebuild needed.
 
The parity calculation is supplying the data for the emulated disk, but that emulated disk is unmountable.
If rebuilding to a new disk, the original disk can still be used to recover data if repair results of the emulated disk aren't good enough.
If rebuilding to the same disk, it is better to repair the emulated disk before rebuild so we have more options.
 
You are currently rebuilding an unmountable filesystem. Too late now, we will have to let it finish and deal with the consequences.

Looks like you were having connection problems.
 
Probably best to stop and check connections.
 
Do you know what was wrong with original disk1? Is original disk1 still attached?

Does this only happen soon after booting and not again until next boot?
 
 

Unbalanced plugin

How were these directories created?
 
Try running New Permissions on just the M--------a share

Go to MAIN - Boot Device - flash - Syslinux Configuration and edit the append line for the selected boot option
 

Since the array was not started in normal mode when the diagnostics were taken, no way to know anything about the filesystems on any disks.
 
Leave the array as it currently is. If you have a spare port plug the original disk in and see if it will mount as an Unassigned Device.
 
Either way post new diagnostics.

Disable Docker in Settings, then use Dynamix File Manager to see if docker.img is in cache/system/docker and also in disk1/system/docker.
 
If it is in cache/system/docker, that is the one that would be in use since cache has precedence.
 
If it isn't in cache/system/docker, move it there from disk1/system/docker.
 
Then delete system folder from disk1.
 

That doesn't look too bad. Go ahead with Fix button.

Your appdata, domains, and system shares still have files on the array.
 
Nothing can move open files, so you have to disable Docker and VM Manager in Settings before you can work with those.
 
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

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.