vmasip

It wasn't turned on: tailscale debug prefs | grep RouteAll "RouteAll": false, I haven't modified default settings of tailscale. I've just logged in. I've tried in version installed from unraid 7.3.0-rc1 installing extras, or uninstalling and installing beta version after that. Same behaviour. See the options, accept routes is not even accepting user enables it. I am attaching the diagnostics. alaska-tailscale-diag-20260426-191625.zip

Of course it's strict. It's recommended way set here: https://www.youtube.com/watch?v=OTK4OwpxFek&t=156s But, I thought for a huge period of time unraid was crashed. Let me present you shortly the chain of events. I set ssl to strict. Works perfectly from firefox, my usual explorer. I set tailscale and add my unraid to my tailscale vpn After a minute or so, I can't see unraid on firefox. No http or https address is working I suposse tailscale broke my unraid I am hours trying to findout what tailscale broke Finally I realised that firefox has an issue with something tailscale changed So, it's an tailscale plugin issue. Isn't it? My adresses worked perfectly before tailscale with ssl to strict.

Well, I thought I had same issue, but, well well,it works with Chrome!!! I paste a reporting about my findings with chat gpt: Unraid 7.3 + Tailscale: Forced FQDN HTTPS redirect breaks LAN access (Firefox + curl verified)After enabling Tailscale on Unraid 7.3.0, the web UI becomes subject to automatic nginx rewrite rules that persist even with Unraid Connect remote access disabled and after removing the plugin/account linkage. 🔍 Observed behaviorLAN access is forcibly redirected at nginx level: curl -I http://192.168.1.81Returns: HTTP/1.1 302 Moved Temporarily Location: https://192-168-1-81.<hash>.myunraid.net/ Server: nginxThis confirms the redirect is server-side (nginx-generated), not browser cache or DNS-related. 🌐 Configuration evidence/etc/nginx/conf.d/servers.conf contains Tailscale-triggered rewrite rules: return 302 https://192-168-1-81.<hash>.myunraid.net$request_uri; return 302 https://100-122-21-124.<hash>.myunraid.net$request_uri; server_name 192-168-1-81.<hash>.myunraid.net 100-122-21-124.<hash>.myunraid.net;This persists even when: Unraid Connect remote access is disabled myunraid machine is removed from myunraid.net dashboard 🧪 Client-side impact (Firefox-specific symptom)Firefox shows intermittent UI failure / forced HTTPS navigation loop Likely due to HTTPS-First mode + cached redirect behavior Chrome/curl behave more predictably, masking the issue ⚠️ Root cause hypothesisTailscale interface detection (tailscale0, IPv6 fd7a::) triggers Unraid 7.3 nginx regeneration logic, which: Switches Management Access into “remote-secure mode” Injects .myunraid.net FQDN redirects Enforces HTTPS redirects even for LAN IP access Does not fully respect “Allow Remote Access = disabled” 🧩 ImpactBreaks expected LAN-local HTTP access model Forces external FQDN resolution for local UI Creates browser-dependent behavior (Firefox most affected) Produces inconsistent access paths between LAN IP vs generated FQDN 📌 Key pointThis is not a Tailscale connectivity issue, but a UI routing / nginx rewrite side-effect introduced when Tailscale is present in Unraid 7.3, affecting LAN access.

