Fragsrus

Let me start this post by saying I did search through this thread, and while I did see plenty of similar posts, nothing exactly covers what I have been troubleshooting. I am not an expert in any of this, just some guy playing around with techy stuff, and so I am using Claude Code to help me work through it and it was able to find a workaround. I hope I don't get too much hate from the anti-AI crowd. While working through the problems I tried to document as best I could and had Claude write up an analysis. Basically, everything had been working fine. I installed the Tailscale plugin, added my server and laptop to the Tailscale network, and there were no issues. I even still had LAN access from my desktop without it being in the Tailscale network. That all changed when I upgraded the GPU in my server which required changing to UEFI boot, which apparently changes things in the boot order. Suddenly, I had no access to Unraid, WebGUI or SSH, from the LAN, without running through Tailscale. I had it fixed initially by adding a delay to tailscale so it let Unraid settle before attempting to do it's thing. This workaround broke with the latest Unraid version update. Now, I have my system monitoring for LAN bindings for nginx and SSH and restarting the service if needed. This "fix" is currently holding steady, but I figured it was past time to get help from a real person, especially since Claude seems confident this is a plugin issue. Here is the lengthy, detailed write-up Claude created based on my troubleshooting and documentation: # Tailscale plugin causes WebGUI and SSH to become inaccessible after array autostart (Unraid 7.2.x) **Platform:** Unraid 7.2.3 / 7.2.4 **Plugin:** Tailscale (community plugin) **Other relevant containers:** NginxProxyManager --- ## Summary After array autostart, the Unraid WebGUI and SSH become inaccessible on the LAN. The issue is caused by a race condition between Tailscale restarting during the boot sequence and a brief window in which the LAN bridge interface br0) has no IP address. When Tailscale restarts, it triggers emhttpd to regenerate nginx and SSH configurations — and if that regeneration happens while br0 is temporarily IP-less, both services are configured to listen only on Tailscale/WireGuard IPs, not the LAN IP. The issue was first introduced by a Legacy→UEFI BIOS conversion (required for a GPU upgrade), which changed boot initialization timing and exposed a pre-existing race condition. A workaround was found that overrode the Tailscale plugin's array_started event hook to delay the restart by 45 seconds, which successfully resolved the issue on Unraid 7.2.3. After updating to Unraid 7.2.4, the issue returned. Investigation revealed that 7.2.4's changed boot sequence now fires the plugin's stopped event hook earlier in the boot process — before the array_started override even runs — triggering a second, earlier Tailscale restart that hits the disruption window. The previous fix had no effect on this new trigger. --- ## Root Cause (Full Chain) 1. Array autostart fires → Docker containers start, including NginxProxyManager 2. NginxProxyManager startup causes avahi-daemon to briefly leave br0 — the interface appears IP-less for approximately 11 seconds 3. During this window, Tailscale restarts (triggered by either the array_started or stopped event hook in /usr/local/emhttp/plugins/tailscale/event/) 4. Tailscale's restart causes tailscale1 to come up, which triggers emhttpd to regenerate /etc/nginx/conf.d/servers.conf and /etc/ssh/sshd_config 5. The regeneration runs while br0 has no IP — br0 is excluded from both configs 6. nginx and sshd reload with configs that only include WireGuard/Tailscale IPs — WebGUI and SSH become inaccessible on the LAN **The plugin's network-extra.cfg include_interfaces field does not prevent this** because the config generation code validates that the interface has an active IP at the time of regeneration. If br0 is momentarily IP-less, it is excluded regardless of the setting. --- ## Why This Is a Plugin Issue The plugin should not be able to cause LAN-facing services (nginx, sshd) to lose their LAN bindings. Specifically: - The array_started event hook fires a Tailscale restart with only a 5-second delay, which is not enough to clear the NginxProxyManager startup disruption window - In Unraid 7.2.4, a new stopped event hook fires an additional restart even earlier in the boot sequence, before the array has fully started - The include_interfaces configuration in network-extra.cfg is ineffective when the interface temporarily has no IP, meaning there is no reliable way for users to protect their LAN bindings from being dropped A robust fix would require the plugin to either: - Not trigger nginx/SSH config regeneration during interface disruption windows, or - Retain explicitly configured interfaces in the generated configs regardless of their momentary IP state --- ## Workaround Since the plugin's event system is the trigger and the fix needs to survive plugin updates, the workaround avoids touching plugin files entirely. Instead, a background watchdog runs from /boot/config/go (on the FAT32 flash drive — never touched by OS or plugin updates) that detects when either service loses its LAN binding and corrects it. */boot/config/go:** ```bash #!/bin/bash (while true; do sleep 15 IP=$(ip addr show br0 2>/dev/null|awk '/inet /{print $2}'|cut -d/ -f1) [ -z "$IP" ] && continue ss -tlnp|grep nginx|grep -q "$IP"||/etc/rc.d/rc.nginx update ss -tlnp|grep sshd|grep -q "$IP"||/etc/rc.d/rc.sshd update done)& # Start the Management Utility /usr/local/sbin/emhttp ``` Every 15 seconds, the watchdog: 1. Gets br0's current IP — if br0 has no IP, skips (avoids unnecessary reloads during the disruption window itself) 2. Checks whether nginx is listening on that IP — if not, runs rc.nginx update to regenerate the config and reload nginx 3. Checks whether sshd is listening on that IP — if not, runs rc.sshd update to regenerate the config and restart sshd This approach has negligible performance impact (two kernel memory reads every 15 seconds) and survives all Unraid OS and Tailscale plugin updates since it does not depend on any plugin internals. --- ## Environment - Unraid 7.2.4 - Tailscale community plugin (latest as of 2026-03-04) - NginxProxyManager running as a Docker container with array autostart enabled - UEFI boot mode, Above 4G Decoding enabled - RTX 2070 GPU

I updated to 6.8.1 the other day. Not sure on the exact day but it was a good bit before the issue occurred. It really seemed that using the restart button within Sonarr is was triggered the crash. In the end, it seems to have been an issue with Sonarr itself and not so much your container. So if the issue comes up again I will contact their support instead.

Can disregard my previous post, I figured it out. For whatever reason, I needed to completely wipe out my appdata/binhex-sonarr folder and then restore from a backup. Not exactly sure what was causing the problem but it is fully restored now.

I am hoping someone here can help me. Everything has been working fine now for over a year. However, today Sonarr just crashed and will not come back. I was in the WebUI when I noticed an error message stating Sonarr could not connect with Deluge. I had just restarted the Deluge container since it had stopped responding since the last update. So I used the restart option within the webui. Sonarr never came back up. After about 5 minutes I decided to restart the container from the Unraid Docker console. Still, no Sonarr. I decide to remove the container, first without removing the image and then later with removing it, and then reinstalling the container. Still no Sonarr! I tried re-installing the container both using the "user-template" and from scratch through the apps tab. What can I do to fix this? Attached is the most recent log file with an entry showing "2020-01-17 18:04:48,414 DEBG 'sonarr' stdout output: [Fatal] ConsoleApp: EPIC FAIL!" Sonarr Log.txt