skywalker6705

With rare exception, Tailscale is designed with the knowledge and intent that not all clients will be perfectly in-sync with upstream. It's extremely unreasonable to expect someone to push an update immediately when they are 0.00.1 versions behind master. Generally speaking, if the client is out of date for many months, or many versions behind, you may have some valid concerns, or if there was a zero day CVE discovered in the wireguard protocol itself. Otherwise, relax a bit, give people time.

Like with your other project, Folderview Plus, this feels distinctly vibe coded on top of an existing app to "enhance" it. I have some serious reservations about using this given that you haven't disclosed any use of AI in the process at all.

This is phenomenal, and very sleek. Using this for now until I inevitably want to make custom tweaks of my own. Thanks for sharing. I found it worked fine for me on the Black Theme aside from needing to set a custom header text color. Edit: You should probably re-factor the CSS gradient SVG you made. The animation is really nice, but when on-screen it kind of hammers the processor. Might be a way to optimize this to be less detailed, or just replace it with a rendered animation file.

This error happened to me as well. Unsure exactly what the cause is. Also unable to disable the folder border, no matter what is selected in settings. Will file an issue on github.

Not meant to be nasty by asking, but this gives the strong impression of being vibe coded. For a web interface that isn't really a bad thing, but I'd like to know if it is. The entry in the Community Apps is also barren with little description, no issues and no community discussions. So I hope you can understand the questions.

Happy to hear that. I realize the LTS path is the smarter and safer way to go, but I was hoping there was some kind of update like what you shared. If 7.3 is on 6.18. then that's perfect, and should help resolve a lot of my issues.

I will give nextExplorer a look! I've been testing FileManagerUI recently for this same reason. A modern looking dual-pane interface. Seems vibe-coded but it's functional for now. I only spin it up when I need it right now until it's a bit more tested. https://github.com/jandrop/file_core_api_unraid I don't want to give all my users root access, and the Unraid Dashboard itself is not exactly where I want to send a user who I granted enhanced access to. That said, I do hope the web interface for the file management get a little better in the future, as some operations like moving files from disk to disk would be easier if we had dual panes like Midnight Commander and other file browsers. Until now, MC was my fallback option for Unraid disk activity. And if/when that does happen, letting users login to the unraid dash with their samba user information to access that file browser and limited other sections might be a good idea to explore. As others have mentioned, it is a feature on simpler NAS hardware.

This request is rather specific to some of the driver support included in kernel 6.13.5 adding ROCm support for AMD Radeon 9000 series cards on Linux. For many users who managed to pick these up at MSRP, they are a great value, but currently under-utilized in Unraid containers and applications due to being unable to leverage the latest driver support. I realize Unraid favors array stability over everything else, but moving to 6.13.5 or above (6.14 or 6.15 even) would be hugely beneficial for some users.

Hi, I'll share what I did so I hope it helps. One step I took was to remove my custom DNS from the loop to simplify troubleshooting, and have Unraid connect direct to a known good external DNS to resolve tailscale control plane addresses. This was essential because near as I can tell, the issue in my case turned out to be something in my local dns either on the router level or in my cached IPs in pihole expiring. I refreshed my pihole and cleared my caches, restarted my whole network, and on the Unraid side set the system DNS to use a specific IP outside my network (1.1.1.1) and I did a full safe shutdown and reboot so the system would drop anything in the cached memory. After all of the above, I've seen the issue go away. I use Pihole on my network devices still, and my home router uses it to resolve addresses, so only Unraid OS itself uses a non-filtered DNS, which works fine for me for now. Anything not on "Host" network will be filtered as before, which is like 99% of my containers. I suspect this was an issue with dns propagation within my network falling out of step with the tailscale control plane. Somewhere in my network it was being cached, and remained out of date. But I can't say for sure. I realize that is vague, but I do hope it helps in your diagnosis. 1. Known good and up to date DNS 2. Clear caches 3. Removing any ad-blocking or filtering from the loop. Best of luck.

Thanks! I went back and tested my OpenVPN configuration with these lines added, and between deleting the ctl block and adding these two, the config is working again. I appreciate you taking the time to help diagnose the issue, since it seems to stem from outdated vpn provider configs, not anything with the container.

You are indeed correct, the crl-verify block was causing it to never work. After deleting that, the log file results are thus: Error: ipv4: FIB table does not exist. Dump terminated + exec sg vpn -c 'openvpn --cd /vpn --config /vpn/vpn.ovpn --script-security 2 --redirect-gateway def1 --auth-user-pass /vpn/vpn.auth ' ---Checking for optional scripts--- ---No optional script found, continuing--- ---Taking ownership of data...--- ---Starting...--- 2025-12-14 01:17:47 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 2025-12-14 01:17:47 OpenVPN 2.6.14 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] 2025-12-14 01:17:47 library versions: OpenSSL 3.5.4 30 Sep 2025, LZO 2.10 2025-12-14 01:17:47 DCO version: N/A 2025-12-14 01:17:47 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx 2025-12-14 01:17:47 UDPv4 link local: (not bound) 2025-12-14 01:17:47 UDPv4 link remote: [AF_INET]xx.xx.xx.xx:xxxx 2025-12-14 01:17:47 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 2025-12-14 01:17:47 [newyork433] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx 2025-12-14 01:17:47 WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results 2025-12-14 01:17:47 sitnl_send: rtnl: generic error (-101): Network is unreachable 2025-12-14 01:17:47 TUN/TAP device tun0 opened 2025-12-14 01:17:47 net_iface_mtu_set: mtu 1500 for tun0 2025-12-14 01:17:47 net_iface_up: set tun0 up 2025-12-14 01:17:47 net_addr_v4_add: xx.xx.xx.xx/24 dev tun0 2025-12-14 01:17:47 WARNING: OpenVPN was configured to add an IPv6 route. However, no IPv6 has been configured for tun0, therefore the route installation may fail or may not work as expected. 2025-12-14 01:17:47 sitnl_send: rtnl: generic error (-13): Permission denied 2025-12-14 01:17:47 ERROR: Linux route add command failed 2025-12-14 01:17:47 Initialization Sequence CompletedThis is with mostly the defaults from the container, so I think I'll have to adjust some thing to make it work. Any advice is appreciated. edit: In my particular case, it just so happens that SpaceinvaderOne just put out a tool to help me move PIA over to Wireguard from OpenVPN connections, so while this "resolves" my issue in terms of connectivity, I would actually still like to get this tunnel back up and running as a backup. I appreciate your help on diagnosing this.