Well, I thought I had same issue, but, well well,it works with Chrome!!! I paste a reporting about my findings with chat gpt: Unraid 7.3 + Tailscale: Forced FQDN HTTPS redirect breaks LAN access (Firefox + curl verified)After enabling Tailscale on Unraid 7.3.0, the web UI becomes subject to automatic nginx rewrite rules that persist even with Unraid Connect remote access disabled and after removing the plugin/account linkage. 🔍 Observed behaviorLAN access is forcibly redirected at nginx level: curl -I http://192.168.1.81Returns: HTTP/1.1 302 Moved Temporarily Location: https://192-168-1-81.<hash>.myunraid.net/ Server: nginxThis confirms the redirect is server-side (nginx-generated), not browser cache or DNS-related. 🌐 Configuration evidence/etc/nginx/conf.d/servers.conf contains Tailscale-triggered rewrite rules: return 302 https://192-168-1-81.<hash>.myunraid.net$request_uri; return 302 https://100-122-21-124.<hash>.myunraid.net$request_uri; server_name 192-168-1-81.<hash>.myunraid.net 100-122-21-124.<hash>.myunraid.net;This persists even when: Unraid Connect remote access is disabled myunraid machine is removed from myunraid.net dashboard 🧪 Client-side impact (Firefox-specific symptom) Firefox shows intermittent UI failure / forced HTTPS navigation loop Likely due to HTTPS-First mode + cached redirect behavior Chrome/curl behave more predictably, masking the issue ⚠️ Root cause hypothesisTailscale interface detection (tailscale0, IPv6 fd7a::) triggers Unraid 7.3 nginx regeneration logic, which: Switches Management Access into “remote-secure mode” Injects .myunraid.net FQDN redirects Enforces HTTPS redirects even for LAN IP access Does not fully respect “Allow Remote Access = disabled” 🧩 Impact Breaks expected LAN-local HTTP access model Forces external FQDN resolution for local UI Creates browser-dependent behavior (Firefox most affected) Produces inconsistent access paths between LAN IP vs generated FQDN 📌 Key pointThis is not a Tailscale connectivity issue, but a UI routing / nginx rewrite side-effect introduced when Tailscale is present in Unraid 7.3, affecting LAN access.

I didn't see it! Thanks!

why usb creator doesn't have this version available? why is not listed with the other .zip? It's quite confusing seeing the blog announcing that it's available, with a video to create a fresh boot with usb creator, just to realise, that there is no way of creating an usb to make a fresh install. Have I missed something?

Well, what I need is the license I paid for just working or being attended correctly. It's frustrating not to be able to use my system. I've waiting for my support ticket to be solved from Monday. Almost two days without answer. No phone for support calls...

I think they have a glitch. Becuase I submmited a ticket 2 days ago. My original key was related to an usb which tends to fail. So I installed my key into the new one with "replace licensed key". It worked until reboot. License fine and normal behaviour. And now, it doesn't work. The ticket was answered yesterday, and they told me to set new key url download into new usb. But they told me that it was associated to old GUID, which "was suceessfull". I didn't get that. Precisely i want to leave behing old usb. Nonetheless, new url offers same error. Very rare ..

Hello Not for me. I've got fresh new unraid 7.2.2 . also fresh plugin (installed trough terminal with unraid-api plugins install unraid-api-plugin-connect because ui installation one didn't showed up the top right orange icon) I've obtained sign-in error after waiting.

Maybe writing permissions? That happened to me. Check the log and paste it here

Hello I try to find docs which could clarify me this. Could anyone tell me the answer or passing me a link to learn about how this could work?

