JonathanM

@mgutt?

Shouldn't matter.

I'm not saying for sure it's the motherboard, but that's where I'd start my investigation from where you left off.

Have you tried a different motherboard? The board is in charge of changing the power state from standby to on, the PSU only supplies minimal power to the board until one of the PSU pins is held low, so if the motherboard doesn't hold that pin low, it will power off. You can test that theory with a cheap PSU tester that plugs into the motherboard connection, one similar to this. With the tester plugged in, the PSU's should go to full on and stay that way as long as there is AC. (image stolen from a quick search)

If the disk is working properly, it won't happen. However... the situations that call for permanent erasure are often when a disk is no longer working reliably. If the software based erasure isn't reliable, the procedure must be escalated to physical destruction. If you like playing with powerful magnets, orderly disassembly is recommended, followed by shattering the platters. If you don't have time for that, 5.65 or larger orifices through the platters is satisfying and quite reliable.

This is the replacement option, it remains compatible using mostly the same base code. Read the first post.

You can select multiple erase passes with the preclear plugin that write random data to the drive. As many passes as you feel safe with, and as an added bonus you can do a standard clear with verification, which gives you confidence that the final write was actually honored and not a placebo where the write was accepted but the subsequent read still returned old data.

The existing preclear plugin for Unassigned devices does a good job of erasing drives, with the added benefit of ensuring that the final pass actually was written correctly.

Have you tried nomachine?

If you don't rebuild, the physical disk will not be part of the array, all reads and writes will still be happening on the emulated disk and you will remain unprotected from another disk failure. The physical disk only has the data on it from the instant before the write failed, all subsequent writes are only on the emulated copy. So, at this point, you have 2 different sets of data, 1 that is actively being read and written as an emulated drive in the array, and 1 that is on the physical disk that stopped being updated when the write failed. Normally you want to use the current set of data, and write that to a physical disk, either the original physical disk that was in the slot or a new disk, depending on the condition of the original drive. In some circumstances if parity was not in sync when the write failed, you can end up with the emulated data being corrupt, in which case you should rebuild to a new drive to attempt data recovery on both the original drive that was kicked out of the array and the emulated copy written to the new drive and see which copy is most correct. The parity emulated disk is being reconstructed on the fly by reading all the remaining drives, and you need to commit that emulated data to a physical disk, rebuilding it and getting the array back in sync so it is once again fault tolerant.

Exactly. Did you read the link for syslog server? It details how to get the logs from before the shutdown event, as the logs are normally lost on restart because they are in RAM.

This is going to be an issue for any device on the network, as both routers are advertising their services and any device looking for a DHCP address is going to find whichever router responds first, and when the DHCP renewal period expires it may well switch to the other network. Do you have multiple full time WAN connections available? Or is the security modem supposed to run off the main internet and fall back to a cell provider if the main WAN is out? If that's the case, then only the security system itself should be connected to the LAN side of the security modem, and the WAN side should go to the LAN connection of the main internet. Bottom line, you need to get this working properly or it will be an ongoing issue, and depending on how things are configured you may get a nastygram from your security company about the use of the backup network for things other than the security system.

http://usbip.sourceforge.net/ There is a plugin to manage it at the Unraid end.

At the SSH prompt, type powerdown When the server shuts down, remove the flash drive and put it in your computer and open the logs folder on the flash drive. Attach the zip file as it is to your NEXT post in THIS thread.

How is your backup situation? If something goes south during this operation, can you retrieve another copy of anything important? With single parity, you are already running on the ragged edge of data loss, since you are emulating the dead drive with a drive showing smart errors. Whether or not you have a second copy of your important data determines how I personally would proceed in your situation.

Direct quote from the link. Can you attach a screen and keyboard to the server? Can you ssh in to the server's IP?

When you add a data disk, it will be cleared before it is added to the parity array so it doesn't alter parity until you format it and start adding data. So, no rewriting parity required when ADDING disks. Removing a data disk, that's when parity will be redone from scratch.

Removing a parity disk and assigning it as a new data drive is easy. Doing the opposite is way more complicated. Yes, you can remove files from a disk, and use it elsewhere or as a parity drive, but removing a data drive means recalculating parity from scratch, or going through an involved process to keep parity valid before removal. Adding a data drive to Unraid is easy, removal is more complicated.

Nope. Each parity disk is different, and uses the remainder of the data disks to rebuild 1 bad data disk. So, 2 parity disks allows rebuilding 2 different data disks. It's complicated, but just keep in mind parity doesn't hold any of your data, it only completes the math using all the rest of the data drives needed to reconstruct a single failed drive. The math used on parity1 slot is different than the math used for parity2.

That's a standard switching UPS, it keeps the batteries charged on standby, but passes line power through unless it detects an anomaly, and then it switches to battery power. Totally different concept than I'm not saying that's the cause, but it wouldn't hurt to take it out of the circuit long enough to test, IF your power is generally stable. If you have flaky line voltage, then you need to test with a different UPS to rule it out as being the cause. Constant "online" UPS tend to be rather expensive, and are used for critical applications like medical equipment and such. A good switching UPS with AVR should be sufficient for typical electronics. (Disclaimer, I personally have 3 2KVA online UPS running all my household electronics, because I got them at a surplus auction and I like overkill.) Software is not normally capable of cutting power on the main board without an event being logged, the only exception I can think of is IPMI control.

Justify coders salary.

Tools, diagnostics. Without that, my best guess would be low level format, 520 sector size instead of 512.

Looks like this (and the source script) only work properly if there are no pools with names other than cache. That USED to be the case, but with the advent of multiple cache pools, there is no guarantee that the cache pool will even be named cache, it can be user defined, and there can be more than one. So, if you have a single cache pool named cache, it should work as planned. Otherwise, it looks like it will ignore any other cache pools. I could be reading this wrong though.

It's not. It allows you to keep existing data on any assigned data drives while rebuilding parity based on those drives. When the array is started are there any drives without the green indicator? The error message you are getting is an indication that Unraid already had a drive emulated before you tried to replace the 40GB drive, and each parity drive can only emulate one failed or removed drive at a time. All remaining data drives must participate in the reconstruction of a single (or double with 2 parity) drive. Post a screenshot of the main GUI with the array started, and attach the diagnostics zip file to your next post in this thread.