SpaceInvaderOne

Im deeply saddened to hear about Ronald's passing. Though we never met in person, I'd worked with him and spoken with him regularly and always valued our conversations. He was always helpful, knowledgeable and generous with his time. The Unraid community has lost someone irreplaceable and he'll be genuinely missed. My thoughts are with his family and everyone who knew him

Thank you very much for the info, that's really useful. I'm wondering if if there was a bug when it came to looking at the encrypted unassigned disk. And then for some reason didn't go any further and skipped the rest of your disks. I'm about to travel abroad, but I will try and recreate the same as what's happened to you and then push out a fix.

I get where the concerns are coming from, but I think some people are missing the point of the plugin. It’s not meant to give maximum-strength encryption if that’s the goal, the best option will always be to enter a strong passphrase or key file manually at every boot. This plugin is for people who want their array to auto start and, until now, were doing that by storing raw keys on the flash or even downloading them from the internet. Compared to those methods, this is a safer middle ground no keys sitting around in plain form. I’ll be pushing out an update later this week that adds a clear note in the Auto Start section to say exactly that: it’s not as secure as manual entry, and yes, in theory brute force is always possible. But IMO if someone is determined enough to go that far, they’re probably getting your data one way or another.

Hey EDACerton, thanks for taking the time to test the plugin and share your thoughts I really appreciate it. You’re absolutely right that a hardware derived key isn’t as cryptographically strong as a long random passphrase. That’s by design. The plugin isn’t trying to compete with “enter your passphrase every boot” style security if maximum strength is the goal, then the best option will always be to type in a long, random passphrase at startup. The problem this plugin tries to solve is a practical one. Before this, people who wanted their array to auto start were either putting the key directly on the flash drive or an external place and calling it from in the gofile. These methods mean the key exists somewhere in plain form. I tried to make this plug-in address that and just so it doesn't have the key stored anywhere on disk or online. Yes You're right, having a hardware drive key that reduces the theoretical cryptographic strength, but in practice it’s still stronger than the approaches many people were actually using before.. And for most Unraid users who encrypt drives for peace of mind (RMA, casual theft etc) rather than nation state level protection 😊 that trade off makes sense. On uninstall, that’s a really good point. Automatically removing the slot-31 key would mean manipulating LUKS headers at uninstall time I just worry about trying to have the plug in remove the keys on uninstall just adds additional points of failure. What are your thoughts about it? But either way I think I should definitely change the plug in so on uninstall, a message does come up and tells the user that the keys are still on their disks and they haven't been removed. I think that's an excellent point you brought up. But overall, if someone truly needs maximum cryptographic security, they shouldn’t be using any auto unlock method, whether it’s this plugin or a go file script and should stick with a strong passphrase/keyfile entered manually. So I agree with you on the crypto maths etc but I think the plugin’s value is in offering a safer, more practical option for auto unlock than what users were already doing, not in aiming for perfect theoretical strength. But I think what I'll do is I'll edit the first post here just to make it clear that it does have its downsides for sure.

Don’t worry, you haven’t lost any data. What’s happened is that your array drives don’t seem to have the extra key in slot 31. On reboot the server was able to unlock the pool automatically, but because that key isn’t present on the array drives, they stayed locked. That’s why they’re showing as “unmountable :wrong filesystem”. Before changing anything, could you please grab a diagnostics file and either attach it here or send it to me in a PM? After that, go into the plugin and disable auto-unlock, then restart the server. When it comes back up, enter your original encryption key manually, that will mount all your drives. Once they’re mounted, open the plugin again, run “Encryption Info” with the “Very Detailed” option, and share the output (either paste it here or PM me). My guess is that slot 31 on the array drives will be empty. The plugin has a safety check that skips adding an extra key if it couldn’t make a header backup, and I think that’s what’s happened in your case.

Yeah I can see why it might look that way at first glance. But the situation is a bit different in practice. The plugin doesn’t just use the MAC address by itself. It builds a key from both the motherboard serial and the router’s MAC, then runs that through a SHA-256 hash. For an attacker to try brute forcing, they would need to know not only that this plugin is being used but also that the hardware-derived key is what’s unlocking the drive. From the outside looking at the server, all they would see is the normal Unraid prompt to enter a passphrase/keyfile. They would be able to know the motherboard serial if they steal the server, but guessing the MAC is still a massive problem space. A MAC address is 48bits long that’s over 281 trillion possible values. Yes, the first three bytes are vendor specific, but each vendor has millions of possible device combinations. That quickly becomes unworkable for brute forcing. The plugin isn’t designed to turn Unraid into a maximum security appliance. Its goal is to make auto unlocking practical in the most secure way possible, without having to drop key files onto the flash drive or fetch them from the network etc etc. I think the plugin is also useful just for header backup feature too.

