On Unraid 7.3.1 version with tailscale plugin version 2026.05.24.1252, was getting API not responding - nginx errors. The errors were being caused tailscale plugin. Once removed, no more nginx errors. Any suggestions please?

https://product.unraid.net/p/7-3-1-webgui-api-offline-after-reboot-array-shows-stopped-offline

23 hours ago, snailtrails said:

On Unraid 7.3.1 version with tailscale plugin version 2026.05.24.1252, was getting API not responding - nginx errors. The errors were being caused tailscale plugin. Once removed, no more nginx errors. Any suggestions please?

https://product.unraid.net/p/7-3-1-webgui-api-offline-after-reboot-array-shows-stopped-offline

I have it running on 7.3.1 on my production and multiple test servers. I’ll need more details/diagnostics to be able to understand what’s happening.

@EDACerton

Longtime lurker, and I had reported this issue about 6 months ago and provided logs, but had not been able to narrow down the root cause. (I also wasn't using AI so much back then).
Today I exported the diagnostic logs and asked Claude to analyze and this is what it came up with:

Bug Report: Tailscale plugin breaks nginx daily due to stale MagicDNS hostname and missing reload_services call

Environment: Unraid 7.2.5, Tailscale plugin (latest), tailscaled v1.98.3

Symptom: After a few minutes of working fine following a manual restart, Tailscale connections drop. The plugin must be manually restarted to restore access. This repeats every day around the same time.

Root Cause (from log analysis): There are two bugs that combine to cause the failure:

Bug 1 — Stale hostname in cert commands. My tailnet's MagicDNS suffix is [tailnet-name].ts.net, so my correct FQDN is [hostname].[tailnet-name].ts.net. However, both daily.php and tailscale-watcher.php are hardcoded to request certs for [hostname].magicdns.ts.net — the old-style MagicDNS format that no longer matches my tailnet. The cert command fails silently every morning. The plugin should derive the hostname dynamically from the live Tailscale state (which correctly reports the current DNS name) rather than using a cached/hardcoded value.

Bug 2 — daily.php does not call reload_services after running tailscale cert. On startup, tailscale-watcher.php correctly calls reload_services after the cert command, which causes nginx to pick up the new cert and bind properly to the Tailscale IP. However, daily.php runs tailscale cert at ~4:41 AM every day and then exits without calling reload_services. This causes nginx to lose its listener on the Tailscale IP (100.x.x.x:80), after which the watcher enters an infinite nginx restart loop that never self-recovers.

Evidence from logs (tailscale-utils.log):

On startup (works):

tailscale-watcher.php: exec: tailscale cert ... [hostname].magicdns.ts.net
tailscale-watcher.php: exec: /usr/local/emhttp/webGui/scripts/reload_services  ← present

On daily timer (breaks):

daily.php: exec: tailscale cert ... [hostname].magicdns.ts.net
← reload_services never called
tailscale-watcher.php: WebGUI not listening on 100.x.x.x:80, terminating and restarting
← loops every 2 minutes indefinitely

Requested fixes:

1. Derive the cert hostname dynamically from tailscale status or the local API rather than using a hardcoded/cached value, so it stays correct if the tailnet MagicDNS suffix changes.

2. Add a reload_services call in daily.php after tailscale cert completes, matching the behavior of tailscale-watcher.php on startup.

I am having a heck of a time with tailscale. I am only a few days into unraid, but a month into ugreen before their update wiped out my setup and got me here. The change is great, but I am so lost. I am installed on my NVME boot/cache, and at first I had a TS not ready messages. I moved the TS files from boot to the NVME, I can't get the TS IP's to connect local or remotely. I wiped it, used a docker install. It is the same. Any help is appreciated. I don't think I have made any changes that should affect this. I only have immich, jellyfin type apps, and have not messed with ports or anything wild. I can get everything working, but the IP connection and they are pingable, just not reachable. hours and hours into trouble shooting circles.

Thanks for any efforts.

I have been running the Tailscale plugin alongside Nginx Proxy Manager (NPM) for a year. However, since a few weeks these conflict with eachother.

When trying to start the NPM docker I now get an error saying:

docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint NginxProxyManager (d9ecadce4b2c6c3d7a2561817a1b4303fa2bb679edbcd4db924629c4618916a2): failed to bind host port 0.0.0.0:443/tcp: address already in use

This 443 port is used by Tailscale. When I deinstall the Tailscale plugin, the NPM docker is starting correctly.

What has changed and how to fix this?

Edited July 7Jul 7 by monsieurrouge

I cannot install tailscale

I get this Network failure error

any idea how to fix it?

thanks

Downloading plugin
plugin: installing: tailscale.plg
Executing hook script: CA_preHook
Clearing Community Applications plugin cache
Executing hook script: pre_plugin_checks


plugin: downloading: unraid-tailscale-utils-2026.08.06.0154-noarch-1.txz ...
plugin: unraid-tailscale-utils-2026.08.06.0154-noarch-1.txz download failure: Network failure
Executing hook script: CA_postHook
Clearing Community Applications plugin cache
Executing hook script: post_plugin_checks
Plugin installed

19 hours ago, DuckWaze said:

Hello,

I have a strange issue with my Tailscale plugin on Unraid. After updating yesterday to the newest Unraid version (7.3.2) Not sure of the update have anything to do with it, but just F.Y.I. and updating the plugins, I can no longer reach the Unraid web interface via its Tailscale IP. Locally, everything works fine — the issue is only when trying to access it remotely through Tailscale.

What I have checked:

• The Tailscale node "Unraid" is online and pingable.

• I can ping from the Unraid server (via Tailscale) to my notebook.

• From the Tailscale admin console, I can ping all devices.

• Restarting Tailscale on the server — no effect.

• Deleting Tailscale on the server and reinstalling — no effect.

• Full reset of the Tailscale plugin and re-authenticating — no effect.

A second strange issue is that all my dockers that are exposed (Wordpress, WikiJS, Ect) also don't work. Not related to this topic but just F.Y.I

I am using Cloudflare, Gandhi & Bunny.net for different domains, checked the WAN on al of those and there a correct neither one docker is external working by domain name.

My immich docker is only accable by tialscale IP of the unraid server, again i can ping the tailscale IP from the phone, but Immich cant reach the IP.

I check the router and did even a factory reset, with no effect.

Any help would be appreciated!

unraid-diagnostics-20260806-2023.zip

The Tailscale plugin webui works normal or not? can other device reached to the unraid machine?

8 hours ago, trevor.ostrander said:

I cannot install tailscale

I get this Network failure error

any idea how to fix it?

thanks

Downloading plugin
plugin: installing: tailscale.plg
Executing hook script: CA_preHook
Clearing Community Applications plugin cache
Executing hook script: pre_plugin_checks


plugin: downloading: unraid-tailscale-utils-2026.08.06.0154-noarch-1.txz ...
plugin: unraid-tailscale-utils-2026.08.06.0154-noarch-1.txz download failure: Network failure
Executing hook script: CA_postHook
Clearing Community Applications plugin cache
Executing hook script: post_plugin_checks
Plugin installed

Have you checked your network to GitHub?

On 5/29/2026 at 11:22 AM, EDACerton said:

I have it running on 7.3.1 on my production and multiple test servers. I’ll need more details/diagnostics to be able to understand what’s happening.

Diagnostics without tailscale plugin installed (unraid webUI works fine)

Diagnostics with tailscale plug installed (unraid webui is broken, hard to export diagnostics, had to run the SSH command manually, cant see webuUI shares, etc).

UR1-tailscale-diag-20260828-134033.zipur1-diagnostics-20260828-1340 (with tailscale plugin).zipur1-diagnostics-20260828-1329 (without tailscale plugin) .zip

Edited August 28Aug 28 by snailtrails
edit, moved to general support. Tailscale plugin works fine, it just seems to interfer with unraid GUI somehow.

Unsure if this was asked before, but is it possible for this plugin to be set up in a way that Tailscale releases can be installed separately from the plugin itself? basically just a way for me to update when updates are ready and not depend on the plugin maintainer (plus it would take that work away from them.

Hello, there's issues running both TREK (and beszel?) once tailscale plugin is enabled.

Container: mauriceboe/trek (TREK travel planner app)

Issue: Enabling "Use Tailscale" on this container causes the Tailscale Unraid Docker Hook to throw a syntax error immediately after successful auth, and the container's actual app process never starts — it hangs on a "Press ANY KEY to close this window" prompt (no TTY available in Docker, so it hangs forever and the container shows red/failed).

Suspected cause: The container's Dockerfile CMD is a compound shell script (does a file-existence validation with if [ ... ]; then ... fi, then drops privileges via gosu node and execs the Node app). It looks like the Tailscale hook script tries to eval this original CMD when handing off after Tailscale setup, and chokes on the embedded if/then block — likely a quoting issue in how the hook captures/re-runs the image's original entrypoint/CMD.

Container's actual Dockerfile ENTRYPOINT/CMD for reference:

ENTRYPOINT ["dumb-init", "--"]

CMD ["sh", "-c", "if [ ! -f /app/server/dist/index.js ] || [ ! -d /app/node_modules/tsconfig-paths ]; then echo 'FATAL: TREK application files are missing from the image.'; ...; exit 1; fi; chown -R node:node /app/data /app/uploads 2>/dev/null || true; cd /app/server && exec gosu node node --require tsconfig-paths/register dist/index.js"]

I'm very sorry for what I know is probably a rather basic question, but I need a little help here please...
I have Tailscale on my unraid server, and all appears to be working well. I can access my shares via Tailnet IP, no problem.
What I'd like to be able to do, is access another physical machine on the same LAN as the server, through TS, from a remote PC.
Is this super basic, complex, impossible?
If it matters, the device I want to access is my pfsense router/firewall.
Its IP is 162.168.10.1
My server is 192.168.10.10

Can anyone tell me what settings I need to change, and where, to make the pfsense accessible remotely?
I kinda thought I had done this on my home tailnet using the "Allow Tailscale Subnets" switch, but maybe not.

I've noticed an odd inconsistency about how a connection through this plugin seems to handle traffic to a Docker container. (I am not using the Docker integration, so I think this is the correct topic to post in despite Docker being relevant).

Here are the only Tailscale settings that are enabled in Unraid: Auto Update, Run as Exit Node, Allow LAN Access while using Exit Node. All others are disabled or blank.

My setup is I have all my containers behind an Nginx proxy manager container that exposes ports 80 and 443 and forwards traffic to other containers on different subnets; these other containers expose no ports. Anything that is IMO more likely to have security vulnerabilities is behind ACLs with an IP whitelist with fallback to a username/password as a very basic safety precaution.

Despite listing the Tailscale IP in the ACLs I keep getting the nginx username/password prompt when accessing the server via Tailscale (it does not occur when accessing the server locally). Looking into the Nginx logs the client IP is listed as the gateway for the first listed Docker network (For me this is both the first alphabetically and the last numerically so I'm not 100% sure on the logic for the selection, but I don't think that matters for the problem).

Upon inspecting the query received by Nginx and playing around with another container that echos HTTP queries I found the following for requests made via Tailscale:

1) If a container exposes ports and has no container networks the correct Tailscale IP will be used in the "ip" field of the query.

2) If a container exposes ports and has any container network the "ip" field will be the gateway IP of one of those networks, additionally the Tailscale IP appears nowhere in the query (like in an XFF header) so there is zero mechanism to retrieve the actual origin IP.

