itimpi

I wonder if this a side-effect on the new pull limits being implemented on dockerhub?

A drive being disabled does not mean no SMART report is available. The normal reason for no SMART report is the drive dropped offline (and this is perhaps why it got disabled). However after a reboot the drive will still show as disabled (pending you taking recovery action) but the drive can now be online and thus provide a SMART report.

You should at the very least reboot UnRAID which will load a fresh copy into RAM from the USB stick. There is a good chance that is sufficient as otherwise a bad actor would have had to modify something on the USB stick to make it survive the reboot.

You DO have to have at least 1 drive in the array. However if you never intend to store anything on it you could just use a small flash drive to satisfy this requirement.

I have released the first version of the plugin that supports restarting array operations after stopping the array or after a shutdown/reboot sequence as long as it was a clean shutdown of the array. You need to be on Unraid 6.9.0-rc2 for this option to be available to you in the plugin settings. On earlier releases you will see the entry for activating the restart facility in the plugin settings but will not be able to change it to "Yes". I had considered hiding this entry on such systems but decided to leave it visible to make it clear that you need a newer version of Unraid to use it. Hopefully I have not introduced any regressions that has broken any previously existing functionality. If you notice any issues then please report them so that I can attempt to fix them. One oddity I have noticed is that the you can get some spurious notifications from the built-in Unraid parity check reporting and I have not (yet anyway) found a way to suppress these. The plugin will also output a notification on all Unraid releases if it detects that there is an automatic parity check triggered by Unraid as a result of an unclean shutdown. Hopefully as well as being generally useful it will make it clear why any array operation was not restarted.

There can be a significant delay before the GUI is updated according to the Settings->disk settings->Poll Attributes value

It is up to you - you just need to make sure that before starting the array the disks are assigned as you want them. in most cases it is easier to select the All option and make changes from that starting position.

When you removed the disk UnRAID started emulating it using the combination of the other data drives plus the parity drive. Unraid is therefore treating it as if it is a ‘failed’ disk, and when you replace it with a physical disk UnRAID will rebuild onto that disk what it thinks should be there I.r. The contents of the emulated disk).

You would have to do another New Config to re-arrange the remaining drives. Since the parity2 calculation takes into account drive position this would invalidate parity2. Parity1 is unaffected by disk position - just that the same drives are involved. I think the best way to do what you want would be: do the New Config option with the option to retain current assignments return to the Main tab and unassign parity2, and move disk12 to its new position (didk9?). If any disks need moving between slots for any reason now is the time to do it. tick the Parity is Valid checkbox and start the array to commit the assignments. The array should mount all devices and will be protected by parity1 stop the array assign parity2 again start the array to rebuild parity2 with the new disk assignments. (optional) run a non-correcting parity check. If everything is good this will report zero errors.

In theory both should work, but I think a Windows machine is less likely to interfere and would thus be the preferred choice.

This is not be expected behavior unless the script stopped your Plex container as part of trying to backup the data.

This suggests that there might be a problem in writing to the USB drive. It could be worth trying to create it on another machine if possible (this has worked for others). You can also try booting it on another machine (as long as you do not attempt to do anything after booting it will not change anything on that machine) to see if it works in that scenario as that will at least prove the drive is written OK.

I am afraid that still does not give me a set of steps I can use to try and replicate your problem. I would suggest you need to do something like providing a screenshots of docker container settings you are setting that are not being applied.

If you want to run scripts that are on the flash drive without first copying them elsewhere then use something like ‘sh path-to-script’. This gets around the fact that scripts on the flash drive cannot be given execute permission so they can be executed directly.

I do not see where anything could easily be hooked into the UnRAID GUI to ‘fix’ this issue which I’d why I did not think a plugin is going to help. I think we are just going to have to wait until the Linux kernel developers finally fix this issue at the btrfs driver level and Unraid picks up the fix as part of its normal migration to newer Linux kernel releases for new UnRAID releases.

Easiest thing is to use Tools -> New Permissions on the share in question. That should rectify such issues. If that does not immediately solve your issue it might also be worth running file system checks on your disks in case there is some file system level corruption that is causing this.

Not sure it is that easy I believe that the behaviour of powering off on a long press is probably baked into the BIOS so outside the control of the OS. Therefore if it is possible it is probably a BIOS setting somewhere.

Yes - UnRAID admin always runs over eth0 so what you did is the correct solution.

Not something I can see a plugin being able to fix. There has been work going on to get a proper fix applied at the generic linux BTRFS driver level and that is the sensible long term solution. Btrfs has been getting better at reporting sensible values but it is not there yet

Reformatting to XFS is only a partial solution. the 6.9.0 release is now at rc2 stage rather than beta. I run it on my production server so I think it is stable enough As long as you have a backup of your flash you can always easily revert if for some reason you encounter problems.

I have quite happily run that file directly from the USB without renaming it on my UnRAID system. The only thing I could not do is run it directly from the USB without specifying which program (E.g. bash) was going to run the script. That is because the script on the ISB stick cannot be given execute permission without first copying it somewhere else first. However by specifying ‘bash’ as the command to run the script it ran fine.

Parity drives do not need to be the same size - but they must be at least as large as the largest data drive.

It will be automatically created when the container with that mapping specified is started.

You would be better of giving a unique folder under /tmp (e.g. /tmp/transcode) so that there is no risk of files under /tmp belonging to other applications being inadvertently deleted leading to unexpected errors.

In that case it should probably be reported in a forum dedicated to Radarr I wound think? It does not round like an Unraid specific issue.