Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


doron last won the day on September 25

doron had the most liked content!

Community Reputation

18 Good

1 Follower

About doron

  • Rank
    Advanced Member


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Wizardry huh. More like rustiness. In fact, even that filter was kinda heavy-handed - a better version would have been lsblk | grep "crypt" | sed -r 's/[^[:alnum:]]*([[:alnum:]]*) .*/\1/' At any rate, I did hack up that script. It is attached here. If there's interest, I'll put it in its own thread, maybe even pack it as a plugin or something. urlukskey # Change the LUKS key/passphrase of all LUKS block devices # that are currently open. Basic assumption is that all # of them are ruled by one common key (Unraid array & cache), # although this assumption is tested and validated. # # # Usage: urlukskey [current-key-file] [new-key-file] # # Both positional arguments are optional. If provided, # each of them is either the name of a file (containing # a passphrase or a binary key), or a dash (-). # For each of the arguments, if it is either omitted or # specified as a dash, the respective key will be prompted # for interactively. # # Note: if you provide a key file with a passphrase you # later intend to use interactively, make sure the file # does not contain an ending newline. One good way to # do that is to use "echo -n", e.g.: # # echo -n "My Good PassPhrase" > /tmp/mykeyfile # # This code has been tested, but no warranty is expressed # or implied. Use at your own risk. # # With the above out of the way, please report any issues. urlukskey
  2. While @johnnie.black is obviously correct and this item will do the job perfectly, if you plan to only use SATA 6Gb/s drives on this box (and not SAS3 drives), it might be an overkill. Looking at your source, this may serve you just as well, for a fraction of the cost. If you go that route, you will need two SFF-8087/SFF-8643 cables, such as this.
  3. Umm, apparently the logs are not being stored on permanent storage, and the server has been restarted since then... So what I have does now not cover the relevant time. Sorry about that.
  4. Isn't it?... 🙂 All it does is take lsblk output lines that contain "crypt", and extract the first alphanum token out of them. Run the line on your server and see what you get. Might be a good idea to write a script to do a key change amass. If I get some spare time later today I might hack up something.
  5. This has been discussed in other threads, e.g. here, but I didn't find an entry in Feature Requests so here goes. Unraid is not spinning down SAS drives. It appears to try, and the GUI indicates that the drive is spun down (with a grey ball and temp not being presented), but in reality these drives keep spinning, remaining warm and drawing full power, 24x7. The problem seems to be that hdparm, which is used to spin down drives, does not affect SAS drives. A solution might be to use the sg_start command (haven't tested this thoroughly but it seems to be doing the right thing): sg_start -s /dev/sdX <== spin up sg_start -S /dev/sdX <== spin down (unfortunately the above does not seem to do the right thing unto SATA drives, so we'll either need to have conditional logic, or maybe just run both tools in sequence for each spindown/spinup operation.) I'm sure adding SAS spindown capability will be met with massive gratitude from a lot of us.
  6. Yep, that could come really handy, even allowing you to script the whole process, if you pass it via a simple filter, e.g. lsblk | grep " crypt " | sed -r 's/[^a-z]*// ; s/([a-z0-9]*) .*/\1/' Welcome aboard! 🙂
  7. @Derek_, glad it worked well for you. Just for other readers of this thread - note that for the array disk you must use the /dev/mdX devices (not /dev/sdX), whereas for the encrypted cache drive you need to find the actual device name /dev/sdX and then use it adding "1" for first (only) partition on that disk. You do not do this for parity drives - they are not LUKS devices. You're very welcome. Great question. You do have 7 left. What technically happened is that for each drive, you added a key into slot #1 (second slot), then restarted and tested, and then removed the key from slot #0, marking it "disabled". The next time you do the same exercise (assuming no fiddling in between, I'm simplifying this a bit), you will add a key into the first free slot - which will now be #0. So if I understand your underlying question, you can repeat this process an infinite number of times - as long as you remove the old keys. The eight slots can keep up to eight keys simultaneously.
  8. I don't see a reason to stop anything. The key slots are fixed and are manipulated in place. Your data is not affected during the process. Just do the full set of luksAddKey, stop/start when convenient to see that the new key works, then a set of luksRemoveKey.
  9. Absolutely not. You must do it when the array is started. In fact when it's not started you will not be able to follow the instructions above, as the /dev/mdX devices will not be available.
  10. @Derek_, limetech's post in the thread referenced above has it exactly right. In brief, you can either use "cryptsetup luksAddKey" followed by "cryptsetup luksRemoveKey", or just use "cryptsetup luksChangeKey" which, in most instances, just bundles these two actions together. The safest way would be to do a whole set of luksAddKey, test that everything works with the new key (array stop/start from GUI etc.), and then use luksRemoveKey to clean up. The /dev/ devices you must use as operands for cryptsetup are /dev/md1 for disk1, /dev/md2 for disk2 and so forth. Note that you have to do it unto all of your encrypted array disks(!), and make very sure you assign the exact same key to all of them. Another thing you want to be mindful of is your cache. If you have configured it to be encrypted XFS, you'll need to take care of it, too. To figure out the correct device name for the operation, you can check out your GUI main tab. Under "Cache Devices" you will find your cache drive. There, you will have the device name in parenthesis under "Identification". So if, for example, you find "(sdc)" in there, your parameter for the luksAddKey / luksRemoveKey would be /dev/sdc1 (note the "1" suffix, indicating the first partition). (Edited - corrected cache reference)
  11. Hi folks, I've recently pre-cleared 3 drives using the plugin (run off of Unassigned Devices, successfully completed) and then added them to the array, one by one. Two drives were recognized by Unraid as clear and added immediately. The third was not recognized as being precleared and Unraid kicked off a clear - again. For a 12TB this is a bit frustrating... The two drives that went in smoothly are 4TB, 512e. The one drive that went into clearing again is 12TB, 4Kn. Btw the Unassigned Devices code recognized all three of them as "precleared" (under fs type). Any thoughts on what could be the reason for the larger (newer) drive to not be recognized as pre-cleared? Could it have something to do with the drive being 4Kn? (I posted about this here and received the good advice to ask on this thread).
  12. Hi all, I've seen this discussed in old threads, but no resolution so here goes. I've just added three drives to my array: two 4TB drives and one 12TB drive. All three had been just previously precleared successfully using the preclear plugin (and the Unassigned Devices Plugin noticed the signature and marked their fs as "precleared"). I added them one by one (just caution, no reason). The two 4TB drives were recognized as precleared, added immediately and were ready for formatting. The 12TB one was seemingly not recognized as such, and starting the array initiated a clearing. For a 12TB drive this is going to take many hours, which is a bit frustrating as we've just been through a full preclear. One fact that may or may not be related is that the "problematic" 12TB drive is 4Kn, while the 4TB drives are 512e. Could it be that the PC plugin's signature on such drive is not properly detected by Unraid? Any other reason that may cause this? (Unraid version 6.7.2.)
  13. I didn't look up the specific mobo but typically the SATA ports are tied off of the chipset, which you can't passthru. The better news is that you can pass the SATA drives you connect to them, as RDM drives. This forum has numerous guides as to how to do that. This will leave your slots free.
  14. A data point: My SAS drives (HGST HC520, relatively new crop) appear to spin up and down properly for Unraid, in the sense that the GUI shows them as spun down and turns their temp display into "*", and there are no i/o sense errors in syslog. However, spin down seems to not actually happen, judging by the fact that clicking "spin up" on the GUI "spins them up" instantly, and their temp remains around 30C while my spun down SATA drives wake up at around 24C. Connection is via an on-board LSI 2308 chip.