Thanks for the suggestion I really appreciate you thinking about ways to improve the plugin. After looking at it, I think the router MAC method is still the best fit. The MAC address itself isn’t the key, it’s just one part of the hardware fingerprint along with the motherboard serial. Whether the MAC comes from your router or another device, the cryptographic properties are the same. The protection really comes from the fact that if the server is moved to a different location, it will see a different router MAC and the auto unlock will fail. Routers also have the advantage of being stable and on 24/7 with every network having one. The plugin can detect the default gateway automatically, so there’s nothing to configure and no need to worry about IP addresses or DHCP changes. Using a hidden device with SSH works too, but it adds a few more potential failure points , the device might be offline, its IP could change etc Part of the design goal was to keep the plugin simple and seamless, only prompting the user when absolutely necessary. Adding IP configuration would mean people need to know more about their network setup, and it would open the door for more issues for beginners. For now at least, the router-based approach feels like the best balance of security, reliability, and simplicity.

Yes you dont really ever need the know what the derived key is, as the orginal key is unchanged and works as it always did (it is not replaced). But a backup is actually made in the setup process. When a hardware derived key is created, the plugin automatically generates a complete backup. All LUKS headers are saved into an encrypted zip file, with each header tagged by its disk UUID. The archive also includes a detailed report showing the hardware derived key, the status of all slots on each drive, and the hardware identifiers used to derive the key, ie the router MAC address and motherboard serial number. The zip is encrypted for security. If your orginal LUKS encryption uses a passphrase, that same passphrase is used to protect the backup. If a key file is used instead, you will be prompted to set a password for the zip. Also if either hardware anchor (the router or motherboard) is changed, the plugin detects this and prompts you to generate a new hardware-derived key. The new key is then written into slot 31, replacing the old one.

Encrypted Drive Manager - Secure Auto-Unlock Plugin & other tools for Encrypted Arrays Hey everyone! I wanted to share my first ever official plugin. Now I've been working on this on and off for quite a few months and this plug-in solves a problem I think many of us have with encrypted Unraid arrays. The Problem So here's the thing a lot of us are using encrypted arrays, which is great for security. But to get auto-unlock working, most people end up storing their LUKS keyfiles right on the server or downloading them from somewhere online. and referencing them in the go file. It works, but there's a huge security hole: if someone steals your server, it'll just unlock itself using that same keyfile. You basically get zero theft protection. I kept thinking there had to be a better way to get the convenience of auto-unlock without giving up the security benefits of encryption. The Solution This plugin creates what I call "hardware-bound" keys. Basically, it takes your motherboard serial number and your router's MAC address, combines them, and generates a unique unlock key from that combo. The cool part is. - The key is never stored anywhere - it's generated fresh every boot - It only works in your specific location with your specific hardware - If someone steals your server and moves it somewhere else, the router MAC will be different and auto-unlock fails - Your original passphrase/keyfile stays completely untouched So you get the convenience of auto-unlock at home, but theft protection if your server gets stolen. How It Works It's pretty straightforward to set up 1. Install the plugin from Community Applications 2. Enter your current LUKS passphrase or keyfile once during setup 3. The plugin generates a hardware key and adds it to LUKS slot 31 (the last slot) 4. From then on, your server auto-unlocks using the hardware fingerprint If you ever change hardware or move locations, just regenerate the key - takes about 30 seconds. Features The plugin has three main tabs - Auto Start: Generate hardware keys and enable/disable auto-unlock - LUKS Headers: Backup your LUKS headers with encryption (always a good idea!) - Encryption Info: View detailed info about your encrypted drives and key slots It integrates with Unraid's native event system, so no messy go file modifications. Fully responsive design and works with both light and dark themes too. Installation Just search for "Encrypted Drive Manager" in Community Applications. You'll need Unraid 6.11.0+ and encrypted drives obviously. The plugin is completely non-destructive - it doesn't touch your existing LUKS setup at all. Your original passphrase/keyfile keeps working exactly like before. Important note If you’ve previously set up a script in your go file to download a LUKS key from elsewhere for auto unlocking, make sure you remove it when using this plugin. New users who haven’t done this before don’t need to worry about it. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Security Note This plugin's auto start feature isn’t as secure as manually entering your passphrase or keyfile every time you start the array. In theory, it’s possible for a determined attacker to brute force the hardware derived key. But that’s not what this feature is aiming for. It’s designed for people who want the convenience of auto unlock while avoiding the much bigger risk of leaving plain keys on the flash drive or pulling them from the internet at boot. It’s a middle ground, not perfect security, but a safer and more practical option than what many users were already doing. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- If you want all the technical details and security explanations, I've put together comprehensive documentation here GitHubGitHub - SpaceinvaderOne/encrypted-drive-managerContribute to SpaceinvaderOne/encrypted-drive-manager development by creating an account on GitHub.Would love to hear what you think! Any future feature suggestions? Let me know if you have any questions or run into any issues.

Last week I bought a Sapphire 9070 XT for testing on a server with a Z690 motherboard and a 13900K CPU. In early testing, I ran into what looks like the reset bug affecting this card. I didn’t have much time to troubleshoot, but I was able to pass the GPU through to a VM without doing anything special no need to bind it no vbios I simply added it to the VM as normal and it worked. However, there’s a major issue for me. When I shut down the VM, the entire server hangs. This also happens when running a custom 6.14 kernel. I’m away on holiday for about 10 days, but once I’m back I’ll be taking a proper look at this. If I find a workaround or solution, I’ll post an update.

