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.

As this relates to Tailscale, I am wondering if I should/can move this to the Tailscale Support subforum?

So I have managed to break my Unraid web dashboard. Currently, nginx cannot start due to what looks like conflicting SSL config. I had previously moved unraid to :5001 and wanted to move it back to :443, and applied in the web configuration. Upon reboot I have no web dashboard access and get an HTTP 502 response. Fortunately, I still have SSH access so I am not totally hooped. Trying to start nginx manually fails: /etc/rc.d/rc.nginx start rc.nginx: Starting Nginx server daemon... No extensions in certificate rc.nginx: Nginx server daemon... Failed. And error logs show: tail /var/log/nginx/error.log 2025/01/19 21:14:06 [emerg] 2299839#2299839: bind() to [fd7a:115c:a1e0::1e01:e52]:443 failed (98: Address already in use) 2025/01/19 21:14:06 [emerg] 2299839#2299839: bind() to 100.103.14.82:443 failed (98: Address already in use) 2025/01/19 21:14:06 [emerg] 2299839#2299839: bind() to [fd7a:115c:a1e0::1e01:e52]:443 failed (98: Address already in use) 2025/01/19 21:14:06 [emerg] 2299839#2299839: bind() to 100.103.14.82:443 failed (98: Address already in use) 2025/01/19 21:14:06 [emerg] 2299839#2299839: bind() to [fd7a:115c:a1e0::1e01:e52]:443 failed (98: Address already in use) 2025/01/19 21:14:06 [emerg] 2299839#2299839: bind() to 100.103.14.82:443 failed (98: Address already in use) 2025/01/19 21:14:06 [emerg] 2299839#2299839: bind() to [fd7a:115c:a1e0::1e01:e52]:443 failed (98: Address already in use) 2025/01/19 21:14:06 [emerg] 2299839#2299839: bind() to 100.103.14.82:443 failed (98: Address already in use) 2025/01/19 21:14:06 [emerg] 2299839#2299839: bind() to [fd7a:115c:a1e0::1e01:e52]:443 failed (98: Address already in use) 2025/01/19 21:14:06 [emerg] 2299839#2299839: still could not bind() I can see tailscale is on :443: lsof -i :443 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME unraid-ap 14762 root 24u IPv4 7373720 0t0 TCP 10.0.0.111:35474->104.26.2.117:https (ESTABLISHED) tailscale 2290810 root 9u IPv4 12893822 0t0 TCP 10.0.0.111:35578->ec2-54-161-152-147.compute-1.amazonaws.com:https (ESTABLISHED) tailscale 2290810 root 26u IPv6 12897463 0t0 TCP [fd7a:115c:a1e0::1e01:e52]:https (LISTEN) tailscale 2290810 root 27u IPv4 12893958 0t0 TCP 100.103.14.82:https (LISTEN) tailscale 2290810 root 31u IPv4 12899715 0t0 TCP 10.0.0.111:54602->derp10b.tailscale.com:https (ESTABLISHED) node 2298862 root 21u IPv4 12949158 0t0 TCP 10.0.0.111:58966->lb-140-82-112-21-iad.github.com:https (ESTABLISHED) I am hoping to get some direction on how to resolve this and get web access back. I suspect a lot of confusion/multiple applications editing nginx has led to this. I am wondering if I would be best to revert to a default, or something else? Diagnostics and configs attached. Setup - Unraid 7.0 - Tailscale enabled - Dashboard previously moved to port 5001, now trying to restore to default - SSH access still working Current Issue Getting HTTP 502 errors when accessing Unraid dashboard. Config Details Current servers.conf has conflicting SSL configurations: ```nginx ssl_certificate /boot/config/ssl/certs/gByte_unraid_bundle.pem; ssl_certificate_key /boot/config/ssl/certs/gByte_unraid.key; ssl_trusted_certificate /boot/config/ssl/certs/gByte_unraid.crt; # Conflicting with ssl_certificate /etc/ssl/certs/unraid.pem; ssl_certificate_key /etc/ssl/private/unraid.key; Any insight or direction would be appreciated! gbyte-diagnostics-20250119-2050.zip nginx.conf servers.conf

I would not trust these. From what I can tell, they are simply taking any popular keyword and generating BS pages of clickbait. From what I can tell, if Lime Tech were to offer coupons they would do it directly through their own mediums (email, social, forums) rather than a dodgy coupon site like this. Not to be dismissive, I just wanted to emphasize some caution!

I am in the same boat - though I would be surprised to see Unraid offer discounts, considering they have only just recently moved to their new commercial model. I am not aware of any discount codes and that form element may be a relic of their previous model.

Great idea, thanks for putting this together! I will definitely give this a shot.

I had actually tried this prior to removing Monitor-All, without success. I do not think I specifically need Monitor-All, so I will just go without it until I see the need. I think I am going to use Uptime Kuma instead.

Correcting myself now - Unraid is reliable under Proxmox. Where you might encounter issues is if you deploy scripts, like Monitor-All, without fully understanding them. Remember: the computer does exactly what you told it to do.

@tjb_altf4 you solved it!!! I feel like an idiot - it was indeed monitor-all that was causing this problem. Evidently, because I do not have a qemu agent running, Monitor-all assumed this was a dead machine and power cycled it. After removing it (via the same install script and using the remove menu option), my Unraid VM is now running stably. I had done some brief googling and did not find this as a result. Well done on your searching, and I really appreciate your going the extra mile after I had essentially resigned to giving up on Proxmox. I feel especially silly knowing I brought this problem on myself! A fair warning to others, do not deploy scripts on your environment without understanding the impact. Thanks again Reptar @tjb_altf4, you have been extremely helpful. I owe you one.

I bumped up my Unraid VM to 8 GB of RAM, no change. I also noted that the Ballooning Device was enabled, I disabled with no change in behaviour - it still reboots consistently. What is odd is that I noted that the 5:19 countdown timer seems to start from first boot. So, if I boot up and then manually reset and start back up, I will still see a reboot at exactly 5:19 after that initial first boot. That reinforces to me that it is something to do with Proxmox that seems to interact poorly with Unraid in a VM. Have not yet made a decision on my final build though I think I have exhausted my troubleshooting approach here, unless I figure out a better logging solution and find some good clues.