itimpi

It might be worth changing the label on the 'old' key to be something other than 'UNRAID' and checking that the 'new' one is labelled as 'UNRAID' and see if the system then still boots OK. If it does then that would confirm that the problem must lie with how the 'new' one is being made bootable as it would confirm that the initial stage of the boot ran from the 'old' key ant the later stages from the 'new' one. There have been reports of security software silently interfering with attempts to modify the MBR on a flash drive to make it bootable so I am wondering if there is a possibility of that being your problem.

You might want to try downloading the zip file for the release and extracting the config/passwd and config/shadow files and putting them on the flash drive? I am not sure what happens when the 'shadow' file is missing and the 'passwd' file wants it to get the password. It is possible there is some sort of bug around this so report back on any progress.

You can simply remove all the listed drives from both the include and exclude fields on an existing share and it will then default to ALL This means that the files (or at least some of them) in the share are unprotected. This is normal if you only have one drive in the cache. With multiple drives in the cache with the cache set to support redundancy then they would always be protected. There is no ON setting Perhaps you mean Use Cache = Yes which first writes files to the cache and later moves them to the (protected) array? Whether a 250 GB cache is large enough to support this mode of working depends entirely on your usage pattern and how much you are likely to put on the cache between automatic mover invocations. Many users now only use the cache as an 'application' drive for use by docker containers and VMs. With a single drive in the cache XFS is normally the recommended setting, although if you later intend to extend the cache to a multi-drive pool BTRFS might be more convenient. Neither XFS or BTRFS suffer from slowdowns writing new files as the drive gets full. ReiserFS is now deprecated (although still supported).

High-water allocation uses the size of the largest drive in deciding when to potentially switch drives. In your case with a 8TB drive present the first switch point is 4TB. When all drives get down to this the next switch point at 2TB is activated. Since the 8TB drive has this much free space Unraid will continue to use it until it gets down to 2TB free, and when that happens it will start using the 4TB drives. When all drives get down to 2TB free the next switch point of 1TB will be activated so Unraid will go back to using the 8TB drive. There is a feature request raised requesting a new allocation method similar to high-water but based on percentage of drive used rather than basing it on the absolute size of the largest drive but whether this will ever get implemented I have no idea.

It is really up to the user to decide. The advantage of the router supporting it is that it does not require the Unraid server to be operational. You could of course use both with different profiles on the remote client. You might want to have a look at the Wireguard web site? You will see there that it is officially still classified as experimental by it's developers which is probably why it currently has limited real-world use. However I can see that changing rapidly and early feedback from those who have tried it already is very positive. Several of the major commercial VPN suppliers have stated that they are actively working on adding support for WireGuard to their offerings which is quite a good endorsement.

You said that you formatted it? Doing so would write an empty file system to the disk and update parity to reflect this. If the disk was being emulated the format would do this to the emulated disk. Whenever a rebuild happens it will restore exactly what can be seen on the emulated disk.

Have you tried a VNC client that is not noVNC based (e.g. something like realVNC)? If that works then it at least pinpoints the problem as being the noVNC client and not something else.

If you go the Tools->New Config route that has been suggested then when you start the array all the content of data disks previously used by Unraid is left intact.

The containers always start in the order on the Docker tab. You can drag-drop them into a different order. The delay field is how long to wait before starting the NEXT container in the list, not the delay before starting THIS container. Maybe you should provide a screen shot of your Dockers tab (with Advanced view enabled) so we can see exactly how you have these set up?

Do you have a 'previous' folder in the flash? If so deleting that will probably give you enough room. A 'logs' folder can also be deleted.

Can you ssh in? If so you could try the 'diagnostics' command from the command line to get the system diagnostics zip file to post. Failing that I would suggest posting the config/network.cfg file from the flash drive as most connection issues seem to be caused by spurious/incorrect entries in that file. BTW: You seem to have a very out-of-date signature as it shows you are running 6.0 beta 14a You can update your signature via your account settings on the forum (as well as turning on/off whether you see signatures)

Agreed that is the purpose of the script, but as I read it there is no intention of removing the drive.

Actually I would probably recommend setting the 'videos' share to Use Cache = Yes as that way you maximise downloads speed initially but then mover later transfers the video material across from the cache to the array which is its long term home. Having said that you want to optimise for your actual expected usage pattern across the Unraid server as a whole.

You cannot easily load your own kernel at the Unraid level. However this is normally a non-issue as you would normally run applications such as Minecraft in either a docker container (most common) or a VM. In both cases they are not aware of what kernel is being used by Unraid.

Does the Downloads share use the cache? If so that is expected behaviour when using Krusader as it works at the Linux level and is not aware of User Shares and can bypass them. As far as Krusader is concerned both source and destination are on a common mount point of /mnt/user so it tries initially to do a 'move' (i.e. rename) for speed and only if that fails does it try a copy + delete operation. The 'move' operation will leave the file on the same disk thus explaining your symptoms. The solutions are to either do a copy + delete in Krusader, or set the 'video' share to Use Cache = Yes so that mover will later move the file from cache to array.

The trailing ~ character is removed if you state that you want UEFI boot capability when creating the flash drive. You can also do it manually at a later stage to enable UEFI boot capability.

I think that one of the potential problems with USB3 drives is that they tend to run hotter than USB2 ones and heat is never good for electronics that are running 24 x 7.

It is an option on the boot menu. if you do not have a keyboard+monitor plugged into your server, you can edit the syslinux/syslinux.cfg file on the flash drive and move the ‘default’ line to the Safe Mode section and then put it back into the server and it will boot into Safe Mode.

This could be because Unraid was originally on v5 when ReiserFS was the only option for the cache file system, and it was never changed when the system was upgraded to v6?

You might have guessed the command - it is 'diagnostics'

This is mentioned in the release notes as part of tightening up security of the flash drive. Files on the flash drive can no longer be given execute permission. The easiest way around it is to run the command giving the script name as a parameter. E.g. bash scriptname if you run scripts via the User Scripts plugin it will automatically handle such issues for you.

I have not been able to open a terminal windows in Edge ever since the 6.8 RC series began.

I would also say that any time you make a significant configuration change (or just before an upgrade) you should click on the flash drive on the Main tab and select the option to make a backup from the resulting dialog so that you have a backup that is off the Unraid server. Maybe there should be an option to automatically generate such a backup as part of the upgrade process?

In my experience cache seems to win out, but since this is not documented anywhere I would not want to rely on that staying true in the future.

Since you are on the 6.8 release the text to the right of the Use Cache setting should explain what mover will do. Any suggestions on how this could have been improved to stop you selecting the wrong option?