itimpi

What HBA are you using? Typically there is a keyboard combination available during the boot sequence to get into the BIOS of the HBA (rather than the motherboard). From there you can disable the option for the HBA to report that any of the drives attached to it are bootable. Another option that may be available in the motherboard BIOS is to avoid running the HBA Bios during boot.

That error message suggest Unraid cannot find thebUSB stick during the later stages of the boot process. NTFS will not work! How did you create the drive? If you manually formatted it what size is the drive (Windows/MacOS do not format drives larger than 32Gb to FAT32). The drive must be labelled as UNRAID (all capitals). What make/model of USB drive are you using? if possible use a USB2 port as some motherboards seem to have trouble handling USB 3 correctly during the booting sequence.

As long as the disk has not physically failed this is normally easily rectified. The first thing, though, is to work out why you are getting errors reported in the first place.

In my experience the docker will fail to start with an error message about being unable to assign the cores it is configured to use.

There will be some difference if it is still in Unassigned Devices. If the names match then the reported size may be fractionally different which will cause Unraid to treat it as a different device.

Maybe another solution is to set up WireGuard VPN on your Unraid server and access it via that? As well as being more secure your port forwarding gets much simpler as the only port to forward in such a case is the one used for WireGuard.

No !

It might be worth posting the output of the 'df' command so we can see it the USB stick is being mounted at Boot

Is the licensing for the fusionio drivers on Linux such that Limetech would even be allowed to distribute them as part of Unraid? From what I have seen normally the end-user compiles themselves for themselves on their own Linux system. I could not find the current definitive statement on the licensing terms so I could be wrong about that.

There is no rule that says you HAVE to use a USB 2 port so you can try it and see if it works OK on your system.

The problem is whether the BIOS can properly handle the USB stick during the boot process, and the lifetime of the drive when it is left plugged in 24x7. Experience has shown that USB2 drives tend to be more reliable than USB3 ones and USB2 ports more reliably than USB3 ones. Since Unraid runs from RAM other than a few seconds during the initial load there is no practical advantage to faster drives. There is also not much point in larger storage capacity as Unraid will not need (or use) it. It is also normally recommended that you do NOT go for the nano sized drives as they are more likely to suffer from heat issues in a server where they are left plugged in 24x7. USB3 drives are also prone to running hot. The 32GB limit is due to the fact that if formatted by the OS Windows and MacOS will format larger drives as vFAT rather than FAT32. The recommendation is normally go for a 8GB or 16GB USB2 drive as the best compromise between being big enough, price and trouble free operation. I do not think there is much (if any) experience of USB-C and you are welcome to see if it works for you. Using such a high-spec drive does feel like a waste I would be interested to hear the results as going forward USB-C is going to become more common I would think.

No idea what is going on - maybe someone else might have an idea. It might be worth deleting the network.cfg file on the flash to revert to defaults to see if that helps but I could not spot anything obviously wrong in the one that was in the diagnostics. What I did notice that is a bit strange is that the end of the syslog emhttp segfaults. This is not something I can remember seeing before.

I was hoping it would not as the fix would have been easy to identify If the USB stick is mounting you should be able use the 'diagnostics' command on the console to create the zip file in the 'logs' folder on the USB stick. and posting that might help with identifying what is going wrong. Only thing I can think of at the moment is to plug the USB stick into a PC/Mac and check that there is no corruption on it. While you are doing that make sure you also take a backup in case later advice is to rewrite the flash drive.

When you log in on the local console does the 'df' command show that the USB stick is mounted as /boot? You can get the symptoms you describe if this has failed for some reason.

There should be a 'logout' button as the leftmost of the icons on the top right of the gui.

Ok - the syslog shows that you got lots of resets on the drive and it then eventually dropped offline so there is no SMART information in the diagnostics to help determine if it is a disk problem. i would suggest that you do a shutdown + restart on the Unraid server to see if that brings the drive back online and then post new diagnostics to see if SMART information is available to help determine its health. You might want to also take the opportunity to check that all cabling to the drive looks firmly connected.

Impossible to say without more information whether you have a disk problem. If you post you system diagnostics zip file (obtained via Tools >> Diagnostics) attached to your NEXT post this will allow for more informed feedback. Often such issues are due not to a faulty disk but to external factors such as problems with the SATA/power cabling to the drive.

With the current 6.9.x series of releases if you look at the Use Cache setting for a share then against that entry it tells you what action (if any) mover will take for the current setting, and that text changes dynamically as you change the value of the setting. That was done to try and make it clearer because users never seem to read the built-in help and get confused by the meaning of the options available.

Have you enabled the mover logging? It is off by default.

What Allocation method is set for the share(s) in question? If it is the default of High Water then you might want to read up on how that works as it is not obvious at first glance.

if anything it is the opposite If any package installed by NerdPack is different to a version that ships with Unraid then it can cause system instability. If you are going to use the NerdPack plugin only install what you definitely need and be prepared to back even that out if the system starts encountering problems.

Sometimes the BIOS limits the number of bootable drives that can be seen. I would suggest going into the HBA settings and disabling the option to boot from any HBA attached drives.

No - the parity check either runs full speed of not at all. The nature of what a parity check is doing probably means that reducing its priority would have little effect anyway There is an option to Pause and then Resume a parity check but this is a manual process, if you only want the Parity Check to run In increments outside prime time you could install the Parity Check Tuning plugin to automate that process.

A workaround would be to use a free-standing VNC client rather than the NoVNC browser based version supplied with Unraid.

I "think" all the functionality is now built in and has been for some time You can change the order in which containers start by using drag-and-drop on the Dockers tab. In advanced view you can add a delay after starting a container before the next one should be started.