itimpi

As I understand it you have to create such a pool manually using the relevant CLI commands. Once that is done mounting any of the pool members within UD results in the pool being mounted. It is always possible the recent spate of UD updates have changes this though.

I think the default is legacy mode which leaves the trailing '~' on the EFI folder (but you specify you want UEFI boot enabled at creation time.) You then have to remove that for UEFI boot to work.

Are both of these separately licensed copies so you can boot from either without going through the license transfer process? You could give one of them a different label (e.g. UNRAID-BACKUP) and then adding something like unraidlabel=UNRAID-BACKUP to the 'append lines in the syslinux.cfg for the backup copy. Which one gets mounted as /boot then depends which one you boot from (as long as the BIOS can tell them apart). This is the technique I use for running Unraid VMs under my main Unraid server for development purposes.

Have you made sure that the EFI folder on the flash has the trailing '~' character to disable the Unraid UEFI boot option? If that does not work and you can do it via a Boot over-ride then it feels like a BIOS bug,.

I assume that you mean the log4j vulnerability? Is so then this will not affect standard Unraid as it is a problem in Java based applications and Unraid does not have Java support installed. It could be a problem if a container uses Java and under that the log4j component I guess - no idea if any meet that criteria.

What do you actually mean by this? To boot in legacy mode then CSM support must be enabled. A BIOS option called Legacy USB support is not what is needed.

Not sure what is going wrong, but I do not use scp for this but instead have successfully mounted the Unraid shares on Raspberry Pi systems by first doing: sudo apt update sudo apt install samba samba-common-bin smbclient cifs-utils and then using using entries in /etc/fstab of the form: //network-name/share-name mountpoint cifs auto,uid=pi,gid=pi,user=username,password=password,_netdev 0 0 although you should be able to use the equivalent 'mount' command on Rpi instead of fstab entries. I have also gone the other way and set up a Samba server on a Raspberry Pi and then mounted this from Unraid via the UD plugin. You can google for the steps to achieve this. Note the above steps also work for me when I want to transfer files between a Windows machine and a Raspberry Pi

Not much to suggest other than one of your plugins seems to be the issue so you need to find out which one: Rename all the .plg files in the config folder on the flash drive to have an extension other that .plg (this will stop them being loaded in normal mode) Rename the ones you want to test back to having a .plg extension Reboot the server to see if it now works in normal mode. Repeat as necessary to identify the culprit(s)

The licence travels with the USB key and is not specific to a machine so in that sense you can transfer the licence to any machine as long as it is being booted off the licenced USB stick. All settings are in the config folder on the flash drive so setting that back to defaults (making sure you first make a copy of your licence key from that folder) sets things back to s virgin state.

No

Probably worth pointing out that with Unraid you can have multiple arrays as pools. It is only the main array that is (currently) restricted to a single array.

Maybe the best way to handle your scenario will be to create pool of HDD rather than SSD? That will give much better performance than hosting the VM on the main array (albeit not as good as SSD) without such a painful price impact?

I think the progress only tends to update in 10% increments.

No idea how you would tell the difference between a reboot and a shutdown. I will see if I can determine exactly what has been done already when it runs. Should be able to capture when it runs from the diagnostics I have built into my plugins. Not looked at what invokes it but you might be able to find out by running a grip for ‘stop’ on the various rc files in the /etc/cron.d folder.

Create a 'stop' script in the config folder on the flash drive. If present this is run late in the shutdown sequence. I have long thought that Unraid should provide as standard a dummy 'stop' file that does nothing to make it clear this is possible.

That at least suggests that the original USB stick is fine and it is something specific to your setup that is causing the problem. Have you tried booting in Safe Mode? If that works then you know that a plugin is probably the problem.

That will transfer all settings. Just make sure you keep the correct .key file for that stick in the config folder as the .key files are tied to a particular USB stick.

Not quite true. The ‘go’ file starts the emhttp server which is what starts all the services and the Unraid GUI, and that can run asynchronousky. Sounds like you could satisfy your need by inserting the long running part to happen before starting emhttp.

That message is only a warning You do NOT want to change the Use Cache setting to Yes as that will tell Unraid you want it moved back to the array. You should either leave it at the Prefer setting or change it to the Only setting.

Is your Unraid server exposed to the internet?

You have to rebuild a disk to get it back online once it is marked with a red X.

You will have to find a solution that does not require WiFi support within Unraid since Unraid lacks WiFi drivers and thus cannot drive WiFi directly. A WiFi extender that has a ethernet port for plugging into the Unraid server is a possibility.

Unraid does not include drivers for Wi-Fi adapters. why do you need the Unraid server to connect directly to the WiFi network? From what you say the WiFi devices can already reach Unraid.

You should never assume that the cables from different modular power supplies are interchangeable - even if they are from the same supplier.

Why? You do not need to use the full path. Simply using the ‘diagnostics’ command is enough.