trurl

That address always only refers the local machine, so you can't use it to access another machine on the network. should be the network IP of the server This sounds more like an issue with the BIOS not trying to boot from the correct device.

It is very important that you not assign a data disk to a parity slot or the data will be overwritten by parity. If you don't know which disk(s) for parity then don't assign any to parity.

Why? Dockers/VMs will perform better and not keep array spinning if you put them on cache.

gui mode is the same web interface you get when accessing from a browser on another computer. If you boot in GUI mode then that web interface will display your IP in the upper right of the page. Or you can look at the output of ifconfig to find the IP address. It shouldn't be very hard to pick out. It is 4 numbers separated by . (period), like 192.168.1.64 or 10.1.1.2 etc.

What did you mean by this then? gui mode is the webUI.

Tools - New Config, assign disks, when you get ready to start the array check the parity valid box

Do you know which drive(s) for parity?

Are you also?

Or if in webUI, it should show your IP address at upper right.

What do you get from the command line with this? ifconfig

You could try copying just the config folder onto a new install. The config folder has everything about your configuration. Instead of relying on you should always keep a current backup of flash. You can download a zipped backup of flash at Main - Boot Device - Flash - Flash Backup

Is the volume name for the flash still "UNRAID"?

Maybe this will clarify. In addition to the original cache pool named "cache" (2x500 btrfs raid1), I also have a cache pool that I have named "fast" (1x256 xfs). Each user share has an additional setting to select the cache pool for that user share. In this screenshot, I have selected my "fast" pool for the share named DVR with Use cache as Prefer so it can overflow.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post.

Not only does it control the mover, but it controls which pool new files get written to. There is no way to have an individual user share set to use multiple pools. Like any user share, if files for the share (top level folder) exist on multiple pools, then those files would be included for any reads. But for writing new files and mover, only one pool can be selected per user share.

Or you can set up gmail Notifications on your server with an "App Password": https://support.google.com/accounts/answer/185833?hl=en

If your boot flash is showing up in Unassigned Devices it has already disconnected. Make sure you are booting from USB2 port.

You should set Minimum Free for each user share larger than the largest file you expect to write to the share. If a disk has less than minimum, Unraid will choose another. For example, you set Minimum Free to 10GB. A disk has 11GB free, so it can be chosen. You write a 9GB file to the disk, and so it only has 2GB free after and will not be chosen again for writes to the share since it has less than minimum. Another example. Minimum Free set to 10GB, disk has 15GB free, so it can be chosen. You write a 20GB file, and the disk runs out of space and the write fails. Cache also has a Minimum Free setting in Global Share Settings. If cache has less than minimum, cache-yes and cache-prefer shares will overflow to the array.

You should always keep a current backup of flash. You can download a zipped backup of flash at Main - Boot Device - Flash - Flash Backup. You should get a new backup anytime you make any changes you don't want to lose. It is especially important when you make disk assignment changes.

Unraid has no way to know how large a file will become when it chooses a disk to write. If you expect to write a file larger than cache then don't cache the share.

There are utilization thresholds for each disk/pool. Have you set up Notifications?

As long as you haven't reused a parity disk as data, then you could probably use that backup. There have been cases where someone used an old backup that said one of their current data disks was (still) the parity disk and so it began overwriting the data with parity. Prepare new flash as a new install. Put config folder from your backup on the new flash. Edit config/disk.cfg to set startArray to no. It may not let you start until you get a new license .key file anyway but I'm not sure. Boot up and report back.

Now that you may be infected, just closing incoming ports may not be good enough until you get rid of the infection. You should shut down the server completely until you are ready to boot it from a clean install.

Since all those IoT embedded OS are some linux flavor and your Unraid is also some linux flavor, it is conceivable that your server is infected. The good thing about Unraid is the OS is only in RAM. A boot from a clean install should take care of it, as long as you don't keep any executables from your data drives, such as dockers and VMs.

Parity is the same wherever it is used in computers and communications. Parity is just an extra bit that allows a missing bit to be calculated from all the other bits. Whether RAID or Unraid, parity is just extra bits that allow the bits of a failed or missing disk to be calculated from the bits of all the other disks. Since it is just an extra bit with no information about any disks, there is no way to know which of the bits is out-of-sync. Something that sometimes happens with a read error. Unraid will get the failed read data from the parity calculation using all the other disks, then write it back to the drive. If that write-back fails then the disk gets disabled just like any failed write.