EDACerton

This uses fileactivity-watcher (guessing might just be truncated on whatever you’re looking at?) It shouldn’t interfere with the array stopping… I run it on my servers and have never seen that happen. I’d be curious to know what it’s stuck on if that’s happening (either via lsof or the open files plugin)

It looks like either something is blocking most (but maybe not all?) of the Tailscale control plane, which is causing it to have issues: 2025/11/12 04:59:40 trying bootstrapDNS("derp1g.tailscale.com", "209.aaa.aaa.120") for "log.tailscale.com" ... 2025/11/12 04:59:42 bootstrapDNS("derp1g.tailscale.com", "209.aaa.aaa.120") for "log.tailscale.com" error: Get "https://derp1g.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp 209.aaa.aaa.120:443: connect: no route to host 2025/11/12 04:59:42 trying bootstrapDNS("derp8d.tailscale.com", "2a03:b0c0:1:d0::e08:e001") for "log.tailscale.com" ... 2025/11/12 04:59:42 bootstrapDNS("derp8d.tailscale.com", "2a03:b0c0:1:d0::e08:e001") for "log.tailscale.com" error: Get "https://derp8d.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2a03:b0c0:1:d0::e08:e001]:443: connect: network is unreachable 2025/11/12 04:59:42 trying bootstrapDNS("derp8f.tailscale.com", "176.aaa.aaa.183") for "log.tailscale.com" ... 2025/11/12 04:59:43 health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Chicago' relay server. Your Internet connection might be down, or the server might be temporarily unavailable. 2025/11/12 04:59:43 health: connectivity impacted; triggering captive portal detection 2025/11/12 04:59:43 magicsock: [0xc0041be000] derp.Recv(derp-12): derphttp.Client.Recv connect to region 12 (ord): context deadline exceeded 2025/11/12 04:59:43 health(warnable=no-derp-connection): ok 2025/11/12 04:59:45 bootstrapDNS("derp8f.tailscale.com", "176.aaa.aaa.183") for "log.tailscale.com" error: Get "https://derp8f.tailscale.com/bootstrap-dns?q=log.tailscale.com": context deadline exceeded 2025/11/12 04:59:45 trying bootstrapDNS("derp7e.tailscale.com", "2600:3c18::2000:60ff:fe0f:6e83") for "log.tailscale.com" ... 2025/11/12 04:59:45 bootstrapDNS("derp7e.tailscale.com", "2600:3c18::2000:60ff:fe0f:6e83") for "log.tailscale.com" error: Get "https://derp7e.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2600:3c18::2000:60ff:fe0f:6e83]:443: connect: network is unreachable 2025/11/12 04:59:45 trying bootstrapDNS("derp21c.tailscale.com", "162.aaa.aaa.215") for "log.tailscale.com" ... 2025/11/12 04:59:46 netcheck: netcheck: UDP is blocked, trying HTTPS 2025/11/12 04:59:46 netcheck: UDP is blocked, trying ICMP 2025/11/12 04:59:47 derphttp.Client.Recv: connecting to derp-12 (ord) 2025/11/12 04:59:48 bootstrapDNS("derp21c.tailscale.com", "162.aaa.aaa.215") for "log.tailscale.com" error: Get "https://derp21c.tailscale.com/bootstrap-dns?q=log.tailscale.com": context deadline exceeded 2025/11/12 04:59:48 trying bootstrapDNS("derp28b.tailscale.com", "2a01:4f9:c012:d55c:XXXX:XXXX:XXXX:1") for "log.tailscale.com" ... 2025/11/12 04:59:48 bootstrapDNS("derp28b.tailscale.com", "2a01:4f9:c012:d55c:XXXX:XXXX:XXXX:1") for "log.tailscale.com" error: Get "https://derp28b.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2a01:4f9:c012:d55c::1]:443: connect: network is unreachable 2025/11/12 04:59:48 trying bootstrapDNS("derp8b.tailscale.com", "46.aaa.aaa.201") for "log.tailscale.com" ... 2025/11/12 04:59:48 bootstrapDNS("derp8b.tailscale.com", "46.aaa.aaa.201") for "log.tailscale.com" error: Get "https://derp8b.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp 46.aaa.aaa.201:443: connect: no route to host 2025/11/12 04:59:48 trying bootstrapDNS("derp21d.tailscale.com", "2607:f740:50::ca4") for "log.tailscale.com" ... 2025/11/12 04:59:48 bootstrapDNS("derp21d.tailscale.com", "2607:f740:50::ca4") for "log.tailscale.com" error: Get "https://derp21d.tailscale.com/bootstrap-dns?q=log.tailscale.com": dial tcp [2607:f740:50::ca4]:443: connect: network is unreachable 2025/11/12 04:59:48 trying bootstrapDNS("derp4i.tailscale.com", "185.aaa.aaa.53") for "log.tailscale.com" ... 2025/11/12 04:59:51 magicsock: [0xc0041be000] derp.Recv(derp-12): derphttp.Client.Recv connect to region 12 (ord): dial tcp6 [2607:f740:e::4c8]:443: connect: network is unreachable 2025/11/12 04:59:51 health(warnable=no-derp-connection): okLots of stuff like that, and other things that would suggest that you're getting out of sync with the control plane, similar to what's described here: https://tailscale.com/kb/1091/what-happens-if-the-coordination-server-is-down

