JesterEE

The ask here is a StaXX dashboard widget that replicates/overrides the docker widget's functionality with folder/stack layering. See the included image of a sample of my docker widget with the FolderView3 tweaks enabled on my server's dashboard. Note that there are "folders" for grouped services which are expandable/collapsible, and all the other non-grouped services are listed below it. Show started only vs show all remains intact, and the docker grouping I implemented in the plugin is preserved on the dashboard widget. I can control the running status, launch the WebUI, command prompt, log window, etc. right from the dashboard. Currently, I have FolderView3 working with StaXX to provide this functionality. For example, in the image I shared, the ddns-updater container is deployed in StaXX while Nginx Proxy Manager is deployed as a normal docker. Even though Unraid registers my ddns-updater container as managed by compose, it still lists it in the docker page and thus still applies the folder rules I set in FolderView3 to group it with my other Networking containers. I'd like to abandon all need for FolderView3 with a complete migration to StaXX and this it a hold-out feature for me. It is also why I requested adding custom stack/folder icons in (2). One thing that FolderView3 can do that I really like is using 3rd party icons for folders; specifically hernandito's Animated "Docker-Folder" Icons for unRAID. Is it functional? No. Is it silly? Yes! But, we are simple creatures and it brings me joy to see nice animated images for my deployed services. & 4. I was surprised to see many projects don't offer a source of truth docker compose YAML file indicating the many options available to the container. This was a little surprising for me coming from Unraid templates which, more or less, usually include a means for full configurability of the container from the source template. Now that I know this, StaXX is doing a good job at trying it's best to be smart, but the source maintainers aren't making it easy. This is yet another challenge the Unraid devs face as they embrace compose in the future. For StaXX, I think you're doing the best you can, and I can't think of a better way to do it so please disregard these requests. I hope a better solution emerges in the future, and if that happens, I think you already have the infrastructure in StaXX to embrace it. I know I compared StaXX to FolderView3 a bunch, but I think StaXX gets to the real heart of the matter while FolderView3 just masks the inherent limitations of a non-compose based deployment in the Unraid GUI. I think StaXX is in a position to do it all better, but the lessons learned through the development of the many iterations of FolderView should not go to waste. If you are unfamiliar with FolderView and don't want to install it to see (I get it!), I suggest watching a few of AlienTech42's YouTube videos on the configuration of the plugin so you see what it can do and how StaXX can benefit.

Your welcome! It's really been nice updating my homelab with StaXX. IMHO docker compose is now necessary for deploying most docker services on a homelab. Gone are the days of spinning up a single container to handle a whole workload, and StaXX makes the transition from individual, disparate images to organized stacks bearable. I'm glad I found it when I did! Thanks for hearing out my comments and feedback! I have already been using some of the features you implemented and I'm finding less "gotchas' as I use the tool. Originally I tried to use your dev board to submit my bugs and requests, but it asked me to create a login. Sorry to say, this was a dealbreaker for me using your submission system . I understand why this makes it easier for you as you work with your AI assistant to make the tool better, but for me as a user, it's just one more set of credentials I have to manage for a system I won't use more than a few times. I understand why you'd want/need a login mechanism for this service to keep the garbage out of your tracker, but to encourage user input, might I suggest a different means of verification like OpenID Connect. This might be overkill for your project, but it also may encourage others to contribute. About the Collapse/Expand arrows, I still see it on my end, but I have been experiencing issues with the Docker page on my server updating dynamic events properly (e.g. refreshing after an update). I believe this may be due to the FolderView3 plugin, which is mostly pretty great, but can be somewhat wonky at times. Using the STaXX settings, I moved StaXX it to it's own page to hopefully remove any plugin conflicts with the default docker page, but I still see this issue. Take this as a grain of salt as this very well could be a me issue and I'm ok with that; it's extremely minor and does not affect the way StaXX works. See included screenshots of a simple folder with a single stack. Thanks again for working on this and I will report back if I find anything else as I continue to migrate images and deploy new services.

