garycase

+1 on this feature ... definitely an improvement over closing the notifications individually.

Agree.

Agree. Hopefully in the future frequent security updates will be the norm and this situation won't recur. If not, we'll be in the same situation when 6.2 is ignored while 6.3 is being developed; etc. As for RC5 "within a week" => as always, my vote is for ensuring it's right rather than pushing for "quick". It does, however, "feel" like the stable release is indeed getting very close

Actually I use v6.2 RC4, but I agree with NAS that there should be security updates for the current "stable release". And many folks will likely stay with v6.1.x if they don't want or need dual parity. I simply don't think the "stable release" should be abandoned BEFORE there is a newer stable version.

Not going to happen. Once 6.2 'stable' is released, 6.1 is no longer supported. We simply don't have the resources to maintain multiple release trees. Understand => but note that "Once 6.2 'stable" is released, 6.1 is no longer supported" IMPLIES that BEFORE 6.2 stable is released, 6.1 IS supported => yet there have been no updates in over 6 months. NAS has, of course, been VERY vocal in pointing this out as time has passed by and the outstanding security issue list has grown.

THAT is a significant UNDERSTATEMENT NAS has absolutely been the loudest voice around on security patches -- both publicly and in the private moderator's forum. My nickel's worth => The 6.1.x releases are indeed the "stable" release thread; and, as such, should absolutely have had more security updates. In addition, many will likely want to simply stay with this release for a couple of reasons: (a) If they don't need (or want) dual parity, there's really no compelling reason to switch; (b) the 6.2 series is notably more CPU-intensive, so if someone's running an older system with a relatively low-power CPU and doesn't need more "horsepower" for VM's or Dockers, they may simply not want to "fix what ain't broken". IMHO, dual parity is enough of a compelling feature to move to 6.2; but many won't feel the need for that extra layer of protection [perhaps because they always maintain good backups; or are simply willing to take the risk of data loss]. This is somewhat analogous to those who stayed on v4.7 for a LONG time after v5 was released (I actually still know a few folks on 4.7) => it was (and indeed still is) a VERY stable platform, and if you didn't need support for drives > 2TB there weren't really many compelling reasons to update if your system was purely a NAS. In any event, I'm definitely in favor or a 6.1.10 release to update the security issues for that series.

Yes, that will do the trick. "shutdown" array is actually just "stop" array => you don't need to shut the system down. Ideally you should do the copies (both when copying the data somewhere else and when copying it back to the newly formatted XFS disk) with verification, to be CERTAIN everything is perfect; but undetected errors during a copy are very rare, so it's up to you whether you want to do that. It will nearly double the time ... but gives you the peace-of-mind of KNOWING that all is well.

Actually you DO put the original key file on your new USB drive => and then when you boot UnRAID there's a function that lets you replace your key with one for the new flash drive. Very nice feature update.

If you have read the rest of this thread and understand what is required to have a good, usable copy of your usb drive, then the only thing you need to do to make the new one bootable is run make_bootable just like when you created your original setup. ... and your key file

Just to be clear, the USB flash drive has NOTHING to do with the data on the hard drives. The only important file you do NOT want to lose from your flash drive is your UnRAID key ... which is tied to that flash unit. You should always have that saved somewhere. You can then freely format the flash drive; install a newly downloaded UnRAID version to it; run the MakeBootable script; copy your key file to it; and then boot your UnRAID server with that flash drive. You then simply assign your drives & when you Start the array it will, if there's a parity drive assigned, do a parity sync. THAT is where you need to be VERY careful. You do NOT want to assign the wrong drive as parity, or it will overwrite all of the data on the disk. One SAFE way to be sure you don't make that mistake is to assign all of your data drives first, but do NOT assign a parity drive. Then Start the array and confirm that it doesn't show any "unformatted" drives [if so, the "unformatted" drive was probably your parity drive before] and that you can "see" all of your data with no problem. THEN you can Stop the array; assign your parity drive; and then Start the array and let it do the parity sync. r.e. the last question ... No need to copy the previous files -- just do as I just outlined, copying the key file from the failed USB flash drive (which you have saved a copy of somewhere] to the new flash drive. When you boot to UnRAID, you can select the option to move your key to a new USB flash drive, and the Limetech server will provide you with an updated key file for the new flash drive.

Remember, however, that the "current behavior" of the stable release (and all previous releases) was to NOT start the array if a disk was missing. As Johnnie noted, this behavior changed with the 6.2 releases -- so there isn't a baseline for "current behavior" in 6.2, since it's not yet been released. Arguments against an "Always" option: (a) It's NOT the way the system has worked in all previous releases; (b) Not starting the array with a missing disk is, as NAS noted, the "only universal notification" method => i.e. it will guarantee the user knows they have a missing disk, since they'll have to go to the Web GUI to Start the array and will see the problem; © It doesn't keep somebody from continuing to use the array with the missing disk => they simply have to manually click on Start ... and thanks to (b) they'll know they have an issue and will (hopefully) get a replacement disk ASAP to replace it (or otherwise resolve the problem) ... so they'll be running "at risk" for the least possible amount of time.

