JonathanM

https://forums.unraid.net/topic/113184-why-ecc-is-so-important-on-any-system-working-with-data-you-care-about/

So this keeps happening I know for a fact that all 4 cores are running wide open, on purpose. Sometimes the dashboard reporting works for a while after a restart, but this specific machine just loses the plot after a while. It's a rather old box, so probably some stat is reporting strangely and breaking the maths. I'm not planning on troubleshooting or doing anything proactive to deal with it, just making a note here. I found it amusing that my processor was doing infinite %. It's had this same behaviour across 6.9.2 and 6.10.0 rc2

Are you forwarding anything to the outside world? In the past, there have been instances where the GUI or console was accessed remotely and servers were getting hacked or shut down.

That's how parity works. When a drive is disabled, it emulates whatever is was on the disk, file system inclusive. You need to click on disk1 and change the desired format, then format the drive after you start the array. Any changes you make to a drive NOT currently in the array will be overwritten if the disk is used to rebuild a valid array slot. Did you read through this thread that you replied to?

Easiest way I know is to set up a second linux VM, Mint is a good choice for windows users, and temporarily add the target VM vdisk as a second vdisk on the new VM. Then you can use gparted which is a GUI partition manager to do whatever you want.

Formatting doesn't touch 99.9% of the drive, it's just adding the book keeping section. Clearing, on the other hand, writes binary 0 to the whole drive, which as you noted, takes quite a while. Think of a hard disk like an empty room. Sure, you could just throw some pages of a book in the empty room, and you could search through and eventually find what you wanted to retrieve, but a nice set of filing cabinets with labels sure would make things easier. Formatting is the filing cabinet system. It takes up space, and a little bit of time to set up, but it adds the features needed to store and retrieve files. You set up locking file cabinets that require your encryption key to open. BTW, if your file system (filing cabinets) ever gets corrupted by bad RAM or a crash or something (somebody takes a sledge to your file cabinet index) the fact that you added encryption makes recovery pretty much impossible. The normal advice to make sure you have backups elsewhere of anything important applies double. Unraid's parity protection will recreate a drive exactly as it was when it failed a write operation, and that emulated recreation is the entire drive, file system included. If your file system gets corrupted, Unraid will happily recreate that corruption to a new drive.

Has it always been actively cooled? Server grade parts expect lots of airflow, sometimes when they are used in normal desktop style cases instead of rack mount, they need a dedicated fan.

From what I see, it's not actually bad yet, just written so heavily the manufacturer thinks it's close to wearing out. I'd hesitate to call it "safe", but I'd personally use it for low value data like transcoding temp space as long as the speed was still ok.

First and possibly most important, when you change the filesystem from reiserfs to XFS, ALL THE FILES WILL BE ERASED. Since you have a little over 1TB of files still on the reiserfs file system on the parity emulated disk1, I'm assuming you don't want them erased. Parity emulates the entire drive, filesystem inclusive, so rebuilding a drive from parity will always rebuild the same filesystem. IF YOU FORMAT THE DRIVE WHILE IT'S IN THE ARRAY IT WILL BE BLANK. Formatting an array drive updates parity with the new filesystem. Parity doesn't emulate individual files, it emulates the entire disk. So with that out of the way, apparently you are running a read check of the array instead of rebuilding disk1. Cancel the check, stop the array, change disk1 to none, start the array, stop the array, change disk1 to the correct disk. This should rebuild your reiserfs file system as it's being emulated currently. After the array is healthy and all green, then you can copy the files off disk1 to disk2, when that is done change the format of disk1 to xfs in the disk1 properties and it should prompt you to format it. Then you can copy the next reiserfs disk to it, lather rinse repeat until all drives are xfs. I'll repeat myself for emphasis. Changing the format of an array disk will REMOVE all the files currently on it. There is an entire sticky thread on migrating from reiserfs to xfs, perhaps that would be a good read while disk1 is rebuilding from parity.

Yep, new config. Take a screenshot of your drive assignments on the Main tab before you start, just in case things get shuffled. You will be rebuilding parity, so don't even start this unless you are sure all your disks are healthy. After you apply a new config with the preserve all option, you go back to the Main tab and make your changes. I'm assuming by the way you worded this that you do not have enough physical slots to have the SSD attached until you physically remove the old drive. If that's the case, you can do the new config after you power down and physically swap the drives. Probably best if you set the array not to start automatically in the disks settings and then set it back after everything is happy.

But plugins run as root anyway, so nothing has changed? Unraid is extremely vulnerable in one sense, as a malicious plugin can do damage regardless of this exploit. I'm just not seeing how this exploit changes Unraid's exposure.

How would this specific exploit work in Unraid? Unlike typical linux installs, ONLY root is allowed console login, so no privilege escalation attack from that vector, right? Since Unraid operates so differently from normal setups, I'm having a hard time picturing how this effects us.

Do you have a flash backup? The flash drive has your saved templates. The appdata and docker.img should still be where you left them, but without templates it's a little more difficult to get them running unless you remember any deviations from the standard template that was downloaded with the container.

Tools, new config. That will allow you to place the drives in any slots. BE ABSOLUTELY SURE you are not assigning a data drive to the parity slot. TRIPLE check.

Looks like your media mapping is pointing to a nonexistent location on the array. Typically it would be something like /mnt /user/movies on the host side.

Odd numbers of cache devices don't always report free space correctly. I believe it looks to be correct in the diagnostics, @JorgeB will know for sure. Try copying a couple TB to it and see what the btrfs stats say on the cache page.

Did the rebalance finish that quickly?

Which device did you target? The sd(x) designations are subject to change on reboot, so be sure you are specifying the correct letter for the device you want to erase, otherwise you easily could erase a drive you didn't mean to.

From the manual linked at the bottom right of the webGUI https://wiki.unraid.net/Manual/Storage_Management#Change_Pool_RAID_Levels

Not currently.

By default Unraid will use RAID1, which if working properly should give you 2TB of usable space. If you want 4TB usable, you need to rebalance to RAID0 after the pool is healthy. https://carfax.org.uk/btrfs-usage/

Have you set a new battery date in the UPS firmware?

AFAIK, cancelled Unbalance operations will ALWAYS create dupes. Solution? Either don't use Unbalance, I can't think of a situation that REQUIRES it, or make sure each Unbalance run is completed successfully, and clean up if it's not.

When the internet goes out, I still want access to my stuff. Requiring an internet connection to start my storage server is a HUGE nono. Internet is still a fickle thing in some parts of the world. I'm glad you are privileged enough to not have to worry whether the internet is down, but you are not considering what life is like for us peons with spotty internet. If you have no concerns about losing internet, why even bother with local storage? Just stream everything.

Frank has a really good point. I would not add all the disks at once, rather a staggered strategy, where you replace the worst of the old disks as you actually need the free space. Every time either a. any disk shows signs of weakness, or b. total array free space dips below 6TB, I'd replace a disk until both a. and b. are no longer an issue. That way, at least the new disks would have a varied amount of time and use, and if you got a dud among the 6TB's, you could immediately replace it with the next 6TB in your stack of spares. It's always a good idea to keep 1 good drive the same size as parity or larger in your back pocket as a ready spare, and replacing known good drives with unknown new drives when you don't need the space is adding risk you don't need. Another point to consider is possibly lowering your spindle count, but that is risky with Unraid, it's not really designed with drive removal in mind so you have to do some gyrations to accomplish it without losing parity protection for the duration of the removal.