itimpi

A 'disabled' drive means that as far as Unraid is concerned a write to it has failed so it will no longer use it until appropriate corrective action has been taken. This is covered in more detail here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

I would suggest you post your system’s diagnostics zip file (obtained via Tools -> Diagnostics) attached to your next post so we can see what is going on.

Disk2 has definitely dropped offline according to the diagnostics, and this results in an error in the syslog occurring any time you attempt to do anything with it. since the disk is offline there is no SMART information in the diagnostics to give an indication of its health. I would suggest you power off the server, carefully check the power and SATA cabling for disk2 and then power on the server again and as long as the system sees disk2 take new diagnostics and post them so we can see if disk2 looks like it is healthy or not.

If you make sure that you have a good backup strategy in place for anything that is important or irreplaceable then this is normally a sensible decision to take. If you DO decide to go the data recovery route and but forgo any attempt to rebuild then you should mention that each disk is a self-contained file system. It will probably be XFS unless you changed the default in Unraid to be something else.

To get the array back into operation without a rebuild you would need to use Tools->New Config to allow drives to be assigned and new parity built based on the assigned drives. UnRaid will recognise array drives that are already set up with UnRaid partitioning and will add them into the array leaving their data intact.

These are connection issues - normally power or SATA cable related although it can also be the controller to which the disks are attached.

I have heard of Unraid systems being hosted in remote data centres as an alternative to having them in one's home. However as was mentioned they do at the very least require the boot USB device to be dedicated to their use.

It is the name that Linux developers for some obscure reason used to refer to array devices under Linux. Limetech re-purposed the standard Linux array (md) driver with their own special variant.

The UnRaid driver is the one that Limetech provide to handle array devices which when in use are mounted with names of the form /dev/mdX (where X corresponds to the disk number. ‘Kernel’ is the underlying Linux.

No - it is an all or nothing scenario. A rebuild with 2 parity drives requires all except a max of 2 failed drives to be read reliably for the rebuild to work. With 3 failed drives this is not possible.

Technically USB disks are allowed but USB disks are not recommended as they do not tend to provide a reliable connection. UnRaid is not hot-swap aware and cannot handle a USB disk used as a array drive dis-connecting and then re-connecting while in use. If this happens then UnRaid will end up misbehaving. You might be better of not using the USB drives as array drives, but as temporary drives mounted using the Unassigned Devices plugin (which can handle USB drives reliably) and then copying data off them into the array of SATA drives. Since under UnRaid each array drive is a self-contained filing system they can be read individually even when removed from the array. Longer term these USB drives can e used for backup or data transfer purposes.

Copying across the config folder will transfer all the Settings to the Pro USB disk (but you may want to delete the config folder on the Pro disk first to clear any existing settings). After doing that you will want to make sure that the Pro disk only contains the licence key relevant to it. As a precaution I would recommend first taking a copy of the Pro disk current contents before attempting to copy anything across to it. You would then need to boot your server using the Pro disk in place of the current ‘Basic’ one.

I am confused - you mention setting the SSD as cache an then show an rsync command that is moving appdata to an Unassigned Device rather than cache You also make no mention of whether you updated the Plex mapping to point to this new location?

With 3 dead drives and only 2 parity drives then parity will not help you as you cannot run a rebuild in that state. In principle you should consider the content of those 3 dead drives lost unless a PCB swap can bring them back to life. You did not mention if the 3 drives were all data drives, or if any of them were parity drives? What is the state of your backups? That might help with determining if it is worth trying get the drives resurrected via a PCB swap. in the short term you can rebuild your array without the content of the 3 dead drives, and later if they are resurrected copy their content back into the array.

For some reason you seem to have the vdisk1.img file in 2 locations - on both the cache and on disk1. Unaid only expects a file to exist in one place and mover will not overwrite a file that already exists at its target location. You will manually have to decide which copy of the vdisk1.img file you want to keep and delete (or rename) the other one for mover to function correctly. It is probable that the copy on the cache is the more up-to-date version but only you can determine that for sure.

No - 1 data + 1 parity is fine. in fact it turns out to be a special case as the result of the parity calculation means that the parity disk is identical to the data disk right down to the bit level. This is not true when you have more than 1 data disk.

Just for reference this is mentioned here in the online documentation that can be accessed via the “Manual’ link at the bottom of the UnRaid GUI.

Is your server directly exposed to the internet or been put into your routers DMZ? UnRaid is not hardened enough against attacks to make this safe. the csrf token messages are saying that a web request has been made that do not include a valid UnRaid security token.

You should be able to use a VMWare .vmdk file directly under KVM on UnRaid, but you will need to type the path in manually as there is no GUI support for selecting ..vmdk files.

The flash drive suddenly going empty is never a good sign - suggests it may be about to fail That copy should be fine as long as you have made no changes to the drive configuration since that copy was made. If you have made a change since then ask for advice on how to proceed.

I would not think the part in brackets should be there?

No idea then. The syslog definitely shows that UnRaid thinks there is no cable connected. Maybe someone else will have a suggestion.

OK - I think I will raise it as a bug then and see what is the response. If the settings are not independent then the size on the cache/pool will often be irrelevant. I have seen no mention in the GUI help of this behaviour that I have seen and if it IS intended behaviour it should be mentioned there.

I have seen other indications that this is the behaviour but I would think it is a bug and the two settings should be independent of each other? Do you know if it has been reported as a bug?