ggfevans

@shpitz461 right on! and yeah, Techno Tim is the man. He dropped by the repo with a helpful PR and words of encouragement.

this makes my toes tingle. Like, almost enough to drag me back. well done, LimeTech team!

Hi everybody, I'm Gareth. Former Unraid user, now migrated to Proxmox because I'm a masochist. I'm also the guy behind Rackula. Rackula is a server rack layout designer, meant to be lighter weight than similar tools like NetBox. You can use the client side only version here: https://count.racku.la/ Full disclosure, I use GenAI tools (Claude Code, CodeRabbit, CodeAnt) to build this though all PRs are reviewed by me with my real eyeballs. I mention that now because I know this is an important piece of information for many users. It looks like this: For context, Rackula already ships container images so the level of effort for this is relatively low. I'm also about to ship a Proxmox Community Scripts LXC version, which has been A LOT more work than I had expected though I believe is totally worth it. I'm wondering about the level of interest in a potential template. I recognize that creating this not only means the template itself, the ongoing support requirement via forum thread is important too. I'm tracking work around Unraid distribution here with all the gory details. Thoughts, anyone?

Aha, thanks for catching this. I am not super familiar with Docker socket functionality so I've always avoided fiddling with this. Removing it when necessary seems a much better solution.

Good question(s), @aeisan. I have not found much in terms of what "expected" behaviour is in terms of how Unraid docker management handles environment variables it its Docker engine. To answer your question, I do not believe a rebuild is necessary for env variables to be read and substituted by the Docker engine. I believe they are "read" at runtime, though I do not fully understand how. I see this was just over a week ago, did you get anywhere further?

Could TSDProxy be configured to expose its own web interface via the tailnet it manages, or would this create problematic dependency loops that might compromise reliability and troubleshooting capabilities?

Alllright, so I think what I already had did work - or should have. I nuked and reinstalled Homepage and my same --env-file /mnt/cache/appdata/homepage/.env extra parameter, as you described, worked. At first I thought I was missing an equal sign, eg. --env-file=/mnt/cache/appdata/homepage/.env - but that did not seem to make the difference. I am still not certain what specifically prevented my previous setup from working, however, I can confirm that Homepage is respecting my environment variables from a .env at /mnt/cache/appdata/homepage/.env Anyways, thanks!

Ooh, I think you may be right... though I have not yet been able to get this rebuild to work. I am about to remove and reinstall and see where that gets me.

TL;DR: Looking for a method to properly use environment variables/secrets in Unraid containers, specifically for Homepage but also as a general solution for the containers I am using. Considering migrating to Docker Compose with Portainer if that's a better approach. Current Setup Unraid Version: 7.0.1 Container Focus: Homepage (container template installed via Community CA) Container Path: /mnt/user/appdata/homepage Total Containers: 26 running containers The Problem I need to securely store and use API keys and sensitive URLs for my Homepage container, as well as other containers in my environment. According to the Homepage Docker Environment Secrets documentation, I should be able to: Create a .env file in my /mnt/user/appdata/homepage folder Define variables like HOMEPAGE_VAR_APIKEY=my_secret_key Reference them in my config with {{HOMEPAGE_VAR_APIKEY}} However, these variables aren't being evaluated properly, resulting in non-functional URLs and services. What I've Already Tried Created a .env file in correct location with proper syntax passed that .env file into the container using a ENV_FILE attribute with a value of /mnt/user/appdata/homepage/.env this was based on Docker documentation on env_file attribute, but this appears to be for Docker Compose context Verified file permissions on the .env file Double-checked the variable reference syntax in my config files Searched container logs for any environment variable errors adding a extra parameter to the container of --env-file /mnt/user/appdata/homepage/.env Questions Homepage Specific: Has anyone successfully used environment variables/secrets with Homepage in Unraid? How? General Unraid Question: Is there a standard way to use an environment file (like .env) with Unraid's built-in container management? Container Settings: Do I need to modify specific settings in the Unraid UI to point to an env file? Alternative Approach: Would switching to Docker Compose / Docker Compose Manager with an orchestration tool like Portainer be a better solution for managing environment variables across all my containers? Request for Examples If you've found a reusable method to use environment variables in your Unraid Docker setup, would you mind sharing: A redacted example of your container configuration How you've structured your environment variables How you reference them in your container settings Migration Consideration I'm considering switching to Docker Compose with Portainer to take advantage of the more standardized approach to environment variables. If you've made this switch: Was it worth the effort? Any unforeseen issues with Unraid? Any tips for a smooth transition? Thank you for your help!

