itimpi

I have never had any problem with 1). As was suggested try the Manual method for creating the USB drive, or failing that try a different PC/Mac.

Looks as if your diagnostics appear to be shortly after booting and not taken while you were exhibiting the problem? Regardless, they are enough to show that you have file system corruption on disk7 so you should put the array into maintenance mode and the click on the drive on the Main tab to run a file system check and repair.

Not really - it is the USB factor. Unraid does not function well if the connection to the disk is not rock solid as it is not 'hot-plug' aware and cannot handle momentary disconnects which is something that USB drives are prone to. Note: The UD plugin CAN handle non-array drives connected in this way.

You would need some device to be running a valid gateway on the 192.168.1.x subnet to be able to route between them.

Unraid does not implement what is normally meant by RAID0 (and hence the name). Unraid will never have the performance of a more typical RAID system for a number of reasons Each array drive is a self-contained filing system and so files cannot span drives and striping cannot be used. Reads are therefore limited to the read speed of any drive involved in the read. For writes Unraid updates parity in a completely different way to a standard RAID system which leads to significant performance overhead. The techniques used for Reads and Writes are described here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI. If you want to use Unraid with performance as the main criteria then you should not use the main array for the data but instead look into use Unraid BTRFS pools as these operate more like a traditional RAID system.

CRC errors are rarely actual drive problems. They are connection problems and are typically related to the SATA or power cabling. Normally they will just cause a retry of a read or write and as long as that succeeds no error is reported (although the retries can downgrade performance while they are taking place). It is also worth noting that the CRC count can never be reset to zero - you only know that there is no issue remaining if the counts remain stable.

Have you checked there are actual files still on the cache? It will never get down to zero space used as some space is always used to store file system control information.

If you are using UnRaid v5 then the file system type must be reiserFs and the tool to use is reiserfsck. On v5 it needs to be run from the command line.

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.