itimpi

Almost certainly as in Safe Mode no plugins are installed.

You would have been fine if you had omitted the ‘format’ step. When you selected the format option you would have got a big pop up that doing so would result in data loss - did you not read this or was the warning not clear enough?

Did the files show up before the rebuild started on the ‘emulated’ drive? A rebuild just makes a physical drive match the ‘emulated’ one. if the drive is showing as unmountable then this is not ‘fixed’ by a rebuild. That status indicates file system level corruption and the procedures to follow to fix that are documented here in the online documentation accessible via the ‘Manual’ link at the bottom of the Unraid GUI.

Do NOT format disk3 unless you want to lose all its data. The format operation would create an empty file system on disk3 and update parity to reflect this. I assume at this point the system says it is 'emulating' disk3? If that is so then you need to follow the procedure for handling unmountable disks as documented here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI to see if you can successfully repair the file system on the emulated disk before attempting any rebuild. Post back here if that does not work. You can then clear the disabled state on the disabled disks as described here in the online documentation. Not sure if you can rebuild both a parity disk and a data disk at the same time or have to do it in 2 stages - hopefully someone else can chime in with the answer to that.

When you log in at the console and use the ‘df’ command do you see the flash drive mounted as /boot ? If not then that would mean that the flash drive is not being found in the latef boot stages, and would also explain why diagnostics were not saved.

They load into RaM during the boot sequence, so as long as they do not later need anything off the flash drive they are OK. If you simply redid the flash drive and put the licence key file for the flash drive into the config file it should show as already licensed. Not quite sure from your description what you actually did.

As far as I know that is not possible as all configuration information is stored on the USB that you said you have just wiped. I am surprised that UnRaid has not started behaving erratically with the flash drive contents gone. do you have any backups of the flash drive? If it is on the array now would be the time to copy it elsewhere.

No sure what could be your problem then,as,the,process normally ‘just works’. It might be worth checking again as I see from other forum posts that there was a problem with the key server for a short period . if it is still not working you could post your system’s diagnostics zip file (obtained via Tools->Diagnostics) to see if we can spot what might be the issue.

Do you have any devices attached to the server that are not being used by Unraid? Your screen shot cuts off too early to see if there is anything under Unassigned Devices. All storage devices attached to the server are counted even if they are not being used by Unraid as far as the licence is concerned. It is worth noting that the check for the number of attached devices is carried out each time the array is started, so it is possible to plugin in removable devices while the array is running for purposes such as backups but they would then need to be removed if you ever reboot the system to allow the array to be started again without exceeding the limit. In such a scenario I think most people cannot be bothered to have to worry about whether such devices are plugged in and so go for licence that allows for a higher limit on the number of attached devices.

This last screenshot looks like what I would expect to see with a parity rebuild that is proceeding satisfactorily

That screenshot is showing a lot of errors was it taken before you started the parity rebuild as if not then you still have a problem to solve.

I would do neither of those Since you are on UnRaid 6.9 you can have multiple pools so why not simply create another pool for Plex?

I have never had any problem with 1). As was suggested try the Manual method for creating the USB drive, or failing that try a different PC/Mac.

Looks as if your diagnostics appear to be shortly after booting and not taken while you were exhibiting the problem? Regardless, they are enough to show that you have file system corruption on disk7 so you should put the array into maintenance mode and the click on the drive on the Main tab to run a file system check and repair.

Not really - it is the USB factor. Unraid does not function well if the connection to the disk is not rock solid as it is not 'hot-plug' aware and cannot handle momentary disconnects which is something that USB drives are prone to. Note: The UD plugin CAN handle non-array drives connected in this way.

You would need some device to be running a valid gateway on the 192.168.1.x subnet to be able to route between them.

Unraid does not implement what is normally meant by RAID0 (and hence the name). Unraid will never have the performance of a more typical RAID system for a number of reasons Each array drive is a self-contained filing system and so files cannot span drives and striping cannot be used. Reads are therefore limited to the read speed of any drive involved in the read. For writes Unraid updates parity in a completely different way to a standard RAID system which leads to significant performance overhead. The techniques used for Reads and Writes are described here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI. If you want to use Unraid with performance as the main criteria then you should not use the main array for the data but instead look into use Unraid BTRFS pools as these operate more like a traditional RAID system.

CRC errors are rarely actual drive problems. They are connection problems and are typically related to the SATA or power cabling. Normally they will just cause a retry of a read or write and as long as that succeeds no error is reported (although the retries can downgrade performance while they are taking place). It is also worth noting that the CRC count can never be reset to zero - you only know that there is no issue remaining if the counts remain stable.

Have you checked there are actual files still on the cache? It will never get down to zero space used as some space is always used to store file system control information.

If you are using UnRaid v5 then the file system type must be reiserFs and the tool to use is reiserfsck. On v5 it needs to be run from the command line.

I believe that mover tends to process shares (and their contents) in alphabetical order.. There was probably not much spare space when it started on appdata and do nothing got moved. You say it is currently moving data off the cache for the ‘homeserver’ share which is freeing up space? The ‘appdata’ share seems to be bigger than the cache can hold which is not a good scenario to be in - any idea why it is that huge? it is also worth mentioning that the ‘system share contents can normally only be moved if the Docker and VM services are stopped as these hold files open and open files cannot be moved.

You can do it from the GUI by clicking on the drive on the Main tab. For XFS file systems the array needs to be running in Maintenance mode while BTRFS is done from normal mode.

Look like you had multiple disks drop offline simultaneously. I would suspect that you have some sort of hardware related issue. Since a parity check is when the system is under maximum load it could be power related. Other possibilities that spring to mind are something more obscure like an improperly seated HBA.

Looks like you have file system corruption I would suggest running a file system check/repair on all your drives.

Why would you expect these to be moved? The ‘prefer’ setting tells mover to move the share contents ONTO the cache if there is any room.