Aha, I've figured out the solution! The issue was with the Tailscale state directory configuration, or lack thereof. For anyone else facing this problem, you need to manually set the Tailscale state directory in the DockerMan web interface for the UptimeKuma container. Specifically, I set it to: /mnt/user/appdata/uptimekuma/.tailscale This prevents the container from interfering with the host's Tailscale configuration and resolves the startup failures. I've created a gist with my full working configuration that you can reference. This is the content from /boot/config/plugins/dockerMan/templates-user/my-UptimeKuma.xml This approach maintains proper isolation between the container's Tailscale instance and the host system. Hope this helps anyone else who runs into the same issue!

I'm having difficulty configuring the UptimeKuma container to work with Tailscale. When I enable the 'use Tailscale' option in the environment settings, one of two problems occurs: The container fails to start up completely, or It somehow overwrites my Unraid host plugin's Tailscale configuration This issue appears to be specific to the UptimeKuma container, as my other containers work fine with Tailscale. I suspect there's something unique about UptimeKuma's configuration that's causing conflicts. Has anyone successfully exposed their UptimeKuma container through Tailscale? If so, could you share your configuration approach? I'd appreciate any working examples or specific settings that resolved similar issues.

My notes from this issue that I saved, formatted using Notion AI - sharing here should someone else hit this issue or similar: Port Conflict Resolution: Tailscale Serve & Unraid Web Interface A common issue when using Tailscale Serve with Unraid is port conflicts between Tailscale and web servers (Nginx/Caddy) on ports 80/443, preventing access to the Unraid web interface. Common Symptoms: Unraid web interface becomes inaccessible Port 443 shows as occupied by Tailscale (verified via lsof) Tailscale serve configuration persists with error: "background configuration already exists" Standard configuration removal commands fail Port conflicts between Tailscale serve and web servers on ports 80/443 Resolution Steps: First, stop all web servers using ports 80/443: Stop the SWAG (nginx) container if running Stop any Caddy containers if present Clear Tailscale serve configuration: tailscale serve reset Confirm successful configuration removal: tailscale serve list Verify port availability: lsof -i :443 lsof -i :80 Restart web servers using non-conflicting ports: /etc/rc.d/rc.nginx start Preventive Measures: Use alternative ports for web servers (recommended: 81 for HTTP, 4431 for HTTPS) Maintain a port assignment document to track usage Consider nginx/caddy reverse proxy as an alternative to Tailscale serve Note: After running 'tailscale serve reset', you may see the message "only localhost or 127.0.0.1 proxies are currently supported". This is expected behavior and confirms that no serve configuration is active.

A couple weeks later, I rebooted the unraid box (as part of maintenance) and ran into this issue again. Luckily, what @EDACerton had mentioned around tailscale serve being the likely culprit helped clue me in quickly. I was able to resolve my issue using the command tailscale serve reset which reset the config and removed the conflict. Thanks again for dropping that insight - with the knowledge it was an obvious issue.

That is absolutely a possibility. I would have likely tried to use trailscale serve at some point and yes indeed created that conflict. btw, thanks for your contributions to the unraid plugin @EDACerton!

Aha! Yes @JorgeB - this put me on the right track. I was successfully able to start unraid in safe mode and get GUI access. From there, I uninstalled the Tailscale plugin and then reinstalled. After that, I was able to start unraid in normal mode with the GUI working as expected. Thanks for your help - I am kicking myself for not thinking of safe mode to begin with.