• Content Count

  • Joined

  • Last visited

Community Reputation

8 Neutral

About Lignumaqua

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. And he has! 😃 Thanks Squid, all your hard work is much appreciated.
  2. Yes, see my post above. This had been working fine but broke when the single quotes were replaced with ' in mid March. Unfortunately some (all?) browsers treat this as a quote which breaks the Javascript. I had to edit the strings in tests.php to remove the apostrophes before I could get it to work. I'm sure Squid will post an update.
  3. FYI - I was able to fix this (well, mask it really, I didn't fix the root problem) by editing the two addWarning() strings in tests.php to remove the apostrophes, and deleting ignoreList.json again. The strings now read 'The unRaid built in FTP server is currently disabled, but users are defined' and 'The unRaid built in ftp server is currently running'. The buttons now work as expected. Any other error strings with apostrophes likely still have the same problem.
  4. Thanks, but I've tried that. In fact I deleted everything and started again. Still has this problem I'm afraid, the single quotes in these two error fields break the JavaScript 'Monitor Warning/Error' buttons. Version installed is 2021.03.24
  5. Looks like 'unRaid's built in FTP server is running' has the same problem. The 'Monitor Warning/Error' button doesn't work because of the single quote/apostrophe breaking the JavaScript. Any suggestions on how to fix this?
  6. Recently I've been getting the 'unRaid's built in FTP server is currently disabled, but users are defined' warning every day. I've tried adding it to the ignored list it but it doesn't help. So, I thought I'd try UNignoring it and then REignoring it. However the 'Monitor Warning/Error' button doesn't work. Looking in the browser console I can see why. There is an unescaped apostrophe which is breaking the JavaScript. This is the line: <input type="button" id="1360801943" value="Monitor Warning / Error" onclick="readdError("unRaid" s= built in ftp server is current
  7. After hours of testing I now think this is nothing to do with Unraid. Instead, it's a fault with my UniFi WiFi set-up. It seems that when meshing is enabled it is creating a net loop. I've disabled every client and it still does it, so it's one of the UniFi devices themselves rather than a client. If I disable meshing all is good. This is clearly off topic for Unraid. So I consider this solved.
  8. With no changes that I'm aware of my log is suddenly getting flooded with messages like this and network access to Unraid is very slow. Presumably because the NIC is getting overloaded. Jan 2 23:58:45 Tower kernel: br0: received packet on eth0 with own address as source address (addr:d0:50:99:c2:d5:1b, vlan:0) I know this message can appear if you have bridged NIC interfaces without bonding them. I do have two NICs connected, but they are neither bridged nor bonded and have been working perfectly for some months with each having its own IP on the same network (I did this to allow VMs to
  9. @NeoSys - You aren't being clear, but just to try and clarify what I think is going on here if your 'issue' is with PIA. 1. PIA's support for OpenVPN V2.5 is very spotty and varies from server to server. 2. I also think this is changing as they upgrade servers, so a server that worked yesterday might not today, or vice-versa. 3. As far as I can tell, best advice right now, no matter what cipher you are using, is to make sure you have the 'ncp-disable' line in your ovpn file. It might work without on some servers but it's a dynamic situation. 4. Also make sure you ar
  10. I don't think so I'm afraid - at least, not for all servers. The nextgen 2.4+ ovpn file from the config file generator for the Bahamas server is essentially the same as the zip file version, and doesn't work without adding in npc-disable.
  11. Update: I was able to make this work by adding the 'ncp-disable' flag to the ovpn file. Not really a great solution, but it allows use of the latest version of the Docker. No other changes or additions needed to the ovpn file as downloaded from PIA, just adding this directive. It's a cheat as it stops any renegotiation of ciphers and forces use of the one defined in the (deprecated) 'cipher' directive so will likely fail again in the future. I've also seen posts elsewhere that suggest this does indeed vary by PIA server and that the Toronto server is the best behaved at the moment. 🤨
  12. No, I've tried both with and without it with no change. The 'cipher' parameter is actually deprecated in the latest version (2.5) of OpenVPN so it should no longer be used. The previous versions of this Docker used the older (2.4) OpenVPN where that was used. The move to V2.5 also changed which default ciphers were used. I think this is the core of the problem. The PIA servers are strangely configured and not well behaved in dealing with a V2.5 client. We aren't the only ones with this problem with PIA:
  13. Here's the file. This is Bahamas.ovpn with the edits to the cipher lines. Still get the BF-CBC failure. (Note : I've been testing with both this Docker and your companion qbittorrentvpn Docker. Could they be behaving differently? Most of my testing has been with qbittorrentvpn as I use Privoxy with that one but I've had the same issues with both. I can't swear to have tried every combination with both of them though. 🤔) client dev tun proto udp remote 1198 resolv-retry infinite nobind persist-key data-ciphers-fallback aes-256-gcm auth sha1 tls-
  14. I've now tested every combination of 2048 and 4096 certificates and associated ovpn files with and without the extra data-ciphers-fallback aes-256-gcm or data-ciphers-fallback aes-128-gcm and none of them work. They all give the same errors. Rolling back to 3.1.0-1-02 (for this Docker) or 4.3.0-1-04 (for the sister qbittorrentvpn Docker) is the only way I've found to get this working again. I wonder if different PIA servers are behaving differently? Quite possible I guess. I'm using the Bahamas server to use port forwarding. Maybe the Toronto one you are using is behaving differently?
  15. Unfortunately this and GitHub A22 didn't help. Same problems as before. The only think that works for me is reverting to the prior build. I note that you say to use the 4096 crt and pem files certificates. Where did you get those from? The only ones in are the 2048 versions. What am I missing here?