trurl

You should disable Docker and VM Manager until you get cache working again.

Looks like you may have opened your server to the internet. Your syslog is flooded with login attempts.

Or maybe you have clipped your screenshot of your plugins page. Attach Diagnostics to your NEXT post in this thread.

Doesn't look like you have installed anything. Install Community Applications plugin then you can use it to install other things, including Unraid Connect.

I recommend reading that whole page on user shares that starts before the link I gave.

replace

The physical disk was not repaired, and apparently doesn't need repair, so there is no lost+found. Any files written to emulated disk1 (after the disk was disabled) are not on the physical disk. Can you identify which files/directories are missing from the Unassigned Device? Can you see them on the repaired emulated disk1?

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/cache-pools/#replace-a-disk-in-a-pool

This includes that as well as other things about configuring shares. https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/#primary-and-secondary-storage

Attach Diagnostics to your NEXT post in this thread.

Mover won't move those files on cache

It might be useful to see if physical disk can be mounted as an Unassigned Device. Could be parity is suspect and that is the reason the emulated disk was unmountable.

The emulated contents are exactly what will be rebuilt, so the lost+found will still be there after rebuild.

Neither did repair 4.6GB is more than nothing, but not a lot comparitively. Linux 'file' command can try to determine what type of contents a file might have so you can try to open it in an appropriate application to see if you know what it is.

Fixing the filesystem created a lost+found share on disk1. These are files that repair couldn't identify so they will be random folder and file names. On the User Shares page, click Compute... for the lost+found share, wait for it to complete, and post the results.

So no files are actually copied? Seems like a permissions issue on the remote. Are you trying to copy to public shares?

For mixed sizes of btrfs drives, single profile would give you the total capacity, but of course, you wouldn't

You should add attributes 1, 200 for monitoring on each of your WD disks. Do an extended SMART self-test on parity.

Is the copy actually happening?

But unless /mnt/user is mounted user shares don't exist. Didn't see exactly where it went away in your diagnostics since it was created when the array started, but it no longer existed when the diagnostics were taken. /mnt/user0 was still there so I assume array access was OK but something not working with pools (cache). Might be useful scrub cache.

user0 is the user shares excluding all pools (just the array, in other words). user is the user shares including array and all pools. I think historically, mover worked by moving cache to user0, so user share settings such as allocation method and split level could be applied when moving to the array. It is more complicated than that now, but user0 is still created when starting the array because many still want it.

What is that remote server?

More likely a problem with cache, since /mnt/user0 was mounted, but /mnt/user was not mounted.

My Shares page doesn't look like that. Is that due to some plugin?

Not only has it created a user share, but it is going to create another user share next time it runs, named ab_whatever_date_time. What is the Backup Destination you have set in the plugin? You must have told it to store it directly to a pool or array disk. User shares are simply the combined top level folders on array and pools. If you create a top level folder on array or pool it is automatically a user share named for the folder. Backup Destination needs to be a path to a user share you create for the purpose, or a subfolder of a user share you already have. Where do you see this?