groot-stuff

That is the entirety of the abc.subdomain.conf file for my unraid subdomain located in /mnt/user/appdata/swag/nginx/proxy-confs/ You may have a slightly different path to the proxy-confs folder though, depending on your setup.

I quoted part of my post from way earlier in the thread, the next thing I'd suggest is capturing some packets to inspect/investigate with WireShark or similar tool. Just switch out the IP in the command below for the one of the machine you are using to SSH into unRaid with. Then take the .pcap file into WireShark and see if there are any oddities, feel free to share the .pcap if you'd like (DM it so you don't have to post potentially identifying IP info to the world). tcpdump -i any -nn -t -e dst not 192.168.0.254 and src not 192.168.0.254 -w unraid.pcap Refer to my older post for more info/instruction. Definitely make sure to reduce network traffic to clean up the tcpdump (turn off Dockers & VMs). https://forums.unraid.net/topic/96835-dns-resolution-issues/?do=findComment&comment=892657

What address are you pinging... a domain or an IP? Are the results of these two commands the same? and same initial delay? ping ns1.google.com ping 216.239.32.10 Are the VM's being assigned their own IP addresses? Same subnet as host unRaid machine? Are they assigned the same or different DNS servers?

After resetting my Plex account password I ran into this same issue. Solved it by doing 2 things: 1. Following the Remove Certain Entries > Linux instructions at this link (delete 4 PlexOnline attribute/key pairs from Preferences.xml file) https://support.plex.tv/articles/account-requires-password-reset/ 2. Following the Sign In/Claim Your Plex Media Server > Docker instructions at this link (to generate a new claim token) https://support.plex.tv/articles/account-requires-password-reset/ Once I updated the claim token in the docker's config and clicked Apply, the docker restarted. I immediately went to http://unraidIP:32400/web in an incognito browser and signed in. Everything was restored and no further action was needed. Signed back in through a normal Chrome browser and I am 100% back to expected functionality.

This is what I've got configured and the progress UI updates, but at a much slower rate than without using the reverse proxy (maybe every 15-30 secs), so often times the entire docker update is completed by the time it updates. When installing/updating larger dockers (like Android Studio) I can see the progress updates come through mid-process. server { listen 443 ssl; listen [::]:443 ssl; server_name unRaidSubdomain.*; include /config/nginx/ssl.conf; client_max_body_size 0; # https://forums.unraid.net/topic/73158-progress-ui-not-working-through-reverse-proxy/page/2/ gzip off; proxy_buffering off; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia #include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia #include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; proxy_pass https://[unRaidIP]; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; } } Its been a while, but I think these are all of the additions I made when I was messing with it... In the server block: gzip off; proxy_buffering off; In the location block (my webui is set for HTTPS only): proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade";

Trying to help here but you'll need to provide more information than just symptoms... What DNS servers are you using? Have you tried others? Which ones? How long after a reboot can you resolve a domain? Minutes, hours, days? Are you using an ISP provided modem/router or have your own equipment? Do you have any "safe browsing" or security services included from your ISP? (like the person above) Are you running through any VPN or proxy connections/services? Are you able to ping 8.8.8.8 from the terminal when the problem is occuring? (that would rule out a more general loss of connectivity) What other troubleshooting steps have you tried aside from just rebooting?

Possible, but unlikely if it is only Sonarr. Would need more information to help troubleshoot, which Sonarr container you are using for starters. Also, rather than rebooting your whole server, have you tried just restarting the container? Verifying a DNS resolution issue with one container would also require getting into it's own shell, are you familiar with that? (it's easy after setting up the docker-shell script) If it's binhex's Sonarr container I would highly recommend shifting your dialog to his support thread here. Occasionally I see indexers not working in Sonarr/Radarr simply because the API's limit has been reached for whatever "request per time period" it is restricted to. Nothing to fix that particular issue aside from waiting. Have you check for errors under System > Status & System > Log Files?

