Secluded

Please don't mind those restarting info in the log. I forced restarts in order to test if the plugin will include "tailscale1" in the listening interfaces. I'm pretty sure on version 2024.08.28, restarting tailscale will NOT automatically include "tailscale1" in the listening interfaces, although the "tailscale1" is listed in the network setting of web GUI. The obvious symptom is SMB won't work via Tailscale, and restarting Tailscale won't help. Manually add "tailscale1" in the listening interfaces can fix this. I only tested SMB via Tailscale magicDNS (which means access SMB using the Tailscale domain). Not very sure if accessing via Tailscale IP address works. I also tried reset my Unraid network setting, but nothing changes. After several tests, I rolled back to version 2024.07.31. This old version has no problem. SMB works via Tailscale once the plugin started/restarted. There seems something wrong with version 2024.08.28. Update: Version 2024.09.09 fixed this bug.

Hi there, I'm currently on Unraid 6.12.11 (rolled back from 6.12.13, since encountered some network issues in VM and docker) and Tailscale plugin 2024.08.28. I found this today that I cannot access SMB via tailscale (but no problem to access the web GUI) after I reboot my Unraid server, and it can be reproduced (It happens every time I reboot unraid). I fixed this by manually going to the network setting of Unraid and reapply including "tailscale1" in the listening interfaces. Since I have seen this post recently, have you already applied this work around in the latest update? I have attached my diagnosis file below if it helps. Thank you in advance!

Hi EDACerton, thanks for your suggestion! I will give the User Scripts a try.

Hi Hoopster, thank you for the advice! ☺️ Yeah, using a docker version seems a feasible way. While I still would like to let the plugin developer know this problem, and to see if this can be fixed from the developer side. I will try swtiching to the docker version if this won't be fixed for the plugin version.

You mean your computer was running another VPN besides Tailscale? And you can connect to your service via LAN IP if you turn that VPN off? That may be because your VPN software has a builtin firewall to prevent to leak your true IP, which is a very common way for many commercial VPNs. Some of them are set to pass thourgh the LAN IP (192.168.x.x) by default, but some may need you to set it up by yourself. Your case may be the later one.

Hi, is there a way to set a delay for starting this plugin? Context: My case is kind of special. I don't use a physical router but running an OpenWRT on Unraid as VM. Each time rebooting the Unraid, it will reboot itself first, and then start an OpenWRT router at 192.168.1.1. This setup may be kind of awkward, but it is very popular in Chinese community. As many Chinese users have demand for using some router based plugin, which require running a router on a x86 system, and if they own a NAS, why not run a router as a VM on that NAS? Although I doubt if there is many Tailscale user in the Chinese community. However, a more complex system get more chance to fail. For my case, I always lose connection to my Unraid server via Tailscale after I reboot it. I need to manually restart the Tailscale plugin after the Unraid server finishing the reboot, and then I can connect to it via Tailscale again. I suspect this is because the Tailscale plugin started before the OpenWRT VM when rebooting the Unraid. The plugin is required to send some info to the Tailscale server when it startup, in order to let the Tailnet to find this Unraid device. However, since the OpenWRT VM boot later than the Tailscale plugin, there is not Internet connection available to send those info. And then, for certain reason, the plugin won't try sending the info to the Tailscale server again, even the OpenWRT VM finished boot process. A possible easy workaround is to add an option to let the user set a delay to start the plugin during rebooting the server. It's even better if we can fix why the plugin won't retry sending the info to the Tailscale server, but I don't know how many efforts are needed for fixing that. Or, that stopping sending info is an intended behavior to avoid consuming system resource. I also attached my diagnosis info below, in case my inference is totally wrong. Thanks!