itimpi

For array drives to show up in unassigned devices they need to temporarily disconnect and then re-connect with a different /dev/sdX identity. Unraid is not hot-plug aware and does not handle this. Why this might happen I have no idea. It is something one might expect from USB connected drives but you say that this is not the case here. Does it happen if you set those drives to never spin down?

Changed it - I thought I had actually written what you suggested - obviously I am not good at proof-reading

It looks like you are running a trial license and one of the requirements of the trial licence is that you have an active internet connection before the array can be started.

Probably worth mentioning that USB3 flash drives are much more prone to failure and since Unraid runs from RAM there is no significant performance advantage to USB3. I suspect that this is because USB3 drives seem to run much hotter and this is not good for them when they run 24x7.

Updating does not affect your current registration - what made you think it would? The main thing is to make sure that you keep a copy of the .key file from the config folder as it is that file that is the file holding your licence that is specific to the current USB drive.

/mnt/cache/appdata is a physical drive location that is part of the ‘appdata’ share. /mnt/user/appdata refers to the User Share that is made of the amalgamation of ‘appdata’ folders on cache and all array drives. If the Use Cache setting for the ‘appdata’ = Prefer, then mover will try and ensure that any files for the ‘appdata’ share are moved to the cache drive so they then end up being two different ways to refer to the same location.

Despite it being a commercial product Limetech is still a very small company (Originally it was a 1 man company and I think total employees are still in single figures) so do not really have the resources to have much in the way of dedicated support. Any support requests sent via email will therefore be handled by people who have other responsibilities as well. There is the ‘official’ part of the wiki accessible via the ‘Manual’ link at the bottom of the Unraid GUI which has a lot of useful information that can be regarded as reasonably definitive. Having said all that you are very likely to get much quicker and more detailed answers via this forum than any other route.

It is your decision as to how frequently you run the check - it is all about your tolerance for risk of a drive starting to fail. There is not much that can be done to shorten it as by its very nature it reads every sector on every drive. You can use the Parity Tuning plugin to at least schedule such checks to run in increments outside prime time (albeit at the expense of the elapsed time getting longer) so that impact on users is minimised.

Dealing with a drive showing as unmountable is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the Unraid GUI.

Interesting that you can get exactly the same symptoms on your VM as I get on real physical hardware. I would love hear if you find a solution as it is very likely that it would also work for me.

I have a feeling that Unraid will not allow these to be done in one step as adding the extra data drive starts a clear operation and adding a parity drive starts a parity sync operation - and you cannot run both of these at the same time.

Do you by any chance have an empty ‘appdata’ folder on the cache drive. That is enough to cause the share to show as unprotected. The diagnostics definitely show that something related to appdata is on the cache.

Encryption is irrelevant to this as parity runs at the physical sector level. Unraid will go straight into clearing a disk when you add it any time it does not recognise a ‘clear’ signature as being present on the drive.

My suspicion is that this is something within Windows. I get exactly the same symptoms on real hardware (UDOO x86). Hyper-V used to work on this hardware but sometime earlier this year one of the Microsoft updates broke it and I get your symptoms. The UDOO can still quite happily run VMs under VirtualBox, just no longer able to run them under Hyper-V. I find this also means that I cannot use WSL2 on the UDOO - trying to enable that causes the same symptoms. Be interested if trying to activate WSL2 causes the same symptoms on your VM.

Unraid does not need to do anything to parity when you add a 'clear' disk as since it is all zeroes it does not affect parity. It is at this stage that you tell Unraid to format the disk (which only takes a few minutes) and as you format the disk (which is a form of write operation) then Unraid will be updating parity to reflect this format operation.

I must admit it is not absolutely clear to me whether you really mean a cache pool or the main Unraid array. For a cache pool you can use this site to work out the available space for various combinations of disk in the pool together with particular btrfs profiles For the main array the available space is simply the sum of the data drives.

It is not unknown for USB enclosures to report the disk geometry slightly differently to the way it is reported via a direct SATA connection. If this is the case that is being encountered then the drive will need to be reformatted from Unraid.

Do you have the USB stick set up to support legacy boot or UEFI boot? If UEFI boot is enabled their will be an EFI folder rather than a EFI~ (i.e. no trailing ~ character) - you can always simply rename it if necessary. The symptoms suggest it might be trying to boot in the wrong mode. I do not know why the USB Creator tool does not always leave both options enabled as standard.

Looks like version_compare() is a standard PHP function that does what I want.

does that work correctly for detecting that 6.9.0 (i. e. stable version) is greater than any beta or rc release and rc releases are greater than beta ones? I had not thought of doing it that way so maybe I should try it to see as it is a very simple way if it works. Since I do not intend to release this new feature until 6.9.0 beta 36 (or later) is released I could probably get away in practice in just checking for the 6.9.09 part of the release info, but I thought the question war worth asking anyway.

To save me writing my own I was wondering if there is a standard PHP routine in Unraid that I can use to check that the Unraid version meets the requirements for a new feature I am adding to a plugin (needs to be Unraid 6.9.0 beta 36 or higher). Ideally this routine would handle both stable and next type releases. It feels like a routine that may already be present somewhere if I could just locate it

If you assign a drive to a parity protected array then the first action that Unraid will take is to ‘clear’ the drive (by writing zeroes to every sector of the drive) to keep parity valid. This will erase any existing content and leave the drive ready to be formatted to the file system you choose (auto means use the default setting). From your description this is what has happened.

Yes if you want to change the parity drive back to parity1. The alternative is to continue with parity2 and without parity1 in which case it will not need resending.

With appdata set to Use cache=only any files belonging to appdata that are on the array will be left there as mover ignore any shares where Use Cache is set to ‘only’ or ‘no’.

How did you add the drive after moving it? It should have showed up just fine in Unassigned Devices with its data intact. If you tried to add it to the array or to an existing cache pool then the data could well be lost as those actions expect the disk to not contain any data you want to keep.