Kilrah

rsync first makes a temp file, then renames it (to avoid leaving a partial file if the transfer is interrupted mid-way). What format? The error is about setting permissions, if it's one that doesn't support linux permissions this is normal, should be able to set it to be ignored. Also should probably be in the LuckyBackup support thread.

Parity rebuild restores a drive exactly as it was, can't change filesystem without manually copying all the data somewhere else, formatting, then copying back. If the array is now happy with the new (but empty) drive just mount the old drive in Unassigned Devices and copy data to the new drive hoping it lives long enough. DiskX is all that matters, sdX can change at any time so it's not a proper way to refer to drives. Post diagnostics and Main page screenshots if you need further input.

Thanks, I've pushed an update to the template to add the new path.

You hadn't, and it's your first post here... had you asked you'd have been pointed to the manual you could have also looked up on your own, particularly the section about "drive unexpectedly becoming unmountable": https://docs.unraid.net/unraid-os/troubleshooting/data-recovery/#unmountable-disks It's stable, but nothing in the world can guarantee data safety, especially not on consumer setups. The only data safety you ever get is backup copies of anything important on completely independent hardware.

Read that last couple of pages since it's where the relevant info for what just happened will be. Uninstall, reinstall the new one.

Unassigned Devices / Unassigned Devices Plus plugins

Obviously you need to choose your destination wisely, same as this script or any method. It has a field for a 2nd location to copy to. I don't use it, but rsync my appdata backups to another machine.

Apps will use the RAM they need. Most don't actually need much. Detections of credits is CPU/GPU-heavy, RAM doesn't matter much.

If you have plex or similar set to transcode to ram it probably had a bunch of leftover stuff in its transcode dir that got cleaned up in the meantime.

Nothing's changed in the flash backup method for a looong while. Also Appdata Backup plugin takes care of that for most people.

It's common for fans to need at least 30-35% to start/keep running, need to test with yours.

Your system is running out of RAM. It seems something is filling your rootfs.

Could disable all the start/stop/pause buttons when a preclear is running with a message just like for when mover runs.

Basically any operation that does a system-level sync to ensure all pending writes are committed will get hung if a preclear write phase is running because the preclear is constantly writing, it'll only exit once that's over. So if you have to run such operations pause the preclear. All your button presses will have been executed but they were all waiting for the writes to stop, once you paused they all ran to completion.

Correct

From my experience on several RAM amounts stability is more percentage-based than absolute quantity, I've only had issues like the one you have when RAM usage was >80% or so, reaching 85-ish% would usually eventually lead to a crash. My guess is if you undo your ZFS ARC increase to stay below 80% use it'll likely be stable again.

Mover always runs only based on the schedule, what the plugin does is that on the scheduled run it decides what to do or not. It's not realtime.

Early Ryzen is a poor choice for servers, they have common instability issues at low load so you typically have to disable power saving features. Also typically worse compatibilty with apps for using the iGPU.

Probably need to manually destroy the system dataset on the cache.

You have an lvm so there's yet one more step - Grow vdisk - Grow lvm - Grow partition - Grow filesystem This shows the first 2 were done, the latter 2 probably not, you have to mount the lvm to do those

If you increased the vdisk size you forgot to also increase the partition size in the VM. Expand it in gparted.

Moving docker folder is pointless, it'll be completely broken because since it's a folder and with native driver it currently relies on zfs features that won't be there on your xfs drive. Delete and recreate at the new path. That's a reason why image is preferred, it's self-contained, doesn't care about what storage it's on and can get moved just fine. Also it's only the Docker filesystem that needs adjusting, appdata/domains/the rest of the system share are fine on zfs as is.

If you have Docker in folder mode and with the "native" driver option yes it'll do that, and it's not recommended on zfs drives.

Check on the array (/mnt/user0) and any other pool if there are files/folders that remain from those shares. Even an empty leftover folder would prevent the shares from becoming exclusive.

Looks like it does get stopped. Any other containers that are set to be skipped that might access the same paths?