Hi @Bala Bob That’s great to hear the GPU is passing through successfully now. One thing I’d be really interested to know, after you’ve shut the VM down, can you start it again without rebooting the server? That would tell us if the GPU resets properly after the first passthrough

Oh also the logviewer pic is not VM related so dont worry about that

Hi Rick. Ok so that didnt work. Lets see if the GPU is in D0 when it first boots and if and when its in D3 after a boot Lets try these steps and note the results of each Step 1 – Full Shutdown and Power On 1. Shutdown your Unraid server completely 2. Wait 10/15 seconds after it shuts down 3. Power it back on 4. Do NOT start any VM 5. Open a terminak and run cat /sys/bus/pci/devices/0000:03:00.0/power_state 6. Note whether it says D0 or D3 --- Step 2 – Unbind VFIO 1. Go to Tools > System Devices in Unraid web UI 2. Uncheck "Bind to VFIO at boot" for - Your GPU - Your GPU Audio device 3. Reboot the server 4. After reboot, run again cat /sys/bus/pci/devices/0000:03:00.0/power_state 5. Note the result again (D0 or D3) --- Step 3 – Remove Framebuffer Block (if still D3) 1. Go to Main > Flash 2. Scroll to "Syslinux Configuration" 3. Find the line starting with append initrd=/bzroot ... 4. Remove: video=efifb:off,vesafb:off 5. Click Apply and Reboot 6. Run again: cat /sys/bus/pci/devices/0000:03:00.0/power_state --- Step 4 – Allow AMDGPU Driver to Initialise GPU 1. Make sure - VFIO is still not bound & Ffamebuffer still removed 2. Reboot the server 3. After booting, run cat /sys/bus/pci/devices/0000:03:00.0/power_state 4. The GPU should now be in D0 Step 5 – BIOS Settings Reboot and enter BIOS Change these settings if not like this - Primary Display -- IGFX (iGPU) - Multi-Monitor -- Enabled - CSM -- Disabled - Above 4G Decoding -- Enabled - Resizable BAR (ReBAR) -- Disabled Save and reboot. Run the power state check again: cat /sys/bus/pci/devices/0000:03:00.0/power_state --- Step 6 – Try the VM Without the vbios attached also again do not bind GPU to VFIO at boot Then starting the VM with GPU passed through --- After each test, report - The GPU power state (D0 or D3) on boot of server - If the VM starts - Any error messages seen & hopefully we can get it to work. But AMD gpus are known to have reset issues which your D3 is closely related to

Hey there, I noticed the title mentions a 9070XT, but in the body, you say you’re passing through a Sapphire 7900 XT. Just wondered which model you’re using? If it’s actually a 7900 XT, you’re not alone alot of people have reported similar passthrough issues with this card on the net. A couple of things to try 1. Bind GPU to VFIO Go to Tools > System Devices in Unraid. Find your GPU and GPU Audio device. Check Bind to VFIO at Boot and reboot server 2. Disable Framebuffer to Prevent Host from Using GPU Modify Syslinux Configuration This prevents UnRAID from using the GPU for console output and helps avoid D3 power state issues. Goto Main Tab > Flash and edit the syslinux config adding video=efifb:off,vesafb:off ie label Unraid OS menu default kernel /bzimage append video=efifb:off,vesafb:off initrd=/bzroot 3. Disable resizable BAR (ReBAR) Some RDNA3 GPUs have issues with passthrough when Resizable BAR is enabled.Try disabling it in BIOS and see if it helps You can also do in the XML by using <rom bar="off"/> Also what is the card like after a cold boot of the server. Do you still have the issue or is it only after restarting a vm etc. Also have a read here for a discussion on the 7900 and passthrough https//forum.level1techs.com/t/the-state-of-amd-rx-7000-series-vfio-passthrough-april-2024/210242

Do you know the OS the vm is? The size looks small compared to whats listed .ovf file (even with thin provisioning) In the .ovf file size is test-disk1.vmdk 563 MB test-disk2.vmdk 1 GB test-disk3.vmdk 102 MB test-disk4.vmdk 307 MB But to convert as Kilrah said you should convert each to raw vdisks in Unraid put them in a temp share or folder ie /mnt/user/temp_share cd into that share. cd /mnt/user/temp_share then for each vmdk run qemu-img convert -f vmdk -O raw test-disk1.vmdk test-disk1.img That will make them raw vdisks. Then make a new vm again as said by Kilrah the XP template should have the defaults that you need CPU qemu64 (if that doesnt work you may have to emulate a 32 bit CPU but thats more difficult as you need to change the xml RAM 256MB BIOS SeaBIOS Chipset i440fx Nic as no pcnet32 in Unraid so I would choose RT1839 Best of luck