JonathanM

Not conclusively, but it's good to be prepared for the worst.
 
After you are satisfied you have done everything you can do before the inevitable, stop the array, then power down. Doesn't really matter if you use the shutdown function of Unraid or just kill the power, as long as the array is stopped before you kill it.
 
Then put the USB drive in another machine and see if it's readable. If so, make a copy of the config folder immediately. If it's not readable, even after a checkdisk, then proceed with disaster recovery.

Set a new config in tools and put all the drives back the way they were.

No, but only attached devices at array start count towards the license, so you could start the array, then attach the drives using Unassigned devices.
 
Why not just do the normal method of replacing the current drives one at a time? Then the removed drives would be an exact copy, so if something goes wrong you have a full backup.

If the error checking and correcting algorithm built into the failing hard drive was working properly (and it should be, the probability of a media error being reported correctly but handled incorrectly is exceedingly small) then when data was sent to the drive, it either wrote properly and returned a success, or it failed the write and returned a fail. When Unraid gets a message from the drive saying a write failed, the drive is immediately disabled, and all further writes will be only committed to the parity emulated drive. Drives are smart though, and when a write to a bad sector fails, it's not immediately tossed, it marks the sector as pending and writes to another sector instead. It's only if the drive is incapable of writing the data that it fails a write.
 
If in the future a sector fails a read, first the drive tries again a BUNCH of times, and if it fails, it sends that to the OS. Unraid records that failure, calculates what should be there from the parity equations, and writes the data back to the drive. If the drive is successful in writing the data, Unraid continues as normal, and the only indication you get is an extreme slowdown and the error counter incremented in the Main GUI. If the write fails, see above.
 
So, the tldr is, your data is fine.
 
The drives themselves provide that protection by reporting back when data is unable to be read or written correctly. Parity provides the safety net when the drive gives up.

Is the modem configured as a router? It may only be handing out a few IP's with valid addresses until it refuses any more assignments.
 
Maybe your WAP system has one or more of those routable IP's and is handing out the private 192.168.86.X addresses to the WAP connected clients.
 
Do your WAP's have multiple ethernet ports? Maybe try plugging an ethernet cable there?

Make a backup copy of both flash drives.
 
Overwrite the config folder with the other drive. Put the license key file back with the drive it goes to.
 
The license key needs to stay with the physical flash drive, the rest of the config folder gets moved over.

Make a copy of the old usb key to another machine.
 
Do this again, but use the old usb key instead of a new one.
 
Copy just the config folder out of your backup to the old USB key.

It's the percentage of the docker.img file that is in use. If it starts growing rapidly that usually means a container is not configured properly. If it's been close to that figure for a while and is slowly increasing a little only when you add new containers, it's probably normal.
 
With the docker service stopped you can increase the size of the image file, but don't just increase it if you can't point to a reason it's getting larger, if something is configured incorrectly just making the image bigger delays the inevitable troubleshooting.
 
It's got absolutely nothing to do with RAM.

Depends. If the error count stays the same, then you are probably fine. If it keeps increasing, I'd return the disk for a new one. Don't manufacturer warranty return it if possible, the drives you get back from a manufacturer warranty swap are typically refurbished. Return it for credit and get a new one if possible. If the count stays at 11 and never increases, I'd keep the drive.
 
Regardless, you always need to be alerted to changes in disk health, you shouldn't need to wait until you log back in. Make sure notifications are set up and working. You should be getting a daily "everything is OK" notification so you know the server can contact you with errors.

Try changing the base folder to /data instead of /config

??

Depends on whether you want to continue using the data while the rebuild is happening. If you do it in maintenance mode, you can easily put the old drives back.
 
If you want to continue to use the server during the swap, the safest way would be to do one at a time.

The Unassigned Devices plugin will do exactly that.

https://docs.unraid.net/unraid-os/troubleshooting/data-recovery/#unmountable-disks
Whatever you do, DON'T format.

Should work fine. I have several VM's all assigned to the same GPU, and it works great.
 
If the GPU is otherwise occupied when you try to start a VM, I'm pretty sure it will just kick an error and not start. I haven't tried it though, didn't see a point to purposely trying to break it.

New config references the parity disk, it allows rearranging array data disks and recalculating parity based on the new arrangement.
 
It doesn't erase any data disks, only the parity disk(s).
 
If you want to wipe a disk, you need to format it, the easiest way to do this in the Unraid GUI is to click on the disk and change the desired format type, start the array, and select the format button after making sure only the disks you want erased are listed and checking the "Yes I want to do this" button.
 
Array disks can't be trimmed, typically you would use various pools for SSD's. Currently Unraid requires disk1 in the array to be populated to start, so you can use any old USB flash drive as disk1.
 
You can assign specific duties to various pools.

Why not just replace the two disks one at a time and let them rebuild from parity?

Split level overrides high water, so if the copying method creates empty folders and then fills them, the allocation method won't be applied.

If the stock scheduling doesn't give you the flexibility you need, maybe look into the tuning plugin?
 

Dynamix File Manager

There may be other ways, but the quickest way I know is delete and recreate the docker.img file.
 
Be sure to create your desired networks BEFORE going to previous apps and selecting everything you want to reinstall. It should only take a few minutes, and everything will be back the way it was.

I don't know if the time being wrong will give that error, but try setting the BIOS time to GMT.
 
You should be able to save the diagnostics zip file to the flash, shut down the machine, then attach the zip file to your next post here.

https://docs.unraid.net/unraid-os/manual/upgrade-instructions/#manual-upgrade-or-downgrade

At this point you may as well format the drive and write your backup to it, run the make bootable, and see what happens.
 
If it gives you errors while formatting or writing your backup to it, proceed with a new drive.

Set up a new VM, get it running to your satisfaction, then add the corrupt vdisk as a second disk to that new VM.