Until using this image with vpn I used one without it. So I didn't have a dilemma I've got right now. I used to donfigure this at my compose: cloudflaretunnel: container_name: cloudflaretunnel image: cloudflare/cloudflared:2023.2.1 restart: unless-stopped environment: - TUNNEL_TOKEN=$TUNNEL_TOKEN command: tunnel --no-autoupdate run networks: - alaska-rr-services So, with this, all my rr apps and qbittorrent were accesible from outside my LAN trough cloudflare tunnels using this: networks: - alaska-rr-services Now I've configured binhex.qbittorrentvpn image. Using pia and openvpn, because this is were I want my torrent traffic goes: qbittorrent: image: binhex/arch-qbittorrentvpn container_name: qbittorrent logging: driver: json-file ports: - ${QBITTORRENT_WEBUI_PORT}:${QBITTORRENT_WEBUI_PORT} - ${TORRENTING_PORT}:${TORRENTING_PORT} - 8118:8118 - 9118:9118 - 58946:58946 - 58946:58946/udp cap_add: - NET_ADMIN environment: # - DOCKER_MODS=ghcr.io/gabe565/linuxserver-mod-vuetorrent - PUID=1118 - PGID=${PGIDTORRENT} - TZ=${TZ} - UMASK=${UMASK} - WEBUI_PORT=${QBITTORRENT_WEBUI_PORT} - TORRENTING_PORT=${TORRENTING_PORT} - VPN_ENABLED=yes - VPN_USER=$PIA_USER - VPN_PASS=$PIA_PASS - VPN_PROV=pia - VPN_CLIENT=openvpn - ENABLE_STARTUP_SCRIPTS=no - ENABLE_PRIVOXY=yes - STRICT_PORT_FORWARD=yes - USERSPACE_WIREGUARD=no - ENABLE_SOCKS=yes - SOCKS_USER=admin - SOCKS_PASS=socks - LAN_NETWORK=$PIA_LOCAL_NETWORK - NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1 - VPN_INPUT_PORTS=1234 - VPN_OUTPUT_PORTS=5678 - DEBUG=true volumes: - /etc/localtime:/etc/localtime:ro - ${APP_DATA_HOST}/qbittorrent:/config - ${DATA_HOST}:/data/torrents restart: always healthcheck: # Container may fail if the PIA's token expired, so mark as unhealthy when there is no internet connection # see: https://github.com/qdm12/gluetun/issues/641#issuecomment-933856220 test: [ "CMD", "curl", "--fail", "http://127.0.0.1:8080", "https://google.com" ] interval: 30s retries: 10 But if I add networks: - alaska-rr-services I guess my torrent traffic will go trough cloudflare too? (which is not suitable) I only want that my WEBUI_PORT goes trough that network (and torrenting network trough vpn) I guess I am not the only one with this problem. How can I achieve that?

Another issue I'd like to talk about is about openvpn vs wireguard. Docs says clearly that wireguard config requires privileged permissions. That's the reason I am trying to use openvpn. I'd like to mention that this image: https://hotio.dev/containers/qbittorrent/#__tabbed_3_2 does not required privileged access for pia + wireguard. Probably I am missing something. But I've wanted to point it out because would be great having this image with wireguard without privileges.

I am having exactly the same question. I think that maybe, conceptually , it's not possible. Have you had any advanced with this?

Of course I respect opinions. And I respect someone is not interested. I respect silence. I respect opinions so much, that I've kept the good manners spite of that flagrant violation of common sense and socially acceptable human conduct. So you are welcome. I just pointed out the misconceptions about me you've used ( I said "you" but it's been 95% @MPC561 ) with bad manners when I was trying to help. Defend myself against bad words about me like "headline readers", that I don't read or don't pay attention, or, insults directly calling out word like stupid, imply more than once that I am problematic, or not skilled enough to copy paste (against detail oriented engineers). I am f**** defending myself all the time. I hope moderators are reading this,because it's completely exhausting. But above all I've been replying because @MPC561 has liked a lot putting words in my mouth which I haven't said, or conclusions I haven't bring out: "Think about or google it" -> I had already done (Can be checked) Bring out twice, even after clarification that I am confusing my motherboard. -> I am not. I didn't fingerpoint anything (maybe you translated wrong) ->that word has a bad underlying meaning and I just tried to help. Say that I hadn't read all the thread -> I did. Moderators, should I memorize or should you instead recognizing past complementary info should be quoted? I say that setpci doesn't work in most cases. Or I don't believe it -> I just really believe it, just that the bad case, is a possibility. Like I proved. He has tried to make the forum believes that I try to steal the authority of the reddit commad -> I just pointed this out, to defend myself that I am not that kind of person. I hate when people moves my words, or move the object of debate continuously. And, I am really glad that has been stopped with his self-silence. It's s not acknowledgement, and is painful with sentences like this. (.. because all, all,....... all? I would say that violate norms as you say with insults is not friendly) But at least, I have to stop to defend myself which is a good point, a relief, and easier to keep on using good manners.