TRusselo

no screenshot? pictures are worth a 1000 downloads. add to your github too.

# Container won't start after reboot: "address already in use" — but the port IS free Applies to: Unraid 7.3.x, Docker 29.x. Hits containers that publish a fixed host port in the 32768–60999 range (e.g. Deluge 58846/58946, qBittorrent 6881). Intermittent — usually after a reboot. ## Symptom Container fails to start with: failed to bind host port 0.0.0.0:58846/tcp: address already in use …but netstatlsof shows nothing listening on that port. ## Why Another container's docker-proxy grabbed your container's port as a random outbound source port (it's a client connection, not a listener — that's why it looks free). Your container just started too late to claim its own port first. ## Confirm it (SSH, replace 58846 with your port) lsof -nP -i :58846If you see a docker-proxy line like 172.17.0.1:58846->172.17.0.x:<someport> (ESTABLISHED), that's it. ## Fix (SSH as root) Replace 58846,58946 with your container's affected port(s): # 1. Reserve the port(s) so the kernel stops handing them out as ephemeral source ports sysctl -w net.ipv4.ip_local_reserved_ports=58846,58946 # 2. Kick the connection squatting on them ss -K -t 'sport = 58846'; ss -K -t 'sport = 58946' # 3. Start the container (or recreate it from the Docker tab: Edit -> Apply) docker start <container-name> ## Make it survive reboots Add this line to /boot/config/go (runs before Docker starts): sysctl -w net.ipv4.ip_local_reserved_ports=58846,58946 Include every fixed published port you have that falls in 32768–60999, comma-separated. Done — the container will now win the race for its port on every boot.

/mnt/cache/ for /mnt/cache/appdata/netalertx and /mnt/cache/appdata/logs will have better performance than /mnt/user/ I learned this the hard way couple years ago. ESPhome would take 5 minutes to compile tiny sketches. changing to /mnt/cache, 20 seconds.

there was an update overnight. not much changed except my daemon now shows 2 interfaces, neither are the host network that the daemon exists on 192.168.1.0/24 .

and... I tried to install daemon on my linux-PC (im new to linux as a daily driver) what does this mean "your parameters"

ok so I have server and daemon working. but... daemon cannot see normal host network... even though daemon is on HOST network. Unraid HOST is showing the 192.168.1.12 interface, the subnet br0 192.168.1.0/24 no errors in logs for server, nor daemon daemon in server shows "no" interfaces this time. previously with other settings had something here. but still no network devices discovered then either. just WARN (seems irrelevant) 2025-12-24T00:20:33.114083Z INFO scanopy::daemon::discovery::manager: Discovery completed successfully 2025-12-24T00:20:33.114462Z WARN scanopy::daemon::discovery::service::network: Skipping 172.31.200.0/24 with CIDR 172.31.200.0/24, docker bridge subnets are scanning in docker discovery 2025-12-24T00:20:33.114474Z WARN scanopy::daemon::discovery::service::network: Skipping 172.21.0.0/16 with CIDR 172.21.0.0/16, docker bridge subnets are scanning in docker discovery 2025-12-24T00:20:33.114480Z WARN scanopy::daemon::discovery::service::network: Skipping 172.17.0.0/16 with CIDR 172.17.0.0/16, docker bridge subnets are scanning in docker discovery 2025-12-24T00:20:33.114484Z WARN scanopy::daemon::discovery::service::network: Skipping 172.20.0.0/16 with CIDR 172.20.0.0/16, docker bridge subnets are scanning in docker discovery 2025-12-24T00:20:33.114489Z WARN scanopy::daemon::discovery::service::network: Skipping 172.19.0.0/16 with CIDR 172.19.0.0/16, docker bridge subnets are scanning in docker discovery 2025-12-24T00:20:33.114494Z WARN scanopy::daemon::discovery::service::network: Skipping 172.18.0.0/16 with CIDR 172.18.0.0/16, docker bridge subnets are scanning in docker discovery 2025-12-24T00:20:33.119982Z INFO scanopy::daemon::discovery::service::base: Starting Network Discovery discovery session aacb2573-22c0-42bf-b444-44086326803c Then when Netowork scan starts: bf-b444-44086326803c discovery_type=Network { subnet_ids: None, host_naming_fallback: BestService } 2025-12-24T00:20:33.160259Z INFO scanopy::daemon::discovery::service::network: Phase 1: Checking host responsiveness total_ips=768 interfaced_ips=512 non_interfaced_ips=256 2025-12-24T00:20:33.163347Z INFO scanopy::daemon::discovery::service::network: Phase 1a: ARP scanning interfaced subnets count=512 concurrency=50 2025-12-24T00:20:44.150887Z INFO scanopy::daemon::runtime::service: Heartbeat sent daemon_id=e4383ce9-08c5-46ab-8597-d4e3450644a3 2025-12-24T00:21:03.140851Z INFO scanopy::daemon::shared::handlers: Received healthcheck request 2025-12-24T00:21:14.146151Z INFO scanopy::daemon::runtime::service: Heartbeat sent daemon_id=e4383ce9-08c5-46ab-8597-d4e3450644a3 2025-12-24T00:21:33.206850Z INFO scanopy::daemon::shared::handlers: Received healthcheck request 2025-12-24T00:21:44.145211Z INFO scanopy::daemon::runtime::service: Heartbeat sent daemon_id=e4383ce9-08c5-46ab-8597-d4e3450644a3 2025-12-24T00:22:03.279161Z INFO scanopy::daemon::shared::handlers: Received healthcheck request 5 min later no error in log

In the windows official app there is a setting to "serve all devices (including from clients)" This option is not available in the docker... Can this be added? It would be much easer to run a single OpenRGB server for all my PCs rather than run a server on each one, for connection to Home Assistant.

you can always re-open the logs after the container has shut down for the info you missed before the log window closed on you. But as previous user mentioned

the webhook variable in the template ended up making me bang my head against the desk for about 24 hours until I realized my production webhook url was not my server IP. I had set a base URL to expose the docker to receive google authentication, it changed my test URL to my domain name, but kept the production URL as an IP. but WRONG IP !!! I was trying to add other docker URL variables to fix the "issue" when I saw your existing variable set to 192.168.1.161 Im not sure if I overlooked this variable during setup, or if I assumed it was set to this IP for a reason... without remembering I have this IP reserved for something in my house. It is bad practice to hardcode IP addresses in the unraid docker templates. best practice is to leave blank for user to fill in, or use localhost, as it is usually the most likely choice. Thanks for setting up the template regardless!

I was just looking into this too

Did you get this figured out?

Reading through the forums over the past 7 years I know I'm not the only one that this happens to

1. I have been running unrade for 7 years and I'm on my 8th USB flash drive. I have tried different brands and types with and without LEDs... I lose one flash drive per year using unraid. I have had zero other hardware failures in the same amount of time. So no, it's not the same. 2. A system can have more than one hot spare

I have 2 issues that worry me if I were to pass away... 1. USB flash is likely to die within a year. My USB dies every year. 2. No "hot-spare" feature to auto rebuild a failed drive. With these 2 unaddressed issues, my server, my legacy, would not survive without intervention for long after my death. This worries me.