Ptolemyiv

I am using AWS authentication so may be specific to that

It seems to reoccur for me whenever I update/reinstall the container. My nginx updated to the recent latest release which broke for a different reason (something about an argument list being too long) so I had to manually configure to the previous docker version and had the same error again but it appears to at least be easily resolvable by just re-running the urllib command mentioned previously. Not sure why the latest version is breaking though - anyone else getting the same?

This could be a lan routing issue - try accessing the site externally (e.g. via mobile) and see if you get the same too many redirects error. If not, in your router you need to find somewhere to configure a static dns hostname - so if e.g. your external domain is www.yoursite.co.uk and your nginx docker ip address is 192.168.1.2 then you would map that domain to that IP - any internal nginx requests would then be routed directly and avoid this infinite routing loop issue you are experiencing. I use a Unifi UDM Pro router and they finally added this feature last year for instance.. (For external access you'll also need to forward any incoming port 443 traffic on your router to the nginx IP)

Am getting a certbot route53 error again in the logs and am unable to log in to the gui (since itself relies on ssl certificate!) - log is showing the following repeatedly: [app ] [12/29/2023] [11:33:43 AM] [Global ] › ✖ error Command failed: pip install --no-cache-dir certbot-dns-route53==$(certbot --version | grep -Eo '[0-9](\.[0-9]+)+') [app ] The 'certbot_dns_route53.authenticator' plugin errored while loading: cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_' (/usr/lib/python3.10/site-packages/urllib3/util/ssl_.py). You may need to remove or update this plugin. The Certbot log will contain the full error details and this should be reported to the plugin developer. [app ] Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/certbot-log-ul_q9vn7/log or re-run Certbot with -v for more details. [app ] ERROR: Could not find a version that satisfies the requirement certbot-dns-route53== (from versions: 0.15.0.dev0, 0.15.0, 0.16.0, 0.17.0, 0.18.0, 0.18.1, 0.18.2, 0.19.0, 0.20.0, 0.21.0, 0.21.1, 0.22.0, 0.22.1, 0.22.2, 0.23.0, 0.24.0, 0.25.0, 0.25.1, 0.26.0, 0.26.1, 0.27.0, 0.27.1, 0.28.0, 0.29.0, 0.29.1, 0.30.0, 0.30.1, 0.30.2, 0.31.0, 0.32.0, 0.33.0, 0.33.1, 0.34.0, 0.34.1, 0.34.2, 0.35.0, 0.35.1, 0.36.0, 0.37.0, 0.37.1, 0.37.2, 0.38.0, 0.39.0, 0.40.0, 0.40.1, 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.10.1, 1.11.0, 1.12.0, 1.13.0, 1.14.0, 1.15.0, 1.16.0, 1.17.0, 1.18.0, 1.19.0, 1.20.0, 1.21.0, 1.22.0, 1.23.0, 1.24.0, 1.25.0, 1.26.0, 1.27.0, 1.28.0, 1.29.0, 1.30.0, 1.31.0, 1.32.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0, 2.5.0, 2.6.0, 2.7.0, 2.7.1, 2.7.2, 2.7.3, 2.7.4, 2.8.0) [app ] ERROR: No matching distribution found for certbot-dns-route53== [app ] [12/29/2023] [11:33:44 AM] [Migrate ] › ℹ info Current database version: none Unfortunately the fix before doesn't seem to be working - anyone know how to fix this once and for all? (may be a recent update issue since only just started reoccurring again) EDIT: So the only way I was able to fix this error was to run the following command and download urllib manually: pip install 'urllib3<2' Nginx Proxy Manager then loaded and unsuccessfully failed to auto-renew the certificates - after this, I was able to manually renew the certificates from the UI. Strangely, if I reboot the container than the original error re-occurs and I have to manually execute the above command again... Anyone else encountering the same or can suggest a permanent fix? Many thanks

I think I just went into the terminal and ran e.g.: ps -ef | grep certb Look for the process ID which is the number immediately after user such as: root 1234 5100 ... To kill the process type: kill 1234

Been running nginx proxy manager on unraid docker for a long time with limited issues - only issue I had really been incurring and never figured out was the auto-renewal for certificates never working.. I received an email saying a certificate was expiring shortly and went to log in to the UI to manually renew - the UI wouldn't go past the login page, it just refreshed without any sort of error message. Checking the logs I noticed repeated errors related to "certbot-route53-dns" (how my own certificates are authenticated) with no valid version available and failure to "pip install" this package. Remoting in via terminal, I manually executed the pip install command to which the login via the UI immediately worked.. however renewing the certificate still failed (UI showing "Invalid error") until I manually killed the standard "certbot" process. Obviously this is only a temporary fix given it will reset whenever the container is rebuilt. I am guessing this may be a bug introduced with recent update to v23.08.1? I didn't take screenshots at the time but can rebuild the container to replicate if not easily identifiable..

Same...

Any update on this? Having the same issue with unraid / shim-br0 / udmp

Yep, would be fantastic if this were updated to latest 2.14.01 because it fixes a number of issues with hue + tradfri switches amongst others Edit: I just had to do 2 minor changes in the docker settings to upgrade and get the latest deconz-community docker: 1) Under advanced view change repository from spaceinvader to: deconzcommunity/deconz 2) Change appdata container path to: /opt/deCONZ

Ok thanks. Anyhow, you were right - as soon as I enabled ICMP protocol and the unraid IP, it immediately shows as green.. thanks for saving me some time!

Sorry for dumb question but which logs should I check and what is easiest way of doing that? If I click the log icon on the right of the row for this share under unassigned devices it is just blank And thanks both for confirming on other question re license

Hi all, I can't seem to work out why any remote SMB or NFS share mounts (a synology NAS I use for critical backup) will not show the mount button enabled under Unassigned Devices section of the Main page. If I click log then nothing appears. It used to work and when I add the share with user name / password I get a "Success!" pop-up window. My best hunch is if perhaps accessing an external share counts towards my unraid disk limit? (I only did basic version since I physically can't fit more than 4 drives + 2 SSDs in my case) If this is the case, it is fine and I will upgrade but wanted to check this was definitely the issue before I pay more to potentially be disappointed! I did check the FAQ and saw it say that all drives that appear as linux drives other than the flash drive will count but I am not quite sure if SMB/NFS shares appear as such (I assumed they were mounts within an existing share) Thanks for the guidance! Overall am loving unraid.. has been a bit of a game-changer from underpowered Syno world..

Thanks - that is just if I want to provide basic login authentication to hosts myself, right? In which case, I do not use that.

Can I ask a paranoid question - when I set this up original I could swear there was some message about needing to move the default passwords file location from www folder or something? For the life of me, I can't find any mention or reference to this elsewhere so not sure if was just hallucinating or not... Point is - I have nginx working great with a mix of externally accessible and lan-only sub-domains but want to ensure I haven't left some silly gaping security hole.. I have of course set up a strong password for nginx itself and all the hosts have their own login access controls Thanks

This worked a treat for me as well using Nginx proxy manager - only tweaks were to update the docker config path which I specifically limited to read-only on the certificate folder for the plex certificate for a little extra security. I also didn't need to do step 3 either and Plex is now working remotely via my own domain (including via web + android / tv apps). My main question (part out of curiosity, part to ensure no gaping security risk) is what is the above actually implementing? Is it that we effectively have SSL encryption from REMOTE DEVICE<->NGINX SERVER which is then reverse proxied but encrypted again between NGINX SERVER<->PLEX SERVER? (i.e. there is in essence one superfluous extra encryption running on the plex server in contrast to a typically https->http reverse proxy)