itimpi

At this point Unraid will be emulating that disk. If the contents for the emulated disk look OK then Follow the instructions for Rebuilding a disk onto itself.f

I assume you mean "disabled" (has a red 'x' against it)? This means that a write to it failed. for some reason. Unfortunately you seem to have rebooted since that happened so their is nothing in the diagnostics to indicate why as the logs do not survive a reboot unless you have the syslog server enabled. No obvious errors showing up in the SMART information (which is included in the diagnostics so no need to provide it separately). The procedures to use are covered here in the online documentation accessible via the 'Manual' link at the bottom of the GUI.

You might want to look into installing the Parity Check Tuning plugin to reduce the impact on daily use so you do not mind running the check more frequently (e.g. monthly).

The scheduled check should be non-correcting as you do not want a dtive that is playing up potentially corrupting parity. Normally you only run correcting checks when you are reasonably certain you have no outstanding hardware issues. Once you have run a correcting checks then subsequent checks (of either type) should show 0 errors. You then want to keep a watch on the server to see if you ever get any parity check reporting a non-zero value when not expected.

When you run the correcting check then it would report the same 5 errors but would be correcting them. I can see in the diagnostics a correcting check being run and correcting 5 errors. You should now be able to (optionally) run a non-correcting check and get 0 errors.

Once you have any parity errors reported then you will continue to get them reported until you run a correcting parity check, after which if there are no further issues you will get 0 errors reported.

Unraid is based on Slackware.

Unless you can find a way to get them into their own IOMMU group all 3 would have to be passed to the VM - as it is an all or nothing for the devices in a specific IOMMU group.

All containers installed via the Apps tab should show there. Only ones installed via a different mechanism should be absent. for every container installed via the Apps tab the settings are stored as a XML template on the flash drive under the community Applications plugin folder. You should always have a backup of your flash drive, with particular emphasis on the config folder as that includes all settings used in Unraid.

To be able to pass any adapter through to a VM it has to be isolated into its own IOMMU group. It is not clear whether your hardware/BIOS combination will allow this.

It is a known issue with btrfs (particularly with an odd number of drives) that those sizes do not add up. As the pool gets nearer full then the size of the discrepancy gets smaller.

The default for a pool is RAID1 (for redundancy), so with 2 drives of different sizes the available space is that of the smaller drive. if you want to have all the space available (rather than having redundancy), then click on the pool on the Main tab and change it use the ‘Single’ profile and then initiate a Balance..

The test should take something like 1-2 hours per TB. Progress only gets updated every 10%.

SSDs in the pools is typical. Any SSD in the main array cannot be trimmed (data or parity). SSDs in pools can be trimmed.

Just a thought - have you tried giving the full path to the ipmitool command - not sure the environment when you run via the command line is the same as when you run the script.

Maybe that partition already existed and Unraid just tried to use it. I would suggest that you remove that partition and try again. If that has does not work then post your system's diagnostics zip file to see if we can work out what is going on.

I am afraid those diagnostics are not much use as all the logs contain is messages of the form: Jun 15 04:40:19 Tower rpcbind[4040]: connect from 192.168.0.242 to getport/addr(mountd) Jun 15 04:40:19 Tower rpcbind[4041]: connect from 192.168.0.242 to getport/addr(mountd) Jun 15 04:40:33 Tower rpcbind[4158]: connect from 192.168.0.245 to getport/addr(mountd) Jun 15 04:40:33 Tower rpcbind[4159]: connect from 192.168.0.245 to getport/addr(mountd) Jun 15 04:40:44 Tower rpcbind[4195]: connect from 192.168.0.243 to getport/addr(mountd) Jun 15 04:40:44 Tower rpcbind[4196]: connect from 192.168.0.243 to getport/addr(mountd) Not sure what causes those. I assume those addresses relate to devices on your LAN?

Does the drive have multiple partitions on it from a previous use? If so you should remove them before trying to use the drive with Unraid.

I have several set up and they all run fine.

Do you have docker set to use a docker.img file or a folder? The diagnostics suggest you have it configured to use docker.img but the files that mover is complaining about look like what you get when you select a folder. Did you have that configured in the past? It might be best to disable the docker service; delete all the docker related files in the ‘system’ share; and then re-enable docker. You can then use Apps->Previous Apps to get the binaries for all your docker containers reinstalled with their settings intact and the files will be placed according to the Use Cache settings for the system share. Most the other shares look to have their files where you would expect according to their share settings. appdata shareUseCache="prefer" Exists on cache-main A---y shareUseCache="yes" Exists on disk3 domains shareUseCache="prefer" Exists on v------s, v-----s G----------s shareUseCache="yes" Exists on disk3, disk4, disk6, disk7, disk9, disk10 g-------e shareUseCache="yes" Exists on disk9 isos shareUseCache="prefer" Exists on cache-main, v-----s M------------e shareUseCache="yes" Exists on disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8, disk9, disk10, disk11 n-------d shareUseCache="yes" Exists on disk3, disk4, disk6, disk9 S---------y shareUseCache="yes" Exists on disk3, disk4, disk6, disk7, disk9, disk10, disk11 system shareUseCache="yes" Exists on cache-main, disk10 T----------e shareUseCache="yes" Exists on disk3, disk7, disk9 T----------e (1) shareUseCache="yes" Exists on disk3, disk6, disk7, disk9 T-------------r shareUseCache="yes" Exists on disk1, disk2, disk3, disk4, disk6, disk7, disk8, disk9, disk10, disk11 you seem to have 2 pools related (I think running VMs since they are ‘vm_ssd’ and ‘vm3_ssd’ with the domains share existing on both of them. Is this intentional? Since mover never moves files between pools you would have to do this manually if the files are not where you want them. The other one that looks a little odd is the ‘isos’ share which is configured to use the ‘cache-main’ pool but seems to also have files on a ssd pool. Again you would have to move files manually to tidy this up. In fact since isos are often only required when initially setting up a VM you may decide to hold them instead on the array to free up pool space.

As was mentioned - along the right lines, but the wrong number of fields (there should be 5).

The issue is more why the File Manager is not letting you edit the files In principle the CA Config Editor should now be superfluous.

Just a hint - it you install the Parity Check Tuning plugin even if you use none of its facilities you will find that the log entries get enhanced so that you can tell how any parity check was started, and whether it was correcting or non-correcting.

Have you tried simply pressing enter with user=root and password blank? As part of tightening security it is now mandatory to have a password on the root user.

That message is not meant to occur with the latest version of the plugin! There was a bug that could result in that in an earlier release if the plugin thought a shutdown was untidy but got it wrong. It was meant to be an informative message when a parity check was going to be automatically started by Unraid, but because Unraid did not do so the text is not sensible. It is not critical as it does not indicate the plugin is actually going to take action. If it can still occur then I would need a syslog with Testing logging mode active in the plugin to work out why.