Feedback: It took me a while to notice the 'add file' buttons for the compose configuration. Now that I see it, it's obvious, but it took me forever to find it. Maybe it's just me, but if the '+' button were closer to the compose.yaml tab like it appears on modern web browser UIs, I think I would have found it faster. Dragging and dropping a stack onto a folder will yield an error "Only a ".staxx" bundle can be dropped here." I realize this is not the proper way to add a stack to a folder, but it is intuitive to perform this action since it looks like a file explorer, and it doesn't do what was expected. Bugs: .env files do not display blank lines. Also causes navigation/display corruption in the editor. Staxx does not respect the Unraid lock sortable items UI element. Folder Collapse/Expand arrows always displays "Collapse" regardless of state Unable to return to split view after selecting Form/Compose view Feature Requests (by desire level): Dashboard docker widget integration (Similar to FolderView3) Stack/Folder custom icons (Similar to FolderView3) Notification/Automerge of upstream docker compose environment (YAML, env files, etc.) modifications One of my biggest gripes with the current Unraid docker template system is that when a docker template is updated by the author, there is no way for a current user to easily merge the changes into the template deployed in Unraid. Staxx offers an infrastructure that could do this better while not compromising user modifications to the upstream configs.

Staxx came at the perfect time for me this week! I needed to roll out a new docker "stack" on my machine, and I finally decided to try and do it in compose to keep things cleaner. I happened to find Staxx in CA while I was considering the latest compose options, and after seeing the feature set, I decided to take it for a spin. I have not completely migrated all my dockers over, but I have set up a new Staxx stack from a compose file, installed an app from CA into Staxx, and migrated an existing container over to Staxx. All went pretty well! After gaining a little bit of knowledge through experimentation and exploring the Staxx UI, I was able to find the features I was looking for and get a number of containers running and working as expected in my environment. Overall, I am impressed with the abilities of the plugin. Since I'm not a regular compose user, I might not understand what Staxx may be missing that would be beneficial for doing complex compose setups, but for typical, everyday setups, I found it pretty easy to get comfortable with and use. Though, I found a couple bugs, and have a few suggestions which I will list below, I plan to continue to use this plugin for my docker needs in preparation for compose integration in Unraid 8. I hope the @limetech devs take note of this plugins functionality as they work on the next native implementation. This solution checks a lot of boxes!

Thanks for your work on this implementation of Krusader. I was looking at potentially migrating to your linuxserver/selkies based image from the ich777/krusader image and was putting them through some paces together. Overall, I think I liked the Selkies based image better due to the smooth feel of working in the browser with less visual artifacts which is nice when doing mundane file tasks. A few feedback notes. Quitting the application in the browser will cause the image to hang (black screen) with no way to recover into a new Krusader session without restarting the container. The functionality in ich777/krusader is (IMO) more desirable where closing the application in the browser window and reconnecting to noVNC (or refreshing the window) will restart the Krusader application. There is no diff tool in the base image. Please consider bundling in kompare or a similar tool to link with Krusader. This image consumes much more RAM than the noVNC based krusader container (~600 MB - 1.2 GB more by my testing). I'm fairly sure this is due to the heavier backend and video rendering requirement so I'm not sure what can be done about this, but for me, a 1 GB+ RAM requirement to run a file manager is a bit too heavy. If this could be halved through image optimization I would likely switch over. I thought the increased RAM usage might be due to the default CPU video rendering, so I modified the image to to use my NVIDIA 3070 GPU based on the Selkies GPU docs but RAM usage remained high (~800-900 MB idle). The GPU rendering pipeline did help a lot when resizing the window (no wait for the window alignment and font scaling to render vs a few seconds on the CPU rendering) but docker RAM usage was mostly unaffected. To render the web browser window at 3440 x 1274 @ 60FPS the hardware encoder required ~950 MB of VRAM.