Experiencing issue connecting to PIA via the OpenVPN-Client now. No changes on my configuration for years, but it started failing. Cleared the appdata, tried reinstalling. Noted a change on dockerhub 2 days ago. Think this may have broken the container config for Unraid? The application template gives a 404 at the moment https://raw.githubusercontent.com/ich777/docker-templates/ich777/OpenVPN-Client.xml Other applicaiton templates on github loading fine. Tested the VPN itself using the windows desktop client, that worked. Updated the ovpn files for the server, the contents were identical to previous. Checked the username and pw in the auth file in case that file was corrupt, it was not, and the process owned the file (it would in fact reset ownership on start)

I'll have to keep monitoring it. I think given what you've shared, it may be an issue actually with some things on my ISP side recently. It works once I restart it, and it seems to have been working consistently for a little bit now. I want to see if there's a way for me to mirror the IPs into a Raspberry Pi Pi hole or something, so I have some fallback in case my ISP modem DNS doesn't properly identify these addresses.

Thanks, diagnostics from the plugin are posted here. I'm seeing some nonsense but I haven't had enough time to parse it. Diagnostics Upload ID: 1624c3db9182d251ca2bda81d8ebc132 Edit: Had a second occurrence, uploaded a second log. Diagnostics Upload ID 2: 734eeefb4a1b6d7ea26af72667ea9a8c

This is good advice. I did check, and both of these are already off unfortunately. It seems to me like the tailscaled daemon is crashing, but I don't know why. Restarting it fixes everything, but only for a while. I don't see anything in the syslog about the tailscale service or daemon erroring out, but I might just be looking in the wrong place. Diagnostics attached. Happy to investigate further if you think of an area I can poke around in.

Also of note, I can still access the dashboard and settings for my PI hole, which I have using its own container network and with its own tail scale daemon. So I know the network connection is up and I know that connection to tailscale from my home is possible. But specifically, the plug-in integration in the Unraid system is failing somehow.

Like somebody posted back in August, I'm also experiencing issues with tailscale losing connection after initial boot. After restarting the server it'll stay connected for a while and for some reason after a indeterminate amount of time it may lose connection with the tailscale service. If I load the plug-in settings page and wait, it will eventually load and show me unknown and error values. But if I restart it from this page, it will successfully reconnect and I will have access for another few hours until the connection drops again. I did not have this issue until extremely recently, but it has started cropping up over the past few weeks, and impacting my ability to access my services outside of the home. I'm currently away from my home, or I would post my diagnostics, but I did go over them the other evening, and it doesn't show any obvious errors that I could identify. Based on the number of users here that are reporting this, however, it seems like there's some kind of regression that's having an edge case interaction with the network. I advertise a subnet and I also host a pie hole on my network that runs my local DNS. Out of an abundance of caution, I removed the pihole DNS entry from Unraid gui and Unraid is using cloudflare and Google dns to make sure that it has a direct path to the tailscale domain without bringing the Pi hole into the equation. I will share my diagnostic logs when I get home, but I am looking any input from someone who might have advice on what I can try. When within my local network I don't really notice any issues. The timing of this for me at least seems to correlate with tail scale adding the peer relay features and some of the other things from this year's fall update. And since I have tailscale installed as a sidecar for pihole, I was concerned that the server might be trying to relay to itself and getting caught in a loop.

The title of your plugin is clear, but since this is the first attempt I have seen to make a plugin for buddy backup, is there any hope that BTRFS could be supported in the future as well? The much higher RAM requirements for ZFS and the risk of data-loss if not using a UPS to protect the RAM led me to using a BTRFS array for my setup among others. BTRFS supports snapshots as well, so I would hope it could become a target for this plugin as well in time.

Coming in here for future users: yes. Set umask to 000. Notably linuxserver.io docker images ship with a umask 022 value, and this value is a good choice for other linux systems, just not unraid. The reason is that Unraid's default security approach is to manage secure access via shares in the virtual filesystem and otherwise use containers for software. If you have qbittorrent set files as 755, and prevent write by others, then the result is that only root (the web gui or ssh), and qbittorrent can do anything to them. This effectively results in being unable to delete old files when browsing a network share over smb, or modify and update documents when syncing them on a network share. Unraid's security model is set such that files being in 777 is not a problem. The core focus of the filesystem is data storage and NAS use, so you want to gate it based on the share or "library" it contains, rather than at a file level in a shared filesystem under multiple users. For the security concerned, keep in mind that the OS is not stored on the same file system at all (USB) and by default docker containers only have as much access and permission as you allow. So this security model effectively moves a lot of the risk via filesystem out of the way. Also this advice applies to container settings and shares, but the default appdata and system shares should be left alone unless something is critically wrong with them.