Please install "Plugin Diagnostics" from CA, and then either upload the Tailscale diagnostics, or download/post them here. Those include the Tailscale-specific logs/data that I need, it doesn't log to syslog (this is a good thing, it can make syslog hard to read :D ).

Sending logs via plugin diagnostics is best here... it's hard to guess what would cause that. Since you mention subnet routes, one thing that I'll mention is to be careful with "Accept Routes" and "Accept DNS" on the server... those can both cause connectivity problems depending on how the network is set up. Neither is usually required (e.g., you can advertise routes without accepting them).

Eventually, probably, but not right away. tsidp is still very alpha on the Tailscale side, so I want to keep it separate for now.

Yes, it will send an alert.

This is in the preview channel now :)

I'm explicitly disabling this for now, for a few reasons: That feature caused a bunch of issues, causing crashes/disconnects for users. Enabling state encryption makes the configuration non-portable, so I'm not certain that it should be the default for Unraid. I want to research how the information is being stored in the TPM -- e.g., could an Unraid update result in the decrypt key becoming inaccessible? Once the feature has had some time to mature, I plan to make it a configurable option.

That probably doesn't mean much. The plex logs are more important -- "internal server error" means that Plex thinks something is wrong, so you need to check its logs to see what it's upset about.

What do the plex logs say?

I don’t know of any changes that should cause behavior like that… I completed the 7.2 update on all of the my test boxes and my main production server without any issues. If you’re having trouble though, the best thing to do is to install Plugin Diagnostics and then post/upload Tailscale diags, that way I can see what it is doing/thinking.

It's been out for 4 hours, I need a little time to look at things to see how difficult it's going to be to integrate into the GUI. I'm also talking with folks at Tailscale about improvements that can be made so that creating services is easier. I do plan to add it -- I think it's a great feature -- but I'm not sure on exactly when that will happen. You can configure it using the CLI and the normal tailscale serve commands, that data is persisted in the state file (and will therefore survive reboots). tailscale.cfg is a config file for the plugin, not for Tailscale itself, so adding Tailscale parameters there won't help you at all

If you're wondering if you need it, you don't. You would know if it would help you :) (It's for managing the card itself / updating firmware / etc... if yours is working fine, it doesn't do anything.)

Possibly, I'll have to dig into that more. In the meantime, I adjusted the setting in "Tailscale IDP" -- if an entry starts with http:// or https://, it won't try to add the WebGUI port.

I just released a new update, it has an "allowed hosts" setting on the Tailscale IDP settings page. Add anything you need there (separated by spaces)

They will not persist in the current version, but that's something that I could look at doing. It shouldn't be too difficult to do, the only disadvantage I can think of is that the list could get a little bloated if you're routinely changing your hostname or WebGUI ports (but I don't think that would be all that common, nor would it really be a problem, more a cosmetic annoyance). Also, you'll need to add the grants to your Tailnet policy to make changes now, but it sounds like you already figured that out.

And just to be clear -- I don't expect for Unraid to be super-secure, by design it can't be. It uses a boot volume/configuration that can't be encrypted, and that isn't externally verified (so, for example, someone with physical access could replace the boot images on the flash drive with ones that would steal encryption keys, no matter how secure they were, add a plugin/package to steal keys/data, change credentials, etc.) Everything runs as root, increasing the impact of attacks of running services. However, while Unraid can't be used as a super-secure OS, I still think it's very important to be clear and unambiguous with users when affecting the behavior of sensitive things such as system encryption. The phrasing that being used in replies here doesn't meet that threshold for me, as it seems to be more focused on saying "this is fine" than being plain and honest about what this does. Users need to be OK with having a 5 character password for their drives -- that's what they're getting. An approach that would be more interesting (especially given how many users like to set up things like pi-hole, the -sense's, Unifi) would be something where you would configure a DNS TXT record, then the boot looks that up (from the local DNS server) and uses that.