Tried this today on my Bazzite Linux VM with Back 4 Blood and the solution is not working. Looks like in the future before I buy a game, I'm going to have to cross reference these lists to see if it's going to give me issues: https://steamdb.info/tech/AntiCheat/EasyAntiCheat/ https://steamdb.info/tech/AntiCheat/BattlEye/

@SpaceInvaderOne I finally got around to giving this plugin a try today and I am having the same problem as the users above. As reported by the plugin, I have 8 LUKS devices: 6 on my main array (4 with LUKS V1 and 2 with LUKS V2) and 2 on my cache pool (both LUKS V2). The plugin would not assign the hardware-derived key on slot 31 to any of my array drives, but it did assign the hardware-derived key on slot 31 to my cache pool drives. I'm not sure if the LUKS version matters, but I don't understand how my array drives got a mix of V1 and V2. All drives were encrypted by various releases of Unraid V6. Judging by which of my drives have which LUKS version, it looks like somewhere in the mid-late Unraid V6 releases (maybe 6.9 or 6.10) the default was changed to V2, and then reverted back to V1 in later releases. Though, this is speculation and I have nothing more than this anecdotal evidence. Also, an additional bug to report, when I removed the Auto-Unlock functionality (since it wasn't going to work for me in this state anyway), it did not remove the Slot 31 hardware-derived key from the cache pool drives! I have a before and after LUKS analysis from your plugin I will share with you, with server diagnostics, via PM. IMHO, this plugin is great and I really hope I get to use it. Happy to help you debug this issue, as long as my data is sufficiently safe as we do it! Thanks JesterEE

Sounds like the driver is fighting for control of the fans on the backend and getting stuck in an odd state. Have you disabled motherboard control of all fans except your CPU? Do you have any other plugins or containers installed that poll the fans?

Oddly enough, I just saw this on my Community Apps feed today. Looks like there's a timely solution for us though I have not tried it yet.

I use the Corsair iCUE Commander Pro for my fan controller. This controller (shown in the image attached) has connectors for 4 temperature sensors that you can route throughout your case. On Linux, the individual temperature readings are easily read by the sensors command with the fan speeds as shown in my previous post. Currently, FanCrtl Plus doesn't read these temperatures to adjust fan curves, but I'm holding out hope @CkChong sees the value in reading external temperature sensors and adds that functionality in a future release.

How did this topic go from asking about a removed feature and potentially asking for it to be reintroduced by the Limetech Dev team from a previous build to using AI to vibe code a solution to recreate the wheel?? Respectfully, I know you're trying to help but without the Dev team contributing to the conversation, outside of creating a plug-in to sideload the feature, I'm not sure there's a conversation to be had. Join works well, and I never had an issue with it, but I'll probably move on to an Unraid supported mechanism if it has been dropped. As for flexing, some Dev muscles to create a plug-in for the community, more power to you. I'm not sure there's a need for this one as only two of us users have commented on this and it's probably been removed for a while, so the reach will be fairly minimal. Join as an Android application and service seems to be in maintenance mode, and that is being generous. There's no reason for active development by the Join Dev since it has worked the same since Android v10, but the last Android app update was in June 2024. @limetech @ljm42 @SpencerJ Thoughts on the OP? Was this agent removed for a reason? Just looking for some clarification since I didn't see anything in any change logs.

This is a known issue with the way the plugin functions. You can not update a container which creates a network for other containers with this plugin because you can not ensure the dependent containers will be restarted after the update. This is required by docker networking since the network references become stale, still being linked to the previous container ID for actively running dependant containers. From what I understood when I looked into this myself over a year ago, it has to do with the Docker Unraid UI page itself which maintains the functionality to trigger the restart of the dependent containers rather than a universal backend mechanism. This is why it works on the Unraid UI when manually updating and not with the plugin. I personally deactivated the auto update for my VPN container and either update it manually or use the Backup/Restore Appdata plugin to trigger a dependent update once a week during the automated backup task maintenance. If you do the later method, you can create a start order of your VPN and dependant containers so they start in the correct order after a backup and update.

Hello Unraiders, I recently had my server offline for a while (~5 months) due to some technical issues and updated from 7.0 -> 7.1.4 when I was able to get it back online. Since it was so long since I had the server on, I was giving it a bit of a configuration cleaning; going through all the options to make sure things are set up correctly after the gap in updates. When I went in the Notifications Settings (Settings -> User Preferences -> Notification Settings), I noticed that the Join agent I am using was no longer listed as an option. Since I had this agent configured before it was removed somewhere along the line, I am still getting notifications via this agent with my previous settings intact and valid (/boot/config/plugins/dynamix/notifications/agents/Join.sh). I did a search on the Unraid forum and Unraid OS change logs to see when this feature was depreciated, but I could not find anything referencing Join. Does anyone have any ideas on why this agent was removed? Was there something malicious I should be worried about? I am open to switching notification services, but other than running my own Gotify server to ensure true security by not having another service in the middle, none of the options seem any more appealing than Join.

I came across your plugin today and immediately downloaded it! I have been hoping to incorporate this functionality native in Unraid for a while and I'm really happy you developed this application and it's continued development. Up till now I have been using liquidctl with the LaaC docker to control my fans with a Corsair Commander Pro, but this lets me also track drive temps for cooling. This is great especially when running array intensive tasks like array parity checks which gives me much more piece of mind. One thing I miss is the ability to also use the temperature sensors I have scattered around my case to add additional temperature dependency for my fan curves. Specifically, my temperature sensors from my ASUS motherboard and my Corsair Commander Pro. I have included the output from the sensors command on my system to illustrate the outputs I'm getting on these drivers, and also to highlight how the ASUS reporting driver differs from the k10 temp driver I'm currently using to supply FanCrtl Plus with data. Thanks again and I will continue to track this project! root@SERVER:~# sensors ... corsaircpro-hid-3-2 Adapter: HID adapter in0: 12.03 V in1: 5.05 V in2: 3.45 V fan1 4pin: 1240 RPM fan2 4pin: 1302 RPM fan3 4pin: 1110 RPM fan4 4pin: 939 RPM fan5 4pin: 1253 RPM fan6 4pin: 1316 RPM temp1: +28.4°C temp2: +21.2°C temp3: +22.5°C temp4: +24.8°C k10temp-pci-00c3 Adapter: PCI adapter CPU Temp: +61.1°C MB Temp: +54.0°C Tccd2: +31.5°C asusec-isa-0000 Adapter: ISA adapter CPU Core: 1.44 V Chipset: 3199 RPM Chipset: +64.0°C CPU: +51.0°C Motherboard: +30.0°C T_Sensor: +35.0°C CPU: 36.00 A nvme-pci-0100 Adapter: PCI adapter Composite: +40.9°C (low = -273.1°C, high = +81.8°C) (crit = +84.8°C) Sensor 1: +40.9°C (low = -273.1°C, high = +65261.8°C) Sensor 2: +44.9°C (low = -273.1°C, high = +65261.8°C)

Quick little pro-tip for forum posterity. I force updated the LaaC image today because I was doing some system maintenance (don't ask, I didn't need to do it, but I did), and afterward I was getting this error in the LaaC docker log on container start: ERROR: no device matches available drivers and selection criteria Thinking I messed the image up, I deleted my template and reinstalled from Community Apps, though I was met with the same error. The device was still recognized on the host in the /sys/bus/usb/devices/X-Y and /dev/bus/usb/XXX/YYY locations (I use the former in my template) so it wasn't an availability issue. On a lark, I thought that the device might not have been let go correctly by docker when I force updated the image and the device is now bound to an invalid endpoint (or something like that). So I stopped the running LaaC container, and ran these commands in a su terminal: echo 'X-Y' | tee /sys/bus/usb/drivers/usb/unbind echo 'X-Y' | tee /sys/bus/usb/drivers/usb/bind Upon restarting the LaaC container, my Corsair Commander was once again able to be seen by liquidctl. Hope this helps someone in the future!