dcarpenter85

Members
  • Posts

    11
  • Joined

  • Last visited

Recent Profile Visitors

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

dcarpenter85's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. Oddly enough, after upgrading to 6.10.1 yesterday from 6.9.2, SSL set to auto was showing a 404 if I went to http://<server-name>.<local-tld>/ or http://<server-ip>/. Just tested again and it redirects as expected. It looks like https://<server-name>.<local-tld>/ or https://<server-ip>/ do not redirect and just go to the login page using the self-signed cert. Regardless, my issue seems to have resolved itself and the behavior I was used to in 6.9.x is back. Thank you!
  2. https://wiki.unraid.net/Manual/Release_Notes/Unraid_OS_6.10.0#Moving_to_Let.27s_Encrypt_wildcard_SSL_certificates. Can anyone confirm for me that this is indeed the case? Because this is not working for me. https://<server-name>.<local-tld>/ does not redirect. It simply goes to the login page using a self signed cert. I am using a new wildcard cert and I have tried all permutations of setting SSL to off/on/auto. Auto shows a 404 instead of redirecting, on or off both go to the login page using either no ssl or a self signed cert.
  3. Quick question--I was previously using the old single-host Let's Encrypt SSL cert on 6.9.x. I always accessed my server using https://<local-ip>/ and it would simply redirect to the <hash>.unraid.net URL. Upon upgrading to 6.10, https://<local-ip>/ no longer redirects...it simply brings me to the login page with the browser complaining the connection isn't secure (due to the self signed cert). I should also add that https://<hostname>.localTLD/ behaves the same way...no redirect, just an insecure connection. Was this behavior intentionally changed? I assume nginx on 6.9.x was automatically redirecting where as it is not in 6.10. If not intentional, any idea how to fix this? It was really nice to simply enter my IP rather than having to make sure I always had a bookmark on the device for the <hash>.unraid.net URL.
  4. Did something change with NPM with regard to access lists at some point in the last year or two? I had a perfectly stable setup running since March 2020, however when I went to make some edits to a proxy this weekend I discovered the access list is no longer properly applied. I was doing simple HTTP auth using the access for one user without doing any type of IP allow/deny. Now, when I apply this list to a proxy, I get 403 forbidden regardless of what I do. When I look in the proxy_host config, I don't see any mention of basic_auth. Wiped things out and did a clean install with the same results and also tried the 'official' NPM but it has the same problem. In the end I just restored my old backup to get back up and running but this means I am no longer able to make changes without things breaking again.
  5. When you add Sonarr and Radarr to Prowlarr as 'Apps', wait 5-10 minutes and you should see new Indexers automatically appear in those apps. This happens automatically and seems to be sporadic as far as the amount of time it takes to sync up. When I added Sonarr, it appeared pretty much right away but Radarr took about 10 minutes before finally showing up. TL;DR: Configure your preferred indexers in Prowlarr. Grab the API keys from Sonarr and Radarr, add them as Apps in Prowlarr. Wait.
  6. EDIT: After reading the reddit post and the comments on this thread, I decided to go ahead and apply the update since I was fairly confident my database was in decent shape. The update applied without issue and all of my data is safely intact. While I would still exercise caution before updating (back up your appdata folder and do a backup in the Radarr UI for good measure), it should be relatively safe for most people.
  7. But not 6.9.2 yet? My problems didn't start until I went from 6.9.1 to 6.9.2
  8. Interesting. Out of curiousity, are you on Unraid 6.9.2 and using Wireguard?
  9. EDIT: Looks to be an issue with Canadian endpoints? Tried ca-montreal.privacy.network and ca-toronto.privacy.network with the same error, but Bahamas (bahamas.privacy.network) seems to work fine. Oddly, I can connect to both of the above Canadian endpoints just fine using my Windows client.
  10. It looks like you are trying to connect to legacy PIA servers with the port forwarding option enabled. This is no longer working on the PIA side so you will need to switch over to a next gen server. Assuming ca-vancouver.privateinternetaccess.com is the server you are wanting to connect to, simply go into your ovpn config file and change the URL to ca-vancouver.privacy.network. Start the container and monitor the logs--you should see a port get assigned and then, finally, a message saying [info] Deluge Web UI started. WebUI should be accessible now.
  11. Thanks for the most recent update Binhex. I just updated to the latest release and I am happy to have port forwarding back from PIA's CA Toronto next-gen server! It was a rough few weeks there without it.