Any ideas why this occurs? I had a quick look at the plugin source on Github but it seems like largely a wrapper around Tailscale so maybe it's an upstream issue. I setup a Tailscale and docker on an ubuntu virtual machine and it doesn't display this issue so unlikely to be an upstream issue.

I also should clarify the container networks that result in the behaviour being triggered are all "external" networks, non-external bridge networks do not result in this behaviour.

Edited September 4Sep 4 by taranf

Recently, I can't SSH to a test server over Tailscale unless I restart sshd by hand first. The WebGUI over Tailscale still works. tailscale1 is listed in include_interfaces. Unraid 7.3.2, plugin 2026.09.12.2000 (Tailscale 1.102.4). Diagnostics attached.

What the logs show at boot:

1. sshd starts and listens only on the LAN IPs, because tailscale1 doesn't exist yet.

2. create_network_ini queues the usual delayed service reload (update_services 20). That job runs about 2 seconds before tailscale1 gets its address, so rc.sshd update finds nothing to change.

3. The watcher then logs Tailscale IP detected, applying configuration and runs /usr/local/emhttp/webGui/scripts/reload_services.

4. reload_services only works when an at job is already queued. If the queue is empty, it exits 0 silently. By now the queue is empty, so nothing is reloaded and sshd never binds to the Tailscale IPs.

The WebGUI isn't affected because checkWebgui() restarts nginx when it isn't listening on the Tailscale IP. sshd, Samba and NFS have no such check.

I think this could always have been a race and was hidden by timing until now: if Tailscale got its IP inside the OS's 20-second window, that reload picked it up. On this server Tailscale now comes up a little later, so the window is missed.

Possible fix: in System::restartSystemServices() (and the other RESTART_COMMAND call sites), call /usr/local/emhttp/webGui/scripts/update_services instead of reload_services. update_services queues a job and then runs the reload, which is how the OS's own callers (create_network_ini, rc.wireless, NetworkExtra.page) do it.

Workaround for now: after boot, run /etc/rc.d/rc.sshd update, or restart sshd.

test1-diagnostics-20261003-1025.zip