EDACerton

There's a misconception here. The base tailscale/tailscaled binaries that are installed via the plugin are open-source (they come from the repo that I linked, I've even submitted PRs for them to make things work better on Unraid). The Mac/Windows/iOS GUIs aren't open-source, nor is the control server (although there is Headscale as an alternative there, which does work with the plugin). None of those components are installed on Unraid.

FYI -- the Tailscale comment here is not accurate, all components are open source: unraid-tailscale (main plugin): https://github.com/dkaser/unraid-tailscale unraid-tailscale-utils (script package): https://github.com/dkaser/unraid-tailscale-utils unraid-plugin-diagnostics (custom diagnostics generator): https://github.com/dkaser/unraid-plugin-diagnostics tailscale: https://github.com/tailscale/tailscale

Did you configure a subnet router for that network? By default, if you're trying to remotely connect to a Tailscale device, you have to use the Tailscale IP, not the local IP. If you configure a subnet router, however, you can use the local IP remotely as well.

Adding a "delay start" isn't something that I plan to add to the plugin settings. Reason: using arbitrary delay values to solve race conditions is generally bad and should be avoided. Secondary reason: the User Scripts plugin can do what you're trying to accomplish, and since this is technically not a Tailscale problem I'd rather not start trying to build fixes into the plugin for other plugins/containers. Ideally, you'd want to build something smart that would run "At startup of array" which would: Wait for the container you want to be started (hint), then Restart Tailscale using the script at /usr/local/emhttp/plugins/tailscale/restart.sh Alternately, you could just build a simple wait by doing this in an "at startup of array" script (change the 60 seconds as needed): sleep 60 /usr/local/emhttp/plugins/tailscale/restart.sh

Are you trying to use the Tailscale IP or the LAN IP?

This isn’t something that I can really help with, you’d have to refer to the documentation for the containers to see how to replace the certificate that each uses.

Tailscale CPU load is usually traffic-dependent; how much are you sending via Tailscale? Otherwise, diagnostics would be helpful to see if there's something else going on.

I think I posted to you on Reddit as well... it looks like your server can't contact the Tailscale control servers.

You don’t have the Tailscale plugin installed. You’re probably running the docker container.

Did you run the restart command? That's necessary to get the WebGUI to start listening on the Tailscale IP.

There's nothing in the Tailscale logs that indicates an issue. I'd recommend trying to get some tailscale status output from both the server and a client while you're seeing a slow transfer, that might shed some light on the problem.

Run this from SSH: tailscale up Then, once you've logged in and you see the device in the Tailscale console: /usr/local/emhttp/plugins/tailscale/restart.sh

/usr/local/emhttp/plugins/tailscale/restart.sh

Yep, that's it. Install plugin, sign in to Tailscale through the WebGUI,

You are correct, switching from the docker to the plugin will require disconnecting Tailscale... the two fight each other if they are running at the same time. If you *really* wanted to try to do it remotely (not that I would recommend it), it might be possible if you get creative with the Tailscale admin console: Turn on device approval for your tailnet (Settings -> Device Management). Install the plugin and log in, but don't approve it yet. Stop the docker container (this will drop your connection to the server, but you should get it back in the next step) Approve the plugin connection in the Tailscale console. The catch to this being (of course) that if anything goes wrong you've just lost your remote connection until you have local access again. Managing remote connections in-band is always a fun process

(Stopping by because I saw the Tailscale mention and decided to check the diagnostics to make sure it wasn't a plugin issue) The good news: your server restarts a lot faster than you think. The bad news: your server is definitely restarting. Given that there's nothing in the syslog indicating why the reboot is happening, I would go back to what JorgeB indicated previously -- this seems like a hardware problem.

There used to be a button in the Tailscale web interface to do the reauth, but it looks like that is gone. I'll have to get in touch with the Tailscale folks on that one. In the meantime, you could disable key expiration via the Tailscale admin console, or use the CLI to do a reauth: tailscale up --force-reauth

This has never been required with the plugin.

That’s because in most cases it’s not a restriction (as you mention, particularly for Docker containers). For plugin developers, the Unraid version is more important.

This is normal. Docker containers don't show up independently in the Tailscale console; they're just treated as a part of the server. If you're using a bridge Docker network (the usual default), you can just connect to tailscaleIP:dockerPort just like you would with the local IP. If you're using br0/etc. networks in Docker (so that your containers get a separate IP address on your LAN), you'll have to do extra work to make them available via Tailscale. There are generally two ways to do this: Use a subnet router to make the LAN IPs accessible over Tailscale (this is what basically everyone in that situation does), or Configure Tailscale "sidecars" for each of your br0 containers.

Your Tailscale state appears to be corrupt. Delete the server from the Tailscale admin console. Erase the plugin configuration (there’s a button in the plugin settings, I think it’s in advanced mode.) Log back in to Tailscale via the plugin.

I can see incoming pings and WebGUI traffic in the Tailscale log. I'd probably have to see Tailscale logs from your clients to see if there's anything interesting there. It might just be easier to reset the config on your server, though. Here's what I'd recommend if you want to try that: Delete the Unraid server from the Tailscale admin console. Erase the plugin configuration (there’s a button in the plugin settings, I think it’s in advanced mode.) Reboot your Unraid server. Log back in to Tailscale via the plugin.

From the Tailscale side, everything looks fine. If you've been accessing the WebGUI from your phone, you might be accidentally crashing the WebGUI. There's been a known issue with the WebGUI and mobile devices (in particular Android devices)... essentially, if a tab with the WebGUI gets left open (even in the background), it eventually causes problems for the server.

You need to turn NetBIOS off in SMB settings. Do you access the WebGUI via mobile device (phone/tablet)? I see some errors in the log that remind me of problems that occur when mobile devices have WebGUI tabs open for long periods of time. It seems like Tailscale DNS is enabled on both servers... I recommend that folks turn that off because it's not usually needed on servers.

If you want the latest update as soon as Tailscale releases it, install the preview version of the plugin from CA (you don't have to uninstall the existing plugin, it will replace it on install). I released a preview update the same day that Tailscale released the last update. I'll probably be pushing that version to the main plugin tonight. For everyone else: I promise, I haven't forgotten you, I've just been very busy lately, I'm going to try to catch up this evening.