itimpi

According to the diagnostics they all initially got automounted fine, but a bit later one started getting messages of the form: Jun 4 12:10:53 TheTower kernel: Buffer I/O error on dev sdb1, logical block 257917816, async page read Jun 4 12:15:06 TheTower emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/checkall Jun 4 12:15:06 TheTower ntfs-3g[12694]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Jun 4 12:15:06 TheTower ntfs-3g[12694]: Failed to read vcn 0x0 from inode 5: Input/output error Jun 4 12:15:06 TheTower kernel: Buffer I/O error on dev sda1, logical block 122094277, async page read Jun 4 12:15:06 TheTower kernel: Buffer I/O error on dev sdc1, logical block 47849196, async page read and they do not show up in the SMART information. This suggests to me that something common to them all went wrong. are you starting up any VMs? If so what about passing hardware through to them and if so since it looks like you recently upgraded to 6.10.2 have you checked whether the id’s of the passed-through devices are still the correct ones (they can change after an OS upgrade).

Sounds rather as if you may have a hardware error. Do you even get the BiOS startup messages displayed. just in case it is the flash drive you could try the steps detailed here to see if they help.

At this point Unraid should be emulating the disabled disk. Using that process will check and/or fix any corruption on the emulated drive (and will do no harm if not needed). To clear the disable state you need to rebuild the drive as described here in the documentation. Since the rebuild basically makes the physical drive match the emulated drive it is a good idea to check that the emulated drive does in fact have the content you expect - if not I would suggest posting back here for advice on the best way to proceed.

You can find the information here in the online documentation that can be accessed via the Manual link at the bottom of the GUI.

Exactly how is it failing when you try to boot? Are you sure the BIOS has the Unraid flash drive set as the boot device? it might be worth carrying out the procedure documented here to see if that helps.

There is something wrong then if the original key is in the config folder (which it should be if you copied the config folder over). The system should recognise the key does not match the new flash drive and initiate the transfer process. if that is not happening to you I can only suggest your email Limetech (contact details at bottom of every forum page) giving details.

You were earlier given the link to User Shates documentation, and that explains how User Shares are seen at the Linux level and how this is folder/file logical view that is independent of the physical drives. If you scroll down to the Disk Shares section it describes how array drives and pools are seen at the Linux level. If you look at this level you see the files/folders that are specific to the selected physical drive/pool. The fact that there are both logical and physical views to the same folders/files explains why there can be what at first glance might appear to be duplication. If there is still confusion after reading all that section of the documentation then if you can perhaps point out exactly which bits you find confusing so that it can be examined with a view to clarifying/expanding the wording.

Did you copy over the config folder (which contains your key file)? If so the system should be prompting you to go through the process for changing the flash device.

According to your diagnostics there are problems with the flash drive and this is almost certainly the root cause of your problem. Do you have a backup?

You are likely to get better informed feedback if you post your system’s diagnostics zip file so we can see what is going on.

You are likely to get better informed feedback if you post your system’s diagnostics zip file so we can see what is going on.

The toggle is the Help “?” Icon at the top right of the GUI and is always visible. Nothing to do with going into Settings

I must admit I had not yet considered that Now that you mention it there is also the fact that if you have different size drives in the array then the speed of the check can vary as each drive size reaches the inner tracks making it even harder to predict how long any particular percentage might take.

My suggestion would be to first add the parity2 drive and build parity on that and then replace the parity1 drive. That means that you have parity protection during the process. In theory you could do both at the same time but if a data drive failed while doing that you could end up with data loss.

I’ll think about it, but I am not convinced it would not just end up complicating the settings page without much benefit for the majority of users. You could achieve the same effect by slightly tweaking the increment pause/resume times so that each increment can run a little longer.

The first post in the plugin’s support thread describes what the plugin gives you.

It is normal for multi-disk pools with an odd number of drives to report the free space wrong (this is a btrfs issue). As the pool gets nearer Full then the size of the error diminishes. The SMART checks are nothing to do with that.

Do you have the Parity Check Tuning plugin installed? You are highly likely to want it with parity disks of that size to minimise the impact on daily work of scheduled parity checks.

It is expected. These are different views of the same folders. It is probably worth reading the User Shares part of the online documentations accessible via the ‘Manual’ link at the bottom of the GUI to understand why.

I am not sure which of the steps identify in the 6.10.2 release notes to work around the NIC being blacklisted you have tried to actually determine if you really need to downgrade. You mentioned disabling virtualisation completely in your BIOS so far but there are other options detailed there. If you need to downgrade then the release to downgrade to is probably the 6.9.2 release. If you can get diagnostics then posting those will allow you to get informed feedback as to whether (and how) you could get the 6.10.2 release working reliably on your hardware. Failing that you should probably wait for a future 6.10.x release where the root cause for the issues described in the 6.10.2 release has been firmly identified and a fix developed.

If you really have a parity check scheduled to run daily (rather than mover) then that is far more than is needed. Typically this is a maintenance task run something like monthly or even less frequently such as quarterly.

Only up/down is currently supported.

No obvious reason why you should have as long as the drives mounted OK after rectifying the error. If any drives are showing as unmountable I would suggest posting new diagnostics taken after starting the array.

You are likely to get better informed feedback if you post your system’s diagnostics zip file.

I would expect any 6.11 release to have significant new functionality. If it was only a kernel upgrade I would expect it to be a point release within the 6.10 series.