I understand the point of the plugin. My objection is in presentation -- the description in CA claims that "Creates hardware-derived keys tied to your server's location and hardware for secure automatic unlocking". It is fair for folks to interrogate what "secure automatic unlocking" means, especially considering that the approach really isn't "secure". That needs to be clear in more words than "brute force is always possible" -- this makes brute force immensely easy compared to a 128-bit key (20ish characters). That would be 2^98 times more difficult, or to put it another way, that $8000 of AWS would become $2,535,301,200,000,000,000,000,000,000,000,000 (and just to put that in context, the global GDP is $111,000,000,000,000). I also think the claim that it's more secure than other methods is dubious -- other solutions involve creating a keyfile (which is presumably more than 30 bits) and then providing that from another device on the local network. Yes, if someone stole the server and that device, they could get the keyfile -- but if someone stole the server and the router, they get the gateway MAC, and so have both components to build the key. From a threat perspective, this isn't an improvement -- it's just giving up cryptographic strength. The actual "benefit" to using the MAC address isn't that it's more secure -- it's less secure than using a keyfile retrieved from another device -- but that it doesn't require for that other device to be set up (convenience). I would also suggest that this plugin should be flagged as a beta, given that I couldn't even get it to configure on my (very basic) test server. That makes me think that it doesn't have the testing/operational maturity to be considered "stable"/"production", especially given its potential impact on the system.

Several items here -- First, my attempt to configure the plugin on one of my test systems immediately failed, claiming my very simple passphrase (unraid-testing) is incorrect. Second, and more importantly, claiming that this is "making auto unlocking practical in the most secure way possible" isn't a fair statement, because (as mentioned) it vastly reduces the key strength of the underlying encryption. The motherboard serial is irrelevant, since if someone stole the server, they have that. Let's assume that, with the MAC address, there are 2^30 possible combinations (the second half of the MAC address (24 bits), plus 6 bits of possible OUIs, understanding that the more common the router, the faster it is to crack). In comparison, the minimum-acceptable key length for AES is usually considered to be 128 bits. 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 possible combinations. 2^30 = 1,073,741,824 possible combinations. "Millions of combinations" is trivial with modern hardware (even with a pass of SHA256). Fortunately, LUKS uses a key derivation function (KDF) which helps mitigate the impact of insecure passphrases by doing a set of computationally-complex calculations. Modern installations of LUKS use Argon2id with a target to calculate the final key in 2 seconds (in other words, when you initially create the key, it runs enough iterations to take about 2 seconds). This also means, though, that slower hardware gets less secure keys (it can do fewer iterations in 2 seconds). So, if you take the key to a faster system/more cores/etc., you can do those calculations much faster. (To put this in context -- based on some quick calculations I did, I think it would cost about $8000 to break most keys in AWS in one hour.) That's not to say that this is a bad idea inherently. However, it needs to be clear -- you are giving up a large amount of cryptographic security for convenience with this plugin. It also doesn't appear to remove that insecure key on uninstall -- so if you forget to remove it before uninstalling, your system remains insecure (with no way to see that).

I just released an update that should fix that problem.

It is still fine to use. 1.80 is the tsnet version (programmers version of Tailscale), it doesn’t usually need to update like tailscaled does.

What version of Unraid? I have a guess on what’s happening. If you can install “Plugin Diagnostics” and upload diags for the plugin, I can confirm.

You removed these lines from /boot/config/go, put them back at the end: # Start the Management Utility /usr/local/sbin/emhttp

Tailscale IDP (tsidp)The Tailscale IDP plugin brings Single Sign-On (SSO) to your Unraid server using Tailscale as an identity provider. With this plugin, you can log in to your Unraid web UI using your Tailscale account—no need to enter the root username and password if you’re already connected via Tailscale. ConfigurationAfter installing the plugin: Go to Settings -> Management Access -> Unraid API Settings. In the "OIDC Providers" section, select "Tailscale". Expand "Authorization Rules". Add Tailscale accounts to "Specific Email Addresses". Click "Apply". Changeloghttps://github.com/dkaser/unraid-tsidp/releases ContributingIssue reports and pull requests are welcome on Github: https://github.com/dkaser/unraid-tsidp

The select2 thing is cosmetic; it's a side effect of moving some code between repos a while back. I'll have that fixed in the next update. As for the restart issue -- this probably has something to do with how/when the network comes up during boot. I need diagnostics to understand what's happening better. Please follow the instructions in the pinned post to generate plugin diagnostics. You can either download the diagnostics and attach to a post here, or use the "Upload" button and post the ID it gives you.