Thomas74

It's the community who should be thankful. This plugin is a life saver, and kudos to you for taking the rains in a long line of good people.

Sorry for not doing even the simplest of verification before asking. Worked after clearing cache and a couple of forced refreshes. 🙈

Also updated and lost all folders. I cannot remove my compose plugin yet, so how can I get my folders back

I must say that I really applaud the initiative from @SpaceInvaderOne on this plugin, and if I were to assume anything on behalf of the Unraid community based on myself, I would think many are welcoming such a plugin. That being said it needs to be as secure as possible - with a clear understanding of what that means. For my own setup I've tested various solutions, and I've landed on an approach were upon boot a request is placed some where in my Tailscale network. I am notified, and I have the option to approve or deny this request. If approved I am asked for a password (for the lack of a better word), which is used to decrypt the key which unlocks my master key-drive. For my setup to work I have highjacked the cryptsetup command on Unraid which allows me to change the default keylocation path used during boot (if only Unraid could supply a config entry for the keylocation). This means that the master key never leaves the encrypted volume, and when disks are unlocked this disk is closed. A rather secure solution, but it does rely on external factors and solutions (which of course can be hosted locally). This solves a few things (for me): 1) Nothing gets decrypted without me knowing (as I have to provide the master password) 2) I don't need to be at the Unraid console for a successful boot 3) The master key never leaves its location What it does not solve (yet) is the temporary storage of the key that unlocks the master key, but I plan to make use of the key programatically. Maybe we could expand on your plugin @SpaceInvaderOne ?

Thanks for you continued efforts into this plugin - which we cannot live without ;) I've been using both the latest and the beta (from May) successfully, but lately I had to create a stack using docker compose and these seem impossible to group. I've tried the labels approach but the containers will not be grouped. Any input from the crowd? //Thomas

Problem will reoccur if you reboot your server.

@Mainfrezzer posted this in another thread, which resolved my issue. Many thanks.

Thank you so much @Mainfrezzer - I have something to learn when it comes to searching! Problem solved.

Aha - that is indeed interesting. Testing the suggested fix now.

Thanks for the follow-up, but this is not a new setup - this has been running for years. With host access enabled.

Here's my config @bonienl Any suggestions as to how I can get my containers back up? I have downgraded to 7.0.1, but same issue. Running all zfs's I don't want to downgrade below 7.

Just tried this. Removed all the manual ip add’s, and assigned the ip’s in the custom br0 - still fails. No ping or service response.

Interresting. In my case I’ve running on 7 since it became available, and on 7.1.0. It only failed after 7.1.1.

Any reason why this worked when I upgraded to 7.1.0, but failed after going to 7.1.1? And do I have to a manual downgrade to 7.0.1 to get this working again? Right now all services has stopped due to my dns servers not working...

Having issues with Pihole and NPM (running on a static ip's on br0). Seems like there's issues with a host having multiple IP's assigned not working after updating to 7.1. I've used "ip addr add" to add 4 ips to my server, and none of them works after upgrading (no ping response). The IP is assigned on the container but the container does not bind to that ip. I've also tried adding the ips with "ip addr add" in the go script, but still fails. Anybody else see this? algarheim-diagnostics-20250510-1257.zip

Confirming having issues with multiple ip's assigned to br0 after updating to 7. Running Pihole on separate ip and now I am unable to get these up and running using a similar approach as @Smith007.

Great guide @bmartino1. I've opted to store my downloaded keyfile in a tmpfs area which is mounted at boot, and unmounted when the unlock process is completed. Adds additional security as the keyfile is never stored on disk as tmpfs is in RAM only.

Thanks for chiming in. This is what I currently do: Unraid connects to a remote server I get a telegram with a link to this server I put in a key Key is retrieved by the waiting script Key is used to unlock a local zfs-key-drive On this drive I can store other keys When script is done it unmounts and unloads the keys for the zfs-key-drive To achieve this I have created a wrapper script for cryptsetup, but I cannot seem to intercept the actual cryptsetup unlock which Unraid sends. My thinking was that as an advanced setting we should be able to configure the path to the keyfile, which in my case would be the zfs-key-drive. Voila!

It does indeed, and I have been using something similar but I've just downloaded the keyfile from protected dropbox url. But what I wanted to achieve was to have the actual keyfile locally, encrypted and when unlocked Unraid would read the keyfile from that location. To try to achieve this I have created a wrapper script for the cryptsetup command which intercepts the luksOpen command, removes the --key-file parameter (as it points to /root), and reissues the command with the path for my keyfile. This all works when done manually, but fails during boot. I can only assume that there are some code somewhere, that stops this from working during boot, so for now I am copying the keyfile to the /root folder and all is good. Stil not giving up though

Thank you for responding, but I am still questioning having to temporary store the keyfile somewhere on my disk. Ideally it should be a configurable location, for which I could input a path to a zfs encrypted area for which I have to supply a password during boot (currrently doing this now, but I have to copy the keyfile from the secured disk to /root, and deleted it when I'm done). Agreed, I might be paranoid but I like control over where this file is.

I've been running Unraid for years, and I now have multiple disks (luks-encrypted) and dataset (zfs encrypted), and I would like achieve something which I am not sure I can: Change the location from where cryptosetup loads it's key Supply the encryption password for the array preferably using a script at boot (I have the script) This enables me to use the following setup where the dataset loads their key from an encrypted drive, to which I can provide the key at boot time via a script. Is this at all possible? 🙏🏼 //Thomas PS: I primarily want this to avoid the key being stored unencrypted anywhere on my drives

Did you get a chance to look into this?

I am sorry to see you go @scolcipitato I have really enjoyed this plugin and it has been invaluable to me. Hopefully someone will maintain it into the future Good luck. @VladoPortos Thanks for updating it. I just reinstalled it and I can again edit my folders. One question though - and this was not introduced by your changes - I am have a real hard time saving the autostart setting - both for groups and containers. Upon refreshing they seem to reset randomly all over the place. Anyone else seeing this type of behavior?

Also having this issue - running Unraid 7. Jan 21 05:46:10 Algarheim unraid-api[15827]: ⚠️ Caught exception: Something went wrong. cron reached maximum iterations.#012#011#011#011#011#011#011Please open an issue (https://github.com/kelektiv/node-cron/issues/new) and provide the following string> Jan 21 05:46:16 Algarheim unraid-api[15827]: ⚠️ UNRAID API crashed with exit code 1 This seem to interfere with my user script schedules for zfs snapshotting. This problem started after upgrading to U7 - it's been running for months on 6.12.

Upgraded from 6.12.14 without any issues! Thank you for your dedicated and ongoing efforts //Thomas