itimpi

If you go into the Advanced view on the Docker tab you can: re-order the start up order set delays after one docker container is started before attempting to start another one Using this might allow to use values that mean you do not encounter this issue. another possibility would be to use the User Scripts plugin to run a script after array start to automatically restart any docker that needs it.

If you go into the settings for the plugin there is a warning across the bottom of the settings area warning you to use a dedicated share.

Not sure about that card. ASMedia is normally fine as long as there is no port multiplier on the board, but that board appears to have one. @JorgeB might be able to weigh in on this and whether it matters?

That is very old information as it says at the beginning. It also says for unRaid v6 avoid anything with a Marvel based chipset. Al the most recent Linux kernels seem to have trouble using Marvel based controllers. Experience has shown they have a tendency to drop disks offline for no obvious reason.

This suggests the switch does not support jumbo frames? You should not be using them if that is the case.

No. A rebuild can never change the disk format - it can only rebuild to the format that was present before the rebuild.

It is worth remembering that the quoted URE value is for I/O operations, and each sector is 512 bytes. The likelihood needs to be based on the sectors on the drive rather than its capacity.

the latest version of the plugin is no longer compatible with 6.8.3 as it has been updated for 6.9.0-rc2 compatibility. If you look back a bit in this thread you will find details on how to install an older version that is compatible.

What version of Unraid are you running? This can affect whether the plugin is available to install via the Apps tab.

The fact that is occurring regularly does suggest a hardware issue of some sort. Whether it it the disk drive itself or something else may be indicated by the diagnostics. Have you checked out some of the more obvious alternatives such as the SATA or power cabling to the drive? What type of disk controller is the drive connected to? Marvell based ones are notorious for dropping drives offline for no obvious reason as are disk expanders

There should be no problem with seagate Ironwolf drives. If this happens again make sure you grab diagnostics before rebooting so we can see what lead up to the problem occurring.

You should never keep getting repeated corruption with no obvious disk problem without some other factor being at play. My main suspects would be: a failing RAM stick. Have you run memtest recently? power supply related issues (either the PSU itself or the cabling from it). Disk controller issue cabling issue. You should include your system’s diagnostics zip file (obtained via Tools -> Diagnostics) attached to your next post that coveris a period where the problem occurs to see if that can provide any clues.

There has to be something wrong or missing with your description as a failing parity drive will never trigger writing data to a data drive that would not be written anyway. had you formatted the new drive? Assuming you have then the data would be written to it only if it is the correct drive to be using for the data at that point. You may get better informed feedback if you include your system’s diagnostics zip file (obtained via Tools - > Diagnostics) attached to your next post in this thread.

Regarding #3, the main disk controller issue is with any that uses a Marvell chipset (whether on the motherboard or on an add-in board). Port multipliers can also be problematical. This is a generic Linux issue with recent kernels and is not unRaid specific. Not sure why you talk about the ‘dreaded’ LSI HBA controllers - ones based on thenLSI chipset have proved to be the most reliable, although they do need to be flashed to IT mode rather than RAID mode for unRaid to be able to use them optimally.

What may not be obvious is that the system can optimise access to a cache-only share so it gets a performance advantage over a cache-prefer setting. One has to decide if this is an important factor.

I use Edge all the time for accessing unRaid GUI from Windows without any problems

The one that CAN result in deletions is to misconfigure appdata backup to point to an existing location rather than a new dedicated share. That can cause deletions at the location it is pointed to.

Might be worth trying the repair again just to make sure, and if it is still unmountable when you restart the array in normal mode post new diagnostics see if they suggest a cause.

No idea why that last drive is still unmountable. As you say xfs_repair does not seem to be reporting any problem. With any luck someone else may have some ideas.

Whether this happens is set at the individual share level. For the behavior of first going to cache and later being moved to the array you need Use Cache=Yes to be set for the share. The built in help gives a good summary of how that setting works, and more detail can be found here in the online documentation that can be accessed via the Manual link at the bottom of the unraid GUI.

Assuming you are using Windows Explorer have you tried avoiding using any of the Icon views as they can be considerably slower as Windows gathers the information needed to display the icons.

Repair time is normally measurable in minutes so it seems something is going wrong You are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post.

Unfortunately the diagnostics only show what happened after the reboot and not what lead up to the problem. You may find this section of the online documentation (available via the ‘Manual’ link at the bottom of the unRaid GUI) that covers ‘unmountable’ disks to be of use.

The easiest way to do what you want would be: Move all the files that are currently on disk3 to one of the other array drives you intend to keep and that that has space for them as the existing contents will be destroyed when you later use it as a parity drive. use Tools -> New Config ro say you want to reset the array configuration. I would advise also using the the option to retain current assignments as it means you are less likely to make a mistake later in drive assignments. return to the Main tab and re-order the drives to how you want them to end up. This will result in both of the ‘ST’ drives no longer being assigned so that they become visible under the Unassigned Devices section. Make sure you do not assign a drive that currently has data on it to a parity slot as that would destroy its content. You can re-order the data drives at this point if you want to. Start the array to commit the new assignments and build new parity based on these new assignments. UnRaid will leave the contents of the data drives alone as it will recognise that they are already in an unRaid compatible format. if you have any specific include/exclude drive settings for any of your shares make sure they are updated to reflect the new drive arrangement. The same would apply to any docker containers or VMs that mention specific array drives. one downside to the above approach is that your array is not protected against one of the remaining data drives failing until parity has finished being rebuilt. There ARE approaches that could maintain at least one valid parity drive during all steps of the process but it is ‘trickier’ and multiple steps would be required to make changes incrementally so the process would take significantly longer.

On having another look at the settings for your Media share the other value have set that could cause problems is the Split Level setting. Sorry I missed that earlier In the event of any contention between the various share settings over which disk to choose for a folder/file the Split Level setting always takes precedence. This can force unRaid to try to try to put the file onto a drive that does not have space for it. A more relaxed Split Level setting is likely to be require in your case?. There is a good description here in the online documentation accessible via the ‘Manual’ link at the bottom of the unRaid GUI that describes how the Split Level setting works. since unRaid never moves files automatically between array drives you may want to initiate a manual move of files off disk1 onto other drives?