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.