itimpi

I believe that mover tends to process shares (and their contents) in alphabetical order.. There was probably not much spare space when it started on appdata and do nothing got moved. You say it is currently moving data off the cache for the ‘homeserver’ share which is freeing up space? The ‘appdata’ share seems to be bigger than the cache can hold which is not a good scenario to be in - any idea why it is that huge? it is also worth mentioning that the ‘system share contents can normally only be moved if the Docker and VM services are stopped as these hold files open and open files cannot be moved.

You can do it from the GUI by clicking on the drive on the Main tab. For XFS file systems the array needs to be running in Maintenance mode while BTRFS is done from normal mode.

Look like you had multiple disks drop offline simultaneously. I would suspect that you have some sort of hardware related issue. Since a parity check is when the system is under maximum load it could be power related. Other possibilities that spring to mind are something more obscure like an improperly seated HBA.

Looks like you have file system corruption I would suggest running a file system check/repair on all your drives.

Why would you expect these to be moved? The ‘prefer’ setting tells mover to move the share contents ONTO the cache if there is any room.

I would have thought you could do this by setting each VM to use Bridged networking, and then giving them static IP addresses on their own subnet and with no gateway so they cannot navigate to other subnets. Must admit I have not tried it but I would think it would work?

I was not able to change that setting until I stopped the array? Did not try stopping docker instead to see if that is an alternative?

Would not expect the view to change after a reboot. The updated diagnostics suggest the disk itself is fine. Hopefully you have fixed any cabling issues. To clear the disabled state the parity has to be rebuilt. You can follow the process given here in the online documentation accessible via the ‘Manual’ link at the bottom of the Unraid GUI.

You should go via the Apps tab in the Unraid GUI. Overleaf does appear to be the only one for which somebody has decided to create a specific Unraid template However there appear to be plenty available on dockerHub as long as you are prepared to configure your own mapping to local storage. Note that to be able to see dockerHub containers you need to have enabled this option under the Settings section on the Apps tab (with the array stopped).

According to the diagnostics the parity disk was disabled because it dropped offline As a result there is no SMART information for the drive so we can check that for the drives health. Most of the time this sort of issue is a problem with the power or SATA cabling to the drive. I would suggest powering off; checking (or changing) the cabling to the drive; powering back on; and then getting new diagnostics so we can see the SMART information for the drive.

The process to follow in this scenario is covered here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

It should be the right-most tab in the UnRaid GUI.

That could definitely be a problem! Normally no more than about 4 would be recommended and you want to avoid using too many splitters as they are also often a contributor to power issues.

Edit the title on the first post in the thread to add “(SOLVED)”.

You cannot move the licence easily but you can swap the configurations over by copying the ‘config’ folder between the drives as that is where all user settings are stored. You just need to make sure that you keep the correct licence file for each USB stick in the config folder. I would first back up both drives to a PC/Mac before doing this just in case you make a mistake.

in which case I would be concerned that there is some other device on the local LAN that has been compromised. if it was just the USB then it could perhaps simply be a USB drive problem, but the array drives being wiped as well takes deliberate action. I guess another possibility is that you are running a Docker container that has been compromised?

Those diagnostics appear to be just after a boot and thus not giving much indication of what might be filling the log. You should try letting it run for a while and then post new diagnostics as that would allow us to see what sort of messages are filling the log.

this should not be possible to happen by accident and implies a malicious actor. Do you have your server exposed to the internet? This could be by putting it into DMZ on the router, or by forwarding the UnRaid management port in the router. There has been a spate of users doing this; then getting hacked; and finally deletions happening on the server. if you want to allow remote access to your server you should be using a VPN (WireGuard VPN is built into UnRaid).

There is not much I can think off other than powering off, checking cable; rebooting to check drive comes back online and then rebuilding the drive. You should post the diagnostics after the reboot so that we can check the SMART information for the drive. You might want to also consider running an extended SMART test on the drive. I was hoping someone else would have a ‘flash of insight’ as to what went wrong as not knowing that means it could easily happen again.

No way to do what you want and even if you could it would not help as mover does not take into consideration the size of a file it is about to move when selecting a target drive. For very large files it is easiest to move these directly to the desired drive by-passing cache completely. You would need to have Disk Shares enabled to do this.

This is covered here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

The diagnostics just show that the drive dropped offline for some reason with no obvious cause that I can see. Because it has dropped offline there is no SMART information for that drive in the diagnostics to give an indication of its health.

Have you looked to see if you have a ‘media’ folder on the cache? This will give those symptoms even if there is no content inside that folder.

I would have thought the correct answer is 2TB for RAID1 profile, and the 3TB is the known issue of BTRFS reporting incorrectly with an odd number of drives?

The whole zip