JonathanM

See if you can get in to the BIOS and check the boot order.
Soiunds like you disturbed something when you were in the case.

Yes. Set the secondary storage to array, and the mover direction from array to cache.

How aggressive or conservative do you want to be? Do you have backups of irreplaceable stuff if the file system repair doesn't completely work?
 
You can continue with the repair by running the same procedure, remove the -n and replace it with -L, or you can remove the disk and allow parity to emulate and rebuild the filesystem in its current corrupt state on a new drive, and keep the current drive to operate on with more advanced file recovery software.
 
If you want more than one bite at the apple you need to make a copy of the corrupt drive before you attempt more repairs.

If the utilization keeps growing even though you haven't added any containers, this may help you figure out what's going on.
 

Your current layout of 2 spinners and one SSD is typical.
 
If you are only using it for bulk storage, you don't need SSD, but if you want to run containers and VM's, it's pretty much a necessity unless you are prepared for a severe drop in performance.

Standard replace will work.
 
Why do you want such a large parity disk when all but the first 1TB will be unused? Parity only needs to be equal or larger than any one of the data disks.

Copy everything to Unraid, leave workstation alone for the moment.
 
Get everything sorted in Unraid the way you want it, leaving the workstation as your local backup while you play. Once you are satisfied with the way Unraid is handling your stuff, then you could move all the drives over, and add them as data disks, leaving the 10TB as is for the moment.
 
At that point you have a choice, copy the files to the various 4TB drives, verify the copy was successful, then set a new config with all the 4TB drives as data drives and the 10TB as parity,
OR,
and this is the better option, add another 10TB as parity and leave well enough alone with just the 10TB data disk for now.
 
Are you familiar with all the different storage setups that Unraid supports? The main reason I suggest copying then leaving the workstation off for a period of time was to allow you a "do over" period if you find out you want to set up Unraid differently. It's a whole lot safer to play around and change things while you still have all your data locally backed up on your workstation.
 
This would be an ideal time to get your local backup situation worked out, maybe sending versioned backups to the workstation instead of tearing it down.
 
Keep in mind that Unraid (or any redundant RAID) is NOT backup, it's only good for a small subset of things that can nuke data. Hardware failure is far less common than accidental deletion or worse, overwriting, or file system corruption.
 
Now is the time to spend your energy getting local backup sorted.

Keep the license key file with the physical USB, keep the rest of the files in the config folder with the hardware.
 
If you need more clarity, ask.

That is usually a cable issue, not a drive failure. Make sure the cables aren't under tension, ideally if you theoretically removed the drive without disturbing the cable the cable wouldn't move.
 
I'd run an extended SMART test, then check the SMART report to be sure. The long test will take MANY hours.

You MUST load test to find that out. Batteries can (and often do) fail in a state where voltage is normal during charging, but as soon as a load is applied, the battery falls over almost immediately.

You need the key file that was issued for the new flashdrive. Did you happen to make a backup? If you can't find it, you will need to contact support and ask them to send you the file. Did you possibly get an email with a download link for the new file?
You need the key issued when you did it the first time.

Many BIOS's have three states for power on. Always on, Always off, previous state.

Try setting export to yes.

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.