trurl

Seems like you are trying to update from a version that is too old to be updated. What version of Unraid do you have?

That share is configured to move files from array to zfscache. But it has no files on the array. Set it to Secondary storage:cache then you should be able to set Mover action to cache->Zfscache. As mentioned Then you can run Mover to get those moved from cache to Zfscache. The problem with lost+found is that is where repair puts files that it can't figure out, so they will often have random file and folder names. Linux 'file' command can be used to try to figure out what type of data a file contains so you can try to open it in an appropriate application and see if you can identify it. If there is a lot to go through, probably easier to restore them from backup if you can figure out what might be missing. Disks 12,13 currently have files from 2 shares a------l shareUseCache="no" # Share exists on disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8, disk9, disk10, disk11, disk12, disk13, disk14 j----------e shareUseCache="yes" # Share exists on disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8, disk9, disk10, disk11, disk12, disk13, disk14plus there were 2 other shares that have no files currently b--------------n shareUseCache="no" # Share does not exist p--x shareUseCache="prefer" # Share does not exist Since you have dual parity you still have redundancy without disk8. But you should still find time soon to take care of this. If your cabling is a mess you may get problems with other disks. Some tips on cabling. Don't bundle data cables. All cables, data and power, must sit squarely and firmly on the connection with no tension on the cable that might pull it loose. Also, power connections can cause similar problems. Ideally, no more than 4 disks per PSU cable, even if you use splitters. If you must use splitters, MOLEX-SATA splitters are better than SATA-SATA power splitters. If you don't have enough SATA cables from the PSU, disks can be connected to MOLEX cable with MOLEX-SATA connector.

open.files.plg - 2025.12.03 (Unknown to Community Applications)You should remove that and install a newer version if there is one. zfsappdata does have some files on cache. Nothing can move open files. Simplest thing is to disable Docker in Settings so those could be moved, depending on settings for that share. Post a screenshot of the settings for your zfsappdata share. UDMA CRC errors are connection problems, not disk problems. Just acknowledge the current count by clicking on the SMART (👎) warning on the DASHBOARD and it will warn again if it increases. syslog-previous shows the connection problem with disk8 that disabled it. Emulated disk8 is mounted so should be OK to rebuild on top after you have fixed its connection. https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself Also, looks like you may have lost+found share on disks 12,13 from previous check filesystem repair. Have you looked at those?

I recommend leaving Docker and VM Manager disabled until everything is working again.

Post new diagnostics

Also, USB not recommended for assigned disks for many reasons. And, you don't have cache. Does the mini PC not have any ability to use internal drives such as nvme or SSD?

The disk was disabled when a write to it failed. That failed write and any subsequent writes are emulated by updating parity. The emulated writes can be recovered by rebuilding. Except the emulated disk is unmountable, so it needs to be repaired before rebuilding. Repair can sometimes leave some files "lost+found", and that might be worse than any writes that were missed. When you repaired the sd device instead of the md device, parity is no longer in sync with the repaired disk. The repaired disk could be put back in the array with New Config and then parity rebuilt. But it may be missing some writes that were emulated. If you rebuild the repaired disk, it will be overwritten with the contents of the emulated disk. But the emulated disk is unmountable. The emulated disk must be repaired before rebuilding. Even though it seems you were using the correct command lines, it is really better to do repair from the webUI. Do you have any of the output from repairing the physical disk (sd device)? Since you have already repaired the physical disk filesystem, and it is out of sync anyway, see if you can mount it as an Unassigned Device and check its contents. In particular, look for a lost+found folder at the top level. And, you might as well go ahead and repair the emulated disk filesystem. Start the array in Maintenance mode and check filesystem on disk1 from the webUI. Post the output.

What were you using NerdTools for? That would certainly be a suspect since it might install something incompatible.

Add new data disk as disk3. If it isn't precleared Unraid will clear it, they you can format it as xfs or zfs if you want. Not sure of the advantages of zfs in the array. Then move or copy the data from the others however you want. Copy is faster than move and you don't really need to move the data off the original disks since you are removing them anyway. When all data is on the new disk, New Config with the new parity and new data disk as disk1 and without the others. Then let parity build.

Can you boot in SAFE mode with GUI? Either way, you can try to get diagnostics from GUI or from command line and attach ZIP to your NEXT post

Attach Diagnostics ZIP to your NEXT post in this thread.

Are you trying to use Add Container from the Docker page in the Unraid webUI? Or maybe a docker compose plugin? More details on what you have tried.

Only root has access to the webUI or command line. If you don't know your root password: https://docs.unraid.net/unraid-os/system-administration/secure-your-server/user-management/#reset-your-password

Don't know what you mean there. Unraid parity is realtime. Any time an array data disk gets written, parity is updated.

Are you running Unraid as a VM?

There is nothing about emulation or rebuild to explain what you are saying. Nothing about emulation or rebuild has any effect on any other data drives. Parity is updated when the emulated drive is written, that is how writes are emulated. But parity contains no files and none of this has any effect on any other data drives. The most likely explanation is something moved the files. Another possibility is the file already existed on the different drive and something deleted the duplicate from the emulated drive.

Post a screenshot of your syslog server settings.

This is the least efficient setting. Highwater is default because it will allow all disks to get used eventually, without constantly switching disks just because one disk temporarily has more free space than another.

syslog is a single text file. Zip the latest syslog from wherever you configured syslog server to save it and attach to your next post in this thread. Also The word Diagnostics in any post on the forum is automatically converted to a link to the documentation that explains how to get diagnostics, including from the command line. Next time it happens before rebooting it might be useful to see the result of this command line: df -h /

If a file was moved from the emulated drive, it wouldn't be on the rebuild but would still be on the physical disk.

You can reinstall your containers from Previous Apps on the Apps page, and it will use the same mappings, etc you had before. But without appdata, each application will be starting over.

Delete is a write operation. If a file was deleted from the emulated drive, it wouldn't be on the rebuild, but would still be on the physical drive.

Not clear what you mean by "disabling" in the context of a drive that is not part of the parity array.

A new parity check does not reference anything that happened on previous checks. Why would it?

Just to pick my own nit here. It is possible to write to the rebuilding disk. If rebuild had not already progressed to that block of the physical disk, then parity update results in emulated write. If rebuild had already written the block, then the physical disk is written with the new data and parity updated as usual.