itimpi

Those diagnostics just show the system starting up and then waiting for the user to do something. The array has not even been started as auto-start is disabled.

Did you try accessing the WebGUI from another machine? When you try to boot in standard mode do you get the UnRaid boot menu? When you then attempt to proceed do you get lots of messages flashing past as Linux tries to recognise the hardware environment?

This basically means that you do not want any disk controller to act in RAID mode - but simply pass the disks through to be managed by Unraid.

Are you booting in GUI mode? If so can you access the GUI from another machine? I am trying to determine if your problem is related to GPU drivers or is something else

Sounds like a routing problem. I would carefully check the gateway is valid for the subnet and that the DNS is valid for internet access. You are likely to get better informed feedback if you attach the system's diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post.

The problem is that USB drives are prone to a temporary disconnect and then re-connecting with a different device identifier. Unraid is not "hot plug" aware and cannot handle the device id changing for any array or parity drives so it then treats the drive as failed and disables it. You then need to do a rebuild of the drive contents to get it back into operation which is a lengthy process with a good chance that the problem could occur again shortly. You are welcome to try a USB connected drive but you need to be aware of this issue as it can be very annoying. It is possible that your hardware may not show these symptoms but they are very common.

The full size of the drives is always used. You just will not be able to add any data drives that are larger than the smallest parity drive.

According to the screenshot of the container settings the path of the transcode folder inside the container should be /transcode.

Are you sure that you do not need to run the command inside the container instead of at the UnRaid level? you will get better support I think if you use the forum thread specific to that container (that can be accessed via clicking on the container’s icon on the Docker tab).

You can manually upgrade by downloading the zip file for the release you want and then extracting all the bz* type files overwriting the ones on the flash drive.

Is plex transvoding, and if so have you mapped the path for transcoded files to be external to the container?

It looks as if all the drives have dropped offline. This suggests it is something that is common to all the drives such as the power, disk controller, etc

Not if you want to avoid doing an unclean shutdown. UnRaid will have to write to each disk as part of cleanly unmounting it.

Mover does not work like that as standard! Do you have the Mover Tuning plugin installed? If so it could be as a result of the settings you have for that plugin. If not then something else is doing the move (e.g. whatever app is doing the download).

It would help if you give the last part of the the serial number of the drive in question? It was not obvious to me from the diagnostics which drive you are asking about.

You want to use Tools>New Config; select the option to use current assignments; return to the Main tab and add the extra drive. You now start the array to commit those assignments. By default UnRaid will rebuild parity, but if you are certain that parity is valid you can tick the “parity is already valid” checkbox before starting the array to avoid rebuilding parity.

There is functionality that can only be implemented as plugins because of the level of access to the system that is required, and it may well be the my servers plugin falls into that category.

I wold have thought so but we cannot be certain until we get at least a test version.

Most of the time switching to new hardware and booting of the Unraid flash drive 'just works'. The one thing to be wary of is that if you are running VMs and using hardware pass through then the Id's of passed through hardware will change so disable any such pass-throughs (if any) before starting the switch.

The diagnostics show that the parity check being run is non-correcting (this is the default for any check being run after an unclean shutdown is detected) . You need to run a correcting check to get this rectified. The GUI does not distinguish between errors being corrected or not so you will get the same error count on the correcting run but after that it should revert to 0. It might be worth mentioning that if you have the Parity Check Tuning plugin installed the History will have additional information logged including whether a check was correcting or non-correcting.

Plugins can break anything as they have unrestricted access to the system which is the reason that Safe Mode was introduced in the first place to allow users to easily suppress the loading of plugins. It is also one of the reasons that it is recommended that Docker containers (or VMs) be used where possible as this provides a level of isolation from the core Unraid system.

The memtest provided as standard with Unraid will only work if booting in 'legacy' mode. If booting in UEFI mode then you can download a UEFI compatible version from memtest86.com

Not yet had the chance to look at your diagnostics but thought it worth mentioning that this is covered here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI. FYI: SMART for all disks is already part of the diagnostics so no need to normally provide it separately.

Glad you found it despite my slightly incorrect path

Have you switched to Advanced view using the toggle at the top-right?