trurl

Internal boot will create a small boot partition on whichever drive you put it on the rest of the drive can be used for storage.

You have a large number of .cfg files for shares that no longer exist. You can clean that up with the CLEAN UP button in User Shares.

Possibly you had Docker and/or VM Manager enabled when your pool was missing or hadn't been created yet, so they got created on the array and couldn't be moved. Your appdata and system shares still have files on the array. Nothing can move open files. Go to Settings and disable both Docker and VM Manager. Then run Mover and post new diagnostics.

What could it hurt? If the flash drive can't be reused you will have to do a license transfer. Might be some useful "flash drive" research for you to do here: https://forums.unraid.net/topic/196967-unraid-boot-device-guide-usb-and-nvme-hardware-selection/ Also, Unraid v7.3 (currently beta) allows for "internal boot", which doesn't require a flash drive: https://docs.unraid.net/unraid-os/release-notes/7.3.0/#onboarding-and-internal-boot

That is just a longer way of saying what you already said. Please explain exactly what "mistake" you did. Doesn't really matter I guess just wondering if there is something I could explain that would keep you from making that "mistake" again. yes

Did you actually click the parity swap link and read the documentation about that? It doesn't read your data disk. It is exactly for this situation. The data disk can be completely destroyed and you can still do parity swap.

How much do you think might have been written to your server, by users, dockers, mover, whatever, after disk1 became disabled?

What exactly do you mean by this? If you can reformat that same flash drive and restore your flash backup to it you won't have to do a license transfer.

If you do New Permissions on the share again, can you delete the file it won't let you delete?

How are you doing check filesystem? From the webUI or from command line? Several ways to get the command line wrong.

Since you had dual parity, emulation of disk4 should have worked assuming no other problems. But what exactly do you mean "no data". Is it mountable but empty? That wouldn't be caused by emulation or rebuild. Start in normal (not maintenance) mode.

https://forums.unraid.net/topic/195008-format-xfsv4-to-xfsv5/ also https://docs.unraid.net/unraid-os/release-notes/7.2.0/#storage

Looks like connection problems, data or power, possibly controller but that would usually affect multiple disks. Attach Diagnostics ZIP to your NEXT post in this thread.

Your diagnostics showed some of that was already on the array, so mover won't touch that. But 'arrs won't care it's all the same user share.

It is showing what you expect for free space in SAB now?

Post new diagnostics

If you have appdata backup you can probably recover your dockers. https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/

Your drives are very full. Better if you don't let them get so full, xfs_repair needs some room to work in. Emulated disk1 looks good (and full), and nothing in lost+found after the repair, so it should be OK to rebuild assuming no other problems. You do have other problems, disk5 seems to have failed. But disk5 is part of the emulation of disk1. Not clear there is really anything wrong with physical disk1, though it does have perhaps the largest UDMA_CRC_Error_Count I have ever seen. These are connection problems, not disk problems. But how did you get so many? You should probably replace cables for that disk. See if you can mount physical disk1 as an Unassigned Device. If it is OK, it might give another approach to recovering disk5.

Those errors were caused by bad RAM, and they won't go away just because RAM is good now. The bad RAM corrupted your data. Nothing likely wrong with the drive.

Odd noises can also be caused by bad power to the drive.

I haven't used that particular docker, but it probably will work. What are you using for DDNS?

You mean replace the BAD RAM with known good RAM from another server. That should be OK, but you should do another memtest with the good RAM in that motherboard just to make sure it is working OK before trying to run it again.

Do you mean put it in the server with BAD RAM? Why? You should shut down that server with the BAD RAM and not use it again until it has trustworthy RAM. It can only make things worse the way it is now.

You should quit running your server immediately until you have trustworthy RAM. What you have now is corrupting EVERYTHING!

Who set this up for you?