itimpi

You might want to look at the Parity Check Tuning plugin so that the monthly check runs in increments outside prime time to minimise the disruption to users.

There is no ‘normal’ setting - it is what the user prefers. By setting it to only split at the top level you have TOLD Unraid not to use any other disk. If you wanted Unraid to be free to use the other disk you should have the split level for the share set to allow splitting of lower levels (I think the default for most shares is to allow splitting at all levels).

if the disk is being emulated correctly (using the combination of parity plus ALL the other good drives) then you want to follow the procedure documented here to get the physical drive back into a working state and the array protected again.

Getting IOMMU enabled is purely a hardware/BIOS issue and not something you can change by tweaking Unraid settings. According to the User Manual for your motherboard this you need Advanced => CPU Configuration => SVM setting enabled Advanced => Northbridge => IOMMU enabled Until the BIOS reports that IOMMU is enabled no sort of hardware pass through to a VM is possible.

I would think that the one most likely to cause problem is NerdPack

If you read the announcement you will see it states that tHe plugin is not available for the 6.8.0 release. If you are running that release the options are to upgrade to 6.9.1/6.8.2 (which do not need it) or downgrade to a release that is supported.

Are you sure the drives are spun up? It is normal for * to be displayed if they are spun down.

Rerun without the -n flag, and if prompted add the -L flag. After that the drive should mount OK.

Pre-clearing it can be a good idea as that speeds up adding it to a new drive slot. However I would avoid plugging it in at all if not needed unless there Is a reason such as not being able to easily access the server.

Users do not normally access the XML file directly. You could have set that IP address via the option to Edit the container settings in the GUI as that generates the XML file.

I would also suggest you do not add an additional drive to the array if you do not need it yet. It just adds a potential additional point of failure. You might want to just leave it on the shelf until needed.

it is worth pointing out that you can continue to use the array while parity is being rebuilt (although performance may well be degraded). The problem with removing a drive is that you cannot remove a drive without affecting parity unless it is all zeroes. The moment you format a drive to create an empty file system on it this is no longer the case, What you want could theoretically be done using the Alternative method on This link. however it does not seem to offer any advantage over the method previously discussed. it is really up to you which route you follow for a replacement. If Amazon will replace it then you will get a new drive. However depending on how long you have had it they may well tell you to take the RMA route anyway. If you get a replacement drive then you could simply rebuild onto the replacement without using Unbalance to clear the emulated drive as the rebuild process simply ends up putting whatever is showing on the emulated drive onto the replacement.

The .key file also stores your license level.

It is worth pointing out that although it still works reiserfs is deprecated. If you go through the process of migrating to XFS then one advantage will be that a file system check only takes a few minutes.

The easiest thing would be to replace the failed drive with a new one and rebuild it. However if you are not going to have a drive available to that then your best bet is as you say to transfer the contents of the emulated to the empty drive in the array. When that completes you can use the Tools->New Config option to reset the array to not include the failed drive, and rebuild parity to match the new configuration. Until that all completes you will be running without protection against another drive failing.

It is also worth pointing out that if you click on the flash drive on the Main tab there is an option to download a backup of the USB drive to your PC/Mac which makes it easy to recreate your USB drive with all settings intact. It is a good idea to do this any time you make a significant configuration change.

It depends on what was deleted. Anything in RAM will be recreated on a reboot from the USB drive. If it got as far as the physical media then anything deleted from there is list. No idea whether anything will have been removed from the USB drive - it is probably going to be a case of rebooting and seeing if everything comes back. If you have a backup of the dtive (something you should always have) then you can easily recreate it.

The licence key is tied to the USB stick and all the other configuration information is in the config folder so your approach should work fine. I would suggest that you made a local backup of both flash drives before you start by clicking on the flash drive on the Main tab and selecting the option to make a backup. it is not clear to me if the serves are in the same location and how you are going to get the USB stick swapped between the two servers which would be required as the licence travels with the drive.

That is nowhere near all the files that should be on the flash drive It sounds as if the flash drive was very badly corrupted and the current configuration information has been wiped. Do you have a backup of your flash drive elsewhere (e.g. did you have he CA Backup plugin installed) as if not you are going to have to recreate your Unraid settings. In particular do you have a copy of your *.key type file that was in the config folder and contained your Unraid licence key (if not you will need to contact Limetech to get it resent to you and being a weekend there might be some delay). The good news is that as long as the data drives are intact you can get the array back with its current contents intact. Do you have any record of your disk assignments as that would make it easier.

Config on the flash drive is a folder containing many files/folders, not a file.

I would suggest that you put the USB stick into abPC/Mac and check it. Take the opportunity to make a backup of the current contents. You can then recreate the USB stick and see if that boots. If it does then copy the config folder from the backup overwriting the one on the freshly created USB stick to get back all your current settings.

Ok, first try rewriting that stick. There have been recent reports of boot problems where that fixed the problem. Failing that you will need a new USB stick and follow the procedure for transferring the Unraid licence to it.

Is you current boot device a USB stick or a card reader? If it is a card reader it might just be a case of replacing the SD card.

Unless you have a very slow CPU the parity check speeds will almost certainly be determined by the HBA throughput and disk speeds.

You need a USB device that has a unique GUID to act as a UNraid boot device and most card readers do not meet this criteria! Have you tried rewriting your current USB stick in case something on it had been corrupted?