trurl

Parity knows nothing about filesystems, it is all just bits. Rebuild will result in the same bits on the disk, so can't fix corruption Attach Diagnostics to your NEXT post in this thread.

Then libvirt.img is an open file in the system share.

appdata, domains, and system shares have files on the array. In fact, you have domains configured to be moved to the array. Ideally, appdata, domains, and system shares would have all files on fast pool such as cache with nothing on the array, so Dockers/VMs will perform better and so array disks can spin down since these files are always open. Mover won't replace files, so if something exists on both cache and the array you will have to decide which to keep. Dynamix File Manager plugin will let you work with folders and files directly on the server and can help you figure that out. And, from your previous diagnostics, it looks like default 20G docker.img would be more than enough. After you get those shares moved and configured correctly, you can delete, recreate at 20G, reinstall containers. https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications

vdisks are sparse files but it can grow to the space you have allocated for it.

Nothing can move open files. You have to disable Docker and VM Manager in Settings before these can be moved.

Only drives connected when the array is started are counted.

What terms? Did you already buy?

Do you have adblocker or anything else that might interfere with browser?

Probably better to start your own thread with your diagnostics instead of posting to an old thread for an old version that is already marked solved.

What happens if you boot in SAFE mode? Doesn't look like there is anything for mover to do currently. However, you need to reconfigure system share so it gets moved to cache. And nothing can move open files, so you have to disable Docker and VM Manager in Settings to get those moved.

Looks like you have some corruption on disk22 Mar 27 10:15:10 Balor kernel: XFS (md22p1): Filesystem has been shut down due to log error (0x2). Mar 27 10:15:10 Balor kernel: XFS (md22p1): Please unmount the filesystem and rectify the problem(s). Also, disks 24, 26, 27 empty or nearly so. Is that expected?

Do you have a current backup of flash?

Contact support

/usr is a folder in the OS, which is in RAM. The user shares are at /mnt/user. The system user share only has docker.img and libvirt.img in a default setup. This is actually specified in Docker and VM Manager settings and so is under user control. And of course there is nothing to prevent users from putting other things in the system share so no way for me to know whether you had anything else in there or not. appdata, domains, and system user shares by default are setup to live on cache pool, so Dockers/VMs will perform better and so array disks can spin down since these files are always open. This is also under user control since you can change this and specify other shares or disks for these, in Docker and VM Manager settings, and even for specific containers or VMs. Best if you don't enable Docker or VM Manager until you have cache or other fast pool setup, or these will get created on the array instead.

yes

https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications

You should want appdata, domains, and system shares with nothing on the array so Dockers/VMs will perform better and so array disks can spin down since these files are always open. On the User Shares page, you can click Compute... for a share to see how much of each disk/pool is used by a particular user share.

That shows that those shares have some files on cache. It doesn't show that appdata, domains, and system no longer have any files on the array.

Realtime parity updates are the reason writes to the array cannot be as fast as SATA or even HDD speeds. https://docs.unraid.net/unraid-os/manual/storage-management/#array-write-modes And also the reason Unraid can allow different sized disks in the array.

If you want to try to sort out those lost+found files, Linux 'file' command can help detect what kind of data is in a file so you can try to open it.

Did you get these moved too?

which is in

You can go directly to the correct support thread for this container by clicking its icon in your Unraid webUI and selecting Support. Be sure to check out the information in the first post of that thread.

Possibly this happened due to starting Docker and/or VM Manager before you had a pool for them to live on. Nothing can move or delete open files. You will have to disable Docker and VM Manager in Settings before you can clean this up. Dynamix File Manager can help with this.

Unrelated, your domains and system shares have files on the array. Ideally, appdata, domains, and system shares would have all files on a fast pool with nothing on the array, so Dockers/VMs will perform better, and so array disks can spin down since these files are always open. Looks like you had your docker.img set to 50G before you switched it to a docker folder. Were you having problems filling it? The usual cause of filling docker.img is an application writing to a path that isn't mapped. Docker images shouldn't be growing.