EDACerton

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.

Please generate diagnostics from inside the plugin settings and post on the support thread. Also, a better explanation of "plugin is crashing my server overnight" would be helpful... that could mean many things. Questions to consider/answer in your post over there: Does the server freeze (i.e., can you do anything at the console)? Can you access WebGUI? Can you access shares? Can you access Docker containers? What happens if you use local IP? What happens if you use Tailscale IP?

There's already discussion happening on how to support this better.... we're over a year away from this being a potential issue, so there's plenty of time to solve that problem.

My comment is valid with the latest copy of the privacy policy... the "callback" data is transmitted to the remote server as part of the query string. From the privacy policy (I just copied this section seconds ago): A devtools network capture in a browser shows that the server details are leaving the local browser by being transmitted to account.unraid.net when the "Update OS" button is clicked in the WebGUI. This behavior contradicts the statement above.

Diagnostics from inside the plugin settings please.

It looks like the connection is starting, but the server with UD seems to be terminating the connection ("got RST by peer") when it gets a response: You might want to check logs on that server to see if that helps show what it's unhappy about.

The IP would be a better choice here... you'll lose the logs from while Tailscale isn't running, but once Tailscale comes up it should work. As you've seen, rsyslog won't be able to resolve a MagicDNS name on boot.

Thanks for the additional clarity on this. Perhaps I'm splitting hairs here, but I do think this is important: Cloudflare Pages might be a "serverless" technology, but it's still a "cloud-based server". Cloudflare Pages run Cloudflare Workers, which can be used to store data via numerous means (in fact, Cloudflare Workers is the system that I use for tracking the number of installs of the Tailscale plugin, although with the plugin I specifically avoid transmitting identifiable information). In practice, the server details on the Account app are being sent to a "cloud-based server". It might be that the server-side infrastructure doesn't do anything with those details... but the privacy issue here is that it could. I can see that the data is being transmitted from watching the network traffic generated by my browser, and once that information is sent to the remote server I lose control of it -- and notably here, it's being transmitted when the privacy policy explicitly says that is not happening. (Also: why transmit data to a remote server that isn't intended to be used by that server? There are other ways to get information between web applications, like CORS.)

It seems like there’s something stuck that’s making Tailscale try to open port 80. You could try this: 1. Delete the related entries from the Tailscale admin console. 2. Erase the plugin configuration (there’s a button in the plugin settings, I think it’s in advanced mode.) 3. Log back in to Tailscale via the plugin.

I can see where Tailscale is starting to listen on port 80, but that's not something that it would ordinarily do on its own. Have you run any CLI commands to set up "extra" features of Tailscale, like "tailscale serve" or "tailscale funnel"?

Adding guidance or functionality for advertised routes isn't in my plans for the plugin at this point. That functionality is now provided via Tailscale's built-in web interface.

Tailscale wouldn't usually open up port 80 on its own. Can you run diagnostics from inside the Tailscale settings?

Thanks for the update/FAQ. I do have a question though about the data that is being sent. In the FAQ, I noticed this section: Is this a description of how this is supposed to work today, or how it will work in a future release? I ask because I tested this on one of my instances and it does not appear to behave this way... it's sending more than the described data to account.unraid.net: User clicks Update OS button. Local server generates long, URL-encoded blob containing the data described in this post. The browser is redirected to https://account.unraid.net/c?data=blob-of-urlencoded-data As a result, all of the data is sent to account.unraid.net, where it is presumably logged (since it's in the URL, and not POST) and could also be accessed programmatically. It's not just staying within the browser session.

Any news on the privacy questions from earlier in the thread?

I looked through the log files, and I don't see anything that looks problematic from a connection standpoint. It seems like you had some trouble connecting to the coordination server on 2/22 and 2/23, but that seems to be OK now: However, what I do find weird is that Tailscale is reporting that the two servers have never exchanged data: Are those the IP addresses that you've been trying to ping? I've previously pinged Unraid nodes from each other, but I'll do a double-check on some of my test boxes to make certain that there isn't something weird going on with Tailscale/the plugin. In the meantime, it might also be worth making a post over at r/Tailscale; the folks over there might be able to help. Edit: I was able to ping between Unraid nodes on both my "main" tailnet and on my "test" tailnet.

The beta isn't available yet.

Feature request: Unraid on a 1.44MB floppy disk.

For what it's worth, we're over a year away from this being a possible problem, and folks are already looking at how the app/plugin system can accommodate users that decide not to update.