itimpi

What browser are you using? There have been some reports that suggest using a different browser can work.

actually the steps in the online documentation for replacing a data disk or a parity disk after failure are identical. Perhaps it just needs to be made clearer that they apply to both types of replacement.

No, one flash drive as a data drive and no parity drive. You have to have at least one data drive for unRaid to be able to start up the services and pools.

Then I am afraid you are out of luck as there is no mechanism for un-blacklisting USB sticks.

You might still want to add appdata to the folders to be ignored as even with User Share scanning disabled the folder will still be found and scanned when the drive contains that folder is scanned.

Not sure that is a bug as you bypassed the GUI. The web GUI disk status is only updated at the interval set under Settings -> disk Settings -> Tunable (poll attributes) which defaults to 1800 seconds (30 minutes). I tend to reduce this value on my own system to something like 180 (3 minutes).

Not disagreeing - just pointing that most of what you mentioned is already covered in the current flash backup capability. I do not see any reason why at least the .xml files for VM definitions should not also be included in that zip file as they would be very small. Not sure if there is anything else VM configuration related that should be included? Obviously the vdisk files and iso images would not be part of such a backup.

a disk gets disabled (Red Cross) if a write to it fails for any reason. The write failure can be a genuine disk issue or a transient issue such as cabling or a power glitch. The only way you get the disabled state is to rebuild the disk (to either itself or a spare drive). The steps to follow to achieve are covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the unRaid GUI. in your case since you have a spare drive you can go either route. I would be tempted to use the spare drive as this would be good practice for what to do if you have a future drive failure while keeping the contents of the current ‘disabled’ drive intact just in case any problem arises building onto the older drive. If the rebuild finishes with no problem you can then put this drive through some tests using either the preclear plugin/docker or the manufacturers test software. That would give you a good indication if it was a genuine disk problem that caused the disk to be disabled so it is a RMA candidate or a transient glitch so you just keep the drive as the new spare.

If you are trying to sort out the lost+found folder then the Linux ‘file’ command can be used to at least tell you the content type of the files that have lost their name. if you have decent backups it is often less effort just to recover files from there.

No - rebuilding parity only writes to the parity disk (and reads from the data drives).

Step 7 is redundant as building parity is going to overwrite every sector on the disk anyway. Yes it can be done (but ask for the details if you need to do it) as long as no new data has been written to the array.

Other than the VM settings all the other information is contained in the config folder on the flash drive and this is part of the zip file created by the built-in unRaid flash backup tool.

that sounds like an error trying to read the flash drive during the boot process. You do not mention if unRaid even starts the boot process? I would suggest plug the uDb stick into a PC/Mac to check it can read it OK make a backup of the USB drive contents while you are there onto the PC/Mac downloading the zip file for the release from the Limetech site extract all the bz* type files from the zip overwriting the ones on the USB drive put the USB drive back into the unRaid server and see if it now boots OK.

Do you mean new unRaid keys or simply new USB sticks?

Have you made sure that the array is set to autostart under Settings -> Disk Settings

It has been known for some time that updating via the GUI tends to fail on 2GB systems - you really need 4GB for it to be successful. It would be a good idea if the upgrade script issued a warning about this. There also might be possible to make changes that means less RAM is used during the upgrade process - I think currently the zip download is unpacked into RAM before being written to the flash drive.

No reason you cannot run them on multiple drives at the same time. The main thing is to not be trying to read or write to the disks while the test is running as this can interrupt the test.

@Nathan Richardson handling of unmountable disks is described here in the online documentation accessible via the ‘Manual’ link at the bottom of the unRaid GUI.

Have you cleared the browsers cache? I seem to remember this being the fix for such an issue in the past.

according to the screenshot the update failed but it gives no indication as to why

Yes

The 'find' command is almost certainly the Folder Caching (Cachedirs) plugin doing its initial scan since you have just rebooted. You probably want the appdata share to be excluded as if you have something like Plex installed it can contain millions of files.

If the repair against the emulated drive has worked and you can now see all the expected files on the emulated drive then what you do is follow the process for rebuilding the physical drive (to make it match the emulated one). Only if the emulated drive does not look correct do you want to consider any alternative action.

Handling of unmountable disks is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the unRaid GUI.

Using the ‘df’ command from the unRaid command line can be useful to see what paths have what mount points and their type and therefore are not necessarily in RAM