itimpi

Theoretically you can write to the array, but the writing and parity build both have significantly degraded performance while they are running in parallel so you may prefer not to.

If you cannot get the templates from a backup then the only way to get things back to a normal state is to remove each container and then re-install it with the same settings you previously used.

Not sure what you are talking about still. For most HBAs configuration is done at the BIOS level.

If you really want to start clean you could just restore the key file from the config folder in the backup to the config folder on the flash drive.

Is there any chance you are filling up the cache during these transfers? You have the Minimum Free Space setting for the cache set to 0 which would stop the transfer bypassing the cache if it gets full. Ideally you want this to be set to at least the size of the largest file you expect to transfer.

Do you have Plex set to do Teanscoding? If so is the location for the temporary files created during transcoding mapped to a location external to the docker.img file?

Probably the best way to check the health of the drive is to run an Extended SMART test. That is internal to the drive and thus not affected by SATA cabling issues (although bad power could cause it to fail).

Since you see to be using a completely different set of drives have you used Tools->New Config to reset the array? You are likely to more informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Unraid licence is tied to a USB stick, not any particular server hardware. You can get the message you mention if the flash drive has either been previously used by you for Unraid, or if it does not have its own unique GUID.

You can only get at paths on the host from a docker vontsiner that you have mapped to external storage. Looks lie you are looking at paths inside the container that have not been mapped to paths on the host.

The only standard way to clear a ‘disabled’ state on a drive is to rebuild it. Since you rebooted the diagnostics do not show what lead up to the drive being disabled as syslog resets on each boot. If you want a persistent log that survives a reboot you have to enable the syslog server.

The templates holding the settings you used for docker containers installed via CA are on the flash drive in config/plugins/DockerMsn/templates-user. You might want to check you have those as your symptoms suggest that they might not be there.

Unraid will regularly read the SMART information if it thinks is drive is NOT spun down. The strange thing is that you say this does not happen in Safe mode so it has to be something that is only running when not in Safe mode. Have you identified what that might be? I do not see how anyone can guess what might be spinning up the drives without being able to directly examine your system. BTW: You seem to have a lot of .cfg files in the config/shares folder on the flash drive that relate to shares you no longer seem to have. It is probably worth deleting them to clean up the diagnostics.

I partially agree with this, but I would go for leaving some work space free (such as 20-50GB) rather than as a percentage of the drive.

Technically this is optional, but in practice one nearly always wants to do this to minimise the chance of making a mistake in assignments. You can still make any changes you want when you return to the Main tab.

it sounds as if the MakeBootable script (versions for Windows, MacOS and Linux are on the flash drive) has not been successfully run to set up the drive to be bootable in legacy mode. Very difficult to tell if this is the case if it is not possible to test the flash drive in another computer to see if it boots there.

You should post your system’s diagnostics zip file so we can get a better idea of the current state of things.

There is a sticky thread on this in the General part of the forum.

No it is not! The default for Unraid is legacy boot. If you want UEFI boot you have to rename the EFI~ folder to EFI (removing the tilde) and then both UEFI and legacy boot are supported. That is one of the reasons I suggested testing the flash drive on another system - it is not unknown for the standard installer to fail to set the drive bootable (I have no idea why).

Not sure what you mean? Are you saying that you cannot get your server to boot if syslinux is used? It would always be worth checking the flash drive you create on another system to check that you have correctly set it up to be bootable.

Local LAN addresses can be safely posted as they give away nothing that is private about your system.

Syslinux is the default boot loader for Unraid

Bios level

It might be worth seeing if you can complete an extended SMART test on that drive. BTW: Your disk2 is not looking very healthy with lots of reallocated sectors and pending sectors so it probably should be replaced.

Probably, although if you have 75GB set as Minimum Free Space then there is a good chance the larger file will still fit so no action is required.