trurl

Sorry, my bad. It is disk3 that has no shares. So take everything I said before but apply it to disk3. You can see for yourself that disk3 has no shares by clicking on the File Explorer shortcut to disk3 in Main - Array Devices

Looks like disk2 has been formatted and doesn't contain any shares. Your Mediathek share has files on all other disks and isn't configured to exclude any disks, so I suspect the files that are missing were on disk2. Don't see anything in syslog or previous about formatting so must have happened before that. Was disk2 unmountable at some point so you allowed Unraid to format it so it would mount?

Contents of disabled disk is already emulated whether or not it is assigned and contents of physical disk aren't used for reading or writing until rebuild completes. So it's possible emulated disk has some data that the physical disk does not since the disabled disk isn't used for any writes that happened after, they are emulated instead. The emulated writes can be recovered by rebuilding so that is the standard approach since the physical disk may not have everything. Safest approach is to rebuild to a spare disk as you plan to do, so the original disk isn't changed. That way if there is some problem with the rebuild, the original is a "backup".

That is not the Diagnostics ZIP, just syslog. The word Diagnostics in my post and your post and wherever it appears in the forum is automatically a link to the documentation explaining how to get Diagnostics. It is a single ZIP file. Be sure to Attach Diagnostics ZIP to your NEXT post in this thread. Make sure it is the ZIP file, not the unzipped folders.

You don't want to use FAT32 for an assigned disk.

Attach Diagnostics ZIP to your NEXT post in this thread.

No reason to think rebuilding parity ( which I assume is what you mean by "rebuild the array" ) would result in anything other than what a correcting parity check does.

Attach Diagnostics ZIP to your NEXT post in this thread.

If the failed drive was empty you can New Config with the smaller drive in place of the failed drive, let parity rebuild, and format the new drive during or after parity rebuild. Or New Config/Rebuild Parity with nothing in place of the failed drive since 250G is perhaps not big enough to bother with.

Click on the container icon and select log from the pop-up

@Ellol Please describe your problem.

USB not recommended for assigned disks. There are external enclosures with SAS connections though. Sounds like a new case with better cooling and more bays could be a good place to start upgrades.

After correcting parity errors, if you have some doubts, run another parity check after the errors have been corrected. If it still has errors after those were corrected, you still have a problem.

A common way to fill rootfs is a container host path that doesn't correspond to actual storage. If you changed the name of a pool, for example, but you have a container with a host path that still specifies the old pool name, then it is creating a path in rootfs for that old name, but it doesn't have any storage mounted there, so it is in RAM.

At least you did make a new post to tell us. If you had edited the original post, and no other post was made to the thread, then possibly nobody would have ever visited the thread again since had already been read. That is why I always say "NEXT post"

If that was not a correcting parity check, you must run one.

You really need to figure this out to get any help. Nobody is going to bother to download all those individual files. Perhaps your Mac is automatically unzipping the single Diagnostics ZIP file to a folder, and then you are trying to attach the folder. Go to wherever files are downloaded and find the single Diagnostics ZIP file and attach that single ZIP file to your NEXT post in this thread.

Attach Diagnostics ZIP to your NEXT post in this thread.

Attach Diagnostics ZIP to your NEXT post in this thread.

Anonymize is an option when you create Diagnostics. And you can examine the diagnostics yourself, they are text. If you see anything in diagnostics you think needs to be anonymized that isn't, let us know. While you get comfortable with that, post a screenshot of Main-Array Devices with the array started in Normal not Maintenance mode.

Attach Diagnostics ZIP to your NEXT post in this thread.

Yes, unassign the disk then start the array. If the disk will mount as an Unassigned Device, you can check its contents. If it is unmountable then it would have to be repaired as the emulated disk was. Perhaps that would also result in lost+found. Maybe the physical disk will have less (or none) in lost+found than the emulated disk. Those most recent diagnostics you posted appear to have been taken when emulated disk5 was still unmountable. Post new diagnostics after starting the array.

Before reassigning the disk to rebuild it, see if it will mount as an Unassigned Device.

Rebuilding the emulated disk will result in exactly what you see with the emulated disk, including the lost+found. The contents of the physical disk will be missing any writes to the disk that happened after it was disabled, but the emulated disk will have those missing writes. If you rebuild the disk, you will recover those missing writes. But, the lost+found that will result from rebuilding the disk might be a more significant problem than any writes that might have been missed. In so, your idea of New Config the physical disk back into the array could be a better choice, but in that case you must allow it to rebuild parity because the physical disk and parity are not in sync.