Agree. While it might be okay to have an "Always" setting, that should definitely NOT be the default. But the more I think about it, the less I'm convinced we need an "Always" choice. As I noted earlier, simply having two settings [No and Yes, where Yes means "Yes, if there aren't any missing disks"] means that it's always a conscious action to Start the array if there are problems. As NAS noted, if you boot the array and your shares aren't available (i.e. the array doesn't start), that's the one universal method of ensuring the user LOOKS at the array status page. That's the most reliable guarantee of a "notification". r.e. Brit's point on high availability => The array is going to be available even with a missing/failed disk as long as it's not Stopped. If it's stopped, it's not going to be available anyway. Granted, if it's then rebooted, the user would have to manually Start it in this scenario; but in most cases the user will be aware of the reboot process. Note also that if it's a case where high availability is really important, it's not likely there will even be a missing disk => one would hope that as soon as the user/admin KNEW about the missing disk [hopefully through notifications] they would have already resolved it by replacing the failed disk

Good point => and a reasonable argument for the "Always" option ... Wonder what percentage of UnRAID users have their systems set up to receive automated notifications ... (I suspect it's a VERY low percentage) Perhaps "Always" should actually be "Always - as long as notifications are enabled"

While 3 options would be okay, it seems that there should really only be two: Yes No ... and that Yes should ALWAYS mean "Yes, if there aren't any missing disks" I suppose there might be some rationale for "Always" -- it would indeed let the data still be available; but I'd also think that if there is a missing disk the user should absolutely be made aware of that => and not auto-starting would force them to have a look at the status page and they'd see what the issue was. Not everyone who uses UnRAID looks at the status page with any regularity.

I haven't used the UnBalance plugin; but my understanding is that it's designed to avoid the "user share copy bug" problem, so you're safe to continue with the process using UnBalance.

Yes, I see that (just looked at their pictures). Most of the CyberPower units I've seen (in the US) have two sets of outputs -- one set is battery backed up; the other set are surge only.

Don't forget to actually plug the server into the UPS :) Also, note the UPS has both battery backed up outputs and "surge only" outputs => be sure everything you want to run on the inverter is plugged into the battery backed up outputs.

If you UPGRADE your current VM to '10, that will work fine -- and you'll then be able to do a clean install using the same VM if you want to. But if you try a clean install on another VM with the same key it MAY not work -- not sure how the activation servers check; but I do know they'll refuse to allow a key that's already in use ... so it may not activate correctly with that key. One approach you could take is to make a complete backup copy of your VM; then do an update of the VM to '10. You'd then have both '7 and '10 installed in the same VM => indeed if you renamed one of them they'd probably both work just fine at the same time (but that would be a licensing violation).

It won't work with an Enterprise key; but it absolutely WILL work with an Ultimate key => I've done this with Ultimate, Pro, and Home Premium Windows 7 keys with no problem. It will NOT work with a key that's already been used to install Windows 7, however ... perhaps that's why you've had issues. REMEMBER, however, that this is only true through the 29th (this Friday).

I presume you know you can do a clean install of Windows 10 using these keys -- but only for the next two days. If you want a Win 10 VM (or VMs), NOW would be the time to create them. Just enter the Win 7 Pro key when prompted for the Windows 10 key, and it will automatically install the Pro version (since it's a '7 Pro key) and will activate with no problem.

Don't buy a UPS without AVR (automatic voltage regulation). The CyberPower Value SOHO units at the link you gave DO have this feature, so they'd be fine. The 360w unit should be fine for your build; but I'd recommend going a bit higher to provide a bit more headroom (the 480w unit is fine).

Worth worrying about ?? Certainly not worth losing sleep over. Simple fact is if a bit changes you're going to know it on the next parity check ... although you won't know WHICH bit changed. So it's a VERY good idea to maintain checksums. e.g. when I add a movie to my server I (a) create a checksum for the movie (using Corz); then copy the movie folder to the server and to my backup. So at any given time I can validate a movie with a simple right-click, "Verify checksums"; and if I find an error I can repeat this check on my backup (just to be CERTAIN it's good) ... and then just replace the corrupted movie with a good copy from the backups.

Just be CERTAIN that when you copy the data from one drive to another you do NOT do a share - share copy ... if you encounter the infamous "user share copy bug" you'll lose ALL of the data involved in that copy.

Or mount it on a heavy duty set of casters (with locks on two of them, so it doesn't move "uninvited"

Sorry to hear it's been abandoned before it was completed ... but I can certainly understand. I have a LOT of unfinished projects I've started over the years that have been relegated to a back burner which I'm sure will never actually be lit But this was SO nice !! And it sure seem like it was effectively "done" ... or at least "done enough" that it could have had a nice spot upstairs where you could show it off !! As for SATA cables not reaching your drives -- SURELY 36" cables would work: http://www.monoprice.com/product?c_id=102&cp_id=10226&cs_id=1022602&p_id=5131&seq=1&format=2