It is entirely possible that your ISP is blocking outbound requests on port 53 (DNS). Quoting that answer so you don't have to click the link... "Yes, they can block custom DNS - and its fairly trivial. All they need to do is block port 53 exiting their network (except from their nameservers - but in practice its more likely to be from their broadband IP ranges) The logical reasons for doing this include (which I vehemently disagree with, but thats besides the point) tracking usage, forcing traffic to local caches, blocking access to certain sites, injecting adverts instead of errors for non-existent domain names. There could theoretically also be benefits to you (prevent some kinds of malware, faster DNS resolution times for people with wrong DNS settings)" To test if they are, just run this at the terminal: telnet 8.8.8.8 53 If it times out/fails to connect then your ISP is blocking outbound requests on port 53. This is what my successful result looks like (not blocked):

Wow... 10gig - impressive for in-the-home speed availability! 💪 I'm not sure if I mention this anywhere, but the one thing that did change in my setup was the firewall (but not the config). Went from an old Zyxel USG50 to a Zyxel VPN100... maybe some differences in the firmware that cause it to handle DNS requests differently. I have updated the VPN100's firmware a couple times since this issue but haven't bothered to take my array offline to test going back to using OpenDNS rather than my router's IP for the DNS entry in unRaid. As far as ISP, I've always been on a dual-WAN setup through a basic Arris coax modem (SB6141 before, SB8200 now) and Zyxel firewall (USG50 before, VPN100 now), with 1gig (now 1.2gig) Xfinity/Comcast as the primary and CenturyLink/Level3 as failover-only (no round robin or least-load-first because clink is SO slow (20/1Mbps)). If you don't have much configurability with the ISP provided fiber box... have you tried altering the DNS entries within unRaid (Settings > Network) to test using public DNS options as well as your default gateway/fiber box IP?

What worked for me was (strangely) setting the first DNS entry to my router's default gateway... typically something like 192.168.1.1 unless you have a custom subnet setup. Worth a try - but IMO setting up a custom network is more fun than using ISP provided equipment. ☺️

Did you fix the typo? See the blue text in my post above

Please provide the DNS entries you see when using both of the configurations... the finest details can be the culprit with these types of issues (see my post above for all I went through) These can be acquired from Settings > Network Settings or the results from cat /etc/resolv.conf at the command line

The recommended setup in many other places is to only use public DNS servers and remove all entries for your router. Honestly this is what I prefer, but my new firewall of the same brand is acting subtlety different. So the first thing I would try is using only public DNS servers, i.e. just 208.67.220.220 208.67.222.222 Actually... looking closer at your screenshot, your 2nd entry (1st external IP) has a typo (222.220 should be 220.220). Hopefully its that simple, but if not... What do you have starting with the array? I'd suggest testing these independently... Dockers set to auto-start Settings > Docker > Enable: Yes/No If disabling the Docker service works, continue testing by enabling one Docker at a time, testing after each one VMs set to auto-start Settings > VM Manager > Enable VMs: Yes/No UserScripts plugin with a script set to run on array start Change schedule(s) to "Schedule Disabled" Also think about any other custom scripts or configurations you may have. For example... custom docker networks or ip routing rules. I would also suggest getting into the shell of a docker container and trying the DNS lookups from within it. This is where I isolated my issue because the docker network uses a different DNS resolver/address (127.0.0.11 with my config). Guide to setup docker-shell'ing:

Have you tried setting your DNS in the unRaid webui to external DNS servers (Google, OpenDNS, etc.)? If you have tried external without success, also try setting them to your router (typically the default gateway address a.k.a. your routers IP address) - this solved it for me, strangely. Please give more info of your config, symptoms and troubleshooting already completed for the community to provide assistance (rather than guesses). Lastly, I wrote an extensive post about the troubleshooting I did here:

Necro post with value below, as this is the top Google result on the topic. bulldozer !'s question on @SpaceInvaderOne's recent video (How to Test the Speed inside a VPN Download Container: https://www.youtube.com/watch?v=m7Qly7a_-M0) prompted this post. WARNING! EDITING THE sudoers FILE (OR ANY FILE THAT FEEDS INTO IT) INCORRECTLY CAN CAUSE IRREPERABLE DAMAGE AND POSSIBLE LOSS OF ACCESS TO YOUR SYSTEM! YOU HAVE BEEN WARNED. Only use visudo to edit the sudoers file (or any file that feeds into it)! visudo performs checks to aid in correct sudo file formatting (it is not fool-proof, double check your formatting!). Learning vi/visudo is on you, Google it for plenty of resources! https://lmgtfy.app/?q=how+to+use+visudo+in+linux Also, I am no Linux expert, but have used this method to successfully add a user to the sudoers list - on boot. Okay, now that the disclaimers are over... lets check out a more complete explanation of adding a user to the sudoers list without the use of any additional tools/plugins (UserScripts is great btw, I use it heavily on my server). Understand that sudo access can be dangerous, do not give this to users who do not understand it's power The /etc/sudoers file itself does not need to be edited, by default it will include the /etc/sudoers.d/ directory (below is a snippet of the end of the sudoers file) ## Read drop-in files from /etc/sudoers.d ## (the '#' here does not indicate a comment) #includedir /etc/sudoers.d Create a file named sudoadd (no .extension), using visudo, in /boot/custom/ /boot/ is your flashdrive, storing the file here allows it to survive reboots and unRaid to access it while booting up You may need to create the /boot/custom/ subdirectory I had the subdirectory after following Spaceinvaders video on setting up the docker-shell script Add the following to the sudoadd file (adjusting USERNAME to the one you'd like to use) ## ## User privilege specification ## USERNAME ALL=(ALL) NOPASSWD: ALL This is in the format of root's section in the /etc/sudoers file NOTE: the "NOPASSWD: " is not required and allows the specified user to execute the sudo command without entering a password Again, this is another dangerous setting... see this article for more info: https://www.tecmint.com/run-sudo-command-without-password-linux/ If you prefer to enter a password when using the sudo command, just remove "NOPASSWD: " The resulting line (password required) would read as: USERNAME ALL=(ALL) ALL Write the file and Quit (generally ESC > : > wq > ENTER in visudo) Next we need to tell unRaid to move the custom file and set it's permissions appropriately in the go file AGAIN, BE CAREFUL - THE GO FILE IS VERY IMPORTANT, IT STARTS YOUR WEBUI! Add the following to the end/bottom of the go file located at /boot/config/go cp /boot/custom/sudoadd /etc/sudoers.d/sudoadd chmod 0440 /etc/sudoers.d/sudoadd The first line copies the custom sudoadd file from the flash drive to the OS files running in memory The second line changes the permissions on the copied file to what Linux expects for a system file (IIRC) Also add the following to the end/bottom of the go file chsh -s /bin/bash USERNAME This line changes the shell for the USERNAME you specify, allowing the user to login via SSH I use vi to edit the go file, so Write the file and Quit (generally ESC > : > wq > ENTER) If you're using another editor, save the go file and exit Reboot your server and test that the USERNAME you setup above can: Login via SSH Execute the sudo command P.S. I normally give full credit via links to sources where possible, but I researched and successfully did this a very long time ago. That aside, this thread and @SpaceInvaderOne were definite contributors of my solution. If something in this post needs to be clarified please reply or message me and I will update it

This is great, I was going to attempt to recreate the Docker Safe New Perms script and run it on a schedule for my Dropbox share... now I can just throw this one line into the User Scripts plugin! Link to the source code if anyone is interested: https://github.com/limetech/dynamix/blob/master/plugins/dynamix/scripts/newperms +1, love you @Squid

Despite the thanks... gzip off; doesn't work for me @Indmenity83, or I am not entering it in the right .conf file. I have tried in my nginx x.subdomain.conf file (below) as well as the main nginx.conf file (changing from on to off) and the site-confs>default file. Where are you entering this? server { listen 443 ssl; listen [::]:443 ssl; server_name myunRaidSubdomain.*; include /config/nginx/ssl.conf; client_max_body_size 0; gzip off; location / { include /config/nginx/proxy.conf; proxy_pass https://[unRaidIP]; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; } }

Thank you @maciekish and @Indmenity83 for pursuing the resolution of the problem presented in the OP. I too have experienced unhelpful and out of scope "resolutions" in the past. The key to this thread is that regardless of the security of the application in question, the question is not how to "be more secure" or "work around the problem"... it is about solving the problem presented. I too use a reverse proxy to access my unRaid gui... which is completely restricted to internal machines or those connected to my VPN. There is no security risk to my unRaid gui, being behind a reverse proxy that only works... on the internal network, the same as the local IP of the gui. Again, really appreciate the nginx response from @Indmenity83, thanks to you both!

Curious, what DNS settings resolved your symptoms? I had a similar issue and despite most threads saying to assign public DNS servers (my usual config), setting unRaid's first DNS server to my local router resolved it.

@Squid I understand you aren't a networking guru, but thank you very much, I really appreciated your instant CA update to help me troubleshoot. After a nice hike yesterday and good night's sleep, I banged my head on the keyboard some more this morning. I would hate coming to a thread with a similar or same issue... read through and it ends without a resolution. I would equally hate a final post from the OP saying "Never mind, I fixed it." because it doesn't help the next person that a Google search lands here. Request: I am a not a networking expert and would LOVE someone who is - to take a stab at why this resolved the issue... despite no changes being made to the router or unRaid network config that would have caused it. So further down the troubleshooting rabbit hole: - I stopped the array, same symptoms - I tested this because of reading posts about unRaid gui latency being caused by failing disks Next I dug through my mental cobwebs and found my 20 year old, uncertifed CCNA knowledge... along with many web articles, some linked below. - dig [anyDomainName.TLD] came back instantaneously... SO STRANGE, as here I am thinking unRaid is having DNS request time outs - This command allowed me to learn that my docker containers are using 127.0.0.11 as their DNS server... hence why docker containers had no symptoms - Resource: https://www.google.com/amp/s/www.hostinger.com/tutorials/how-to-use-the-dig-command-in-linux/amp/ So I ran tcpdumps on these various commands (curl, ping, traceroute and even clicking on the CA apps tab) to observe what is sent/received Digging into tcpdump of "curl ifconfig.io" - unRaid settings: external DNS servers statically assigned in Settings > Network (open DNS = 208.67.220.220 and 208.67.222.222) - The traffic (packets) going from point A to B were just fine, quick as it should be... but something was slowing the overall request down - 106 packets over 15 seconds - 33 of those were ARP requests to my local router asking "who has [myPublicIP]? - This got me curious... why is unRaid continually trying to figure out that my router is the next layer 2 (mac address) hop to my public IP? Digging into ARP requests - Resource: https://osqa-ask.wireshark.org/questions/5412/what-does-arp-42-who-has-19216811-tell-192168133-mean - ARP (Address Resolution Protocol) requests are similar to DNS requests but they are IP to MAC resolutions rather than Domain to IP resolutions - running arp -a was very slow (this shows IP addresses and their corresponding MAC addresses) - running arp -an (no DNS lookups) was instantaneous - Surprisingly this is the same after resolution, but it makes sense because DNS requests of each local subnet IP and 172.18.X.X docker subnet IP fail Digging into tcpdump of "curl ifconfig.io" with local router as the first DNS server - unRaid settings: local router and external DNS servers statically assigned in Settings > Network - local router as #1, then open DNS = 208.67.220.220 and 208.67.222.222 as #2 and #3) - 42 packets (64 less) over less than 1 second (14 less) - None of those (33 less) were ARP requests to my local router asking "who has [myPublicIP]? Symptom Resolution: - CLI requests to WAN resources are instantaneous (as expected) - Plugins tab loads in ~5 seconds (background update checks are enabled) - CA tab loads in 2-3 seconds - Dockers update and retain icon image - Fix Common Problems plugin scans within 15 seconds now (took multiple minutes before) Unresolved symptoms: - Docker's still show version "not available" - Forcing an update resolves this, but I am going to wait overnight to see if the scheduled update check resolves it (will post again tomorrow) - UPDATE (same day): I triggered a manual check for docker updates and about 15-20 seconds later all 17 of my dockers had no more "not available" - traceroutes to my default gateway still fail @Squid So, it was my network... I think? lol

I updated CA and it loads now, under 30 seconds on the few tries I did. Still have the same slow response on curl, ping and traceroute requests on the host, dockers are still ok.

Same results even when using open dns (what I usually use, firewall assigns them to devices rather than itself). Same with google and cloudflare dns servers - all statically set in Settings > Network. Regarding "it's not my network" - I let my OP be open-ended, but I feel it is ip routing or dns resolution. Just not the network numbers I'm typing in or configuration of my firewall. Literally nothing has changed on that side, and connection requests from dockers and vms are unaffected. Edit: also no pfsense or other proxys between the unraid box and WAN. Thoughts on my ip routes and traces? I have nothing to compare them to, nor have I ever recorded the same in the past. They are only what unraid generates, aside from the metric = 1 for the IPv4 gateway I set in the gui when troubleshooting. The 14-16 second curl ifconfig.io response is very consistent, same time span for a domain name ping to start hitting the resolved ip. Could it be attempting to route through the 172.18 docker network then falling back to eth0/br0?

I am running into the same issue multiple people are having here, I have read over a dozen threads both old and new. Nothing is working, please don't give me the "it's your network response". When attempting to load the CA tab I get this error: That is only one symptom, I have the other symptoms other's have described: - Intermittent access to CA list (occasionally it loads, most often it times out after 60 seconds) - Docker containers show version "not available" - Forcing the update of a Docker container causes the icon to disappear and show the ? one - When a Docker is missing an icon, loading the Docker tab takes 15 seconds (research shows this is the standard timeout, down from 60 in the past) - I learned how to manually resolve this (where to save the image files and naming convention) - Commands with IPs such as "ping 172.217.12.14" (google.com's ip address) come back instantly - Commands with domains such as "curl ifconfig.io" and "ping google.com" take 10-14 seconds to return anything (ip address or start pinging the ip) - These same commands run instantly, as expected, when run in ANY docker's shell - So we know the network card and subnet/firewall is capable - Commands and speed tests run on a fresh W10 VM are instantaneous and pull my full gig bandwidth - So we know the network card and subnet/firewall is capable Facts and attempted resolutions: - I have rebooted numerous times, re-logged-in through a new browser with cache cleared, re-logged-in through SSH - IPv6 is disabled on unraid and my firewall - I setup letsencrypt docker with reverse proxy a few weeks ago, everything worked fine, still does - This required setting up a custom Docker network (proxynet, as instructed in SpaceInvaderOne's video) - That network has a metric of 1 in my ip routes, whereas my eth0/br0 subnet always has a 200+ metric - I don't know how to change the new Docker network (br-b579...) to a higher metric... could this be the cause? - When Docker is enabled the 172.17.0.0/16 docker0 network shows up with a metric of 1, same symptoms (no dockers use it, all are on proxynet) - Screenshot above also has the "optional metric" for my eth0/br0 IPv4 gateway set to 1, yields the same symptoms - Only recent change is converting the letsencrypt container to swag (name, appdata folder and mapping, repo and icon url were all updated) - swag works fine, websites and dockers are all accessible as they were before (I only mention this because it is the only recent change) - No changes to IP scheme, masks or dns servers (the firewall provides ip/mac bound address and open dns servers) - DHCP and Static configurations yield the same symptoms - Yes I am using the correct mask, gateway and multiple DNS providers (open dns, google, and cloudfare) - I have tried with bonding/bridging: on/on, off/on, off/off (respectively) - I have tried with Docker/VM manager on and off - I have regenerated the /boot/config/network.cfg file and resolvr.conf (forget what path that one was at) - both update in response to changes in Settings > Network (evidenced by cat /boot/config/network.cfg and cat resolvr.conf) - I can ping: 127.0.0.1, 10.3.55.2 (server's IP), 10.3.55.1 (gateway), both ISP's modems LAN address and my WAN IP without issue... it's when I try to ping, traceroute or curl a domain name that it hangs 10+ seconds - Tracing the route to my default gateway though... doesn't work from unraid but it comes back as expected on any other VM or machine on the network (from VM on same subnet, 10.3.55.7) (from unraid console via ssh as root) So I really need some help here folks. I've attached what I thought would be helpful... let me know if other info is needed to help. After 8 hours of reading threads and troubleshooting I am at a loss.

These types of responses are not helpful and have rendered this thread useless to anyone who comes across it looking for the same information @Rhino2310 was looking for. Hopefully someone else can provide a helpful response to this simple syntax question. This config edit appears to be very common when considering YouTube videos demonstrate it and have multiple thankful comments on them. All the OP and I are looking for is a way to define multiple users in the highlighted config line below: [rootshare] path = /mnt/user comment = browseable = no valid users = write list = vfs objects = i.e. valid users = george,lucas,rey valid users = george;lucas;rey valid users = [george,lucas,rey] This is not a question about if it should be done, how it should be done (GUI, CLI, config edits, etc.)... Just CAN it be done? If it can, what is the syntax to define multiple users? If multiple users cannot be defined, can you essentially copy and paste the same share with a different user specified?