EDACerton

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.

That's odd.... if you can post Tailscale diagnostics from both servers, that would be helpful. (There's a diagnostics button in the Tailscale plugin settings -- use that, not the normal system diagnostics.)

Thanks for the backup However, to answer the original question from @Comfuzio : switch to the "Preview" version of the plugin. I updated that one within hours of the last release (right after I did my local testing). The "regular" version of the plugin gets the update around a week after the preview version does.

For someone doing a handful of licenses, you're probably right... but if someone was reselling in substantial quantities, it wouldn't be difficult to spot.

FYI for anyone reading, doing this is against the Unraid policies: https://unraid.net/policies

You should be able to run this from the Unraid CLI: tailscale set --exit-node-allow-lan-access I just tried that on one of my test instances, and it worked correctly.

1. The "core" of Unraid (the main array) isn't open source, and there aren't any "equals" to it in the OSS world (there are things that are similar, but nothing that has the whole feature set to my knowledge). 2. Even if "similar" is good enough, configuring an OSS-based system is still more complicated to deploy/configure/monitor/maintain. 3. Donations "just because people like the product as it is" sounds nice, but in practice very few people actually do that. (Simple example, because I know the numbers: I created and maintain the Tailscale plugin for Unraid. There are around 6,000 active installs right now. Of those 6,000 installs, I've had 3 people send anything via the donation button - 0.05%. I'm not complaining, just pointing out how things work in reality.)