ljm42

I can't think of any reason why http://10.168.178.25 would work for the webgui but http://10.168.178.25:Port_of_Service would not work for a container. My best suggestions are in my previous comment.

The setup seems fine, are you able to access the server's webgui? If so, at what url(s)? If you can access the webgui then you should be able to access docker containers on bridge without doing anything special. What url(s) are you using? If you are trying something like http://tower.local:1234 , that won't work because tower.local does not resolve over VPN. You'll want to use an IP address. If that doesn't help, be sure to go through the first two posts here: https://forums.unraid.net/topic/84226-wireguard-quickstart/ And finally, 6.11.3 is pretty old. I'd recommend upgrading to 6.12.4

How long are you waiting before pressing the button? Wait a bit longer.

see https://forums.unraid.net/topic/144827-dashboard-3-columns-and-save-it/#comment-1304262

To clarify, what is the exact command you ran here? Please run `/etc/rc.d/rc.nginx term` and then that command, to see if it is any different

I am kind of stumped. So you are getting a 500 error but nothing is logged in syslog or errors.log. Is Docker currently disabled? If not, please disable it and reboot. I just want to make sure there is not a Docker container responding on port 80.

aha! a 500 error means that nginx is responding to requests. via SSH, type ls -al /var/log/nginx/ This will show how big the nginx error log is. Then type: cat /var/log/nginx/error.log to see the error messages and paste the results back here.

Glad things are working well for you! Looks like you went with the "2-nic docker segmentation method", that prevents macvlan call traces because it avoids bridging on the nic that is running Docker. The downside is that it requires two nics, and it is a little more complicated than I would want all users to have to go through. For other folks, 6.12.4 has a one-click solution that only needs a single nic, but if you are happy using two nics then there is no reason to change anything.

Interesting : ) When I pass markdown to the notify script directly: /usr/local/emhttp/webGui/scripts/notify -e "My Event" -s "My Subject" -d 'See **Troubleshooting** section of online documentation for guidance on resolving this' -m "My Message" -i "alert" -l "/Dashboard" It comes through the email as markdown, so I'm pretty confident the notification system is not converting it to HTML I see where you are defining the string using markdown as `**Troubleshooting**`: https://github.com/itimpi/parity.check.tuning/blob/800138c7ac56b25bba0d6fdc7b9ca4e1e1c75606/source/usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php#L634 But I think something (maybe the translation system?) is converting the markdown to HTML before it is passed to to the notify script

Ah, it was not clear that you were rebooting between attempts. OK that is good. Please edit your message to delete all those individual files and upload the zip as a single file instead. I understand Macs can make this type of thing difficult. If you are choosing random ports, please use something higher than 1000 and lower than 64,000, and make sure it isn't already in use by a Docker container. Based on that screenshot it looks like nginx is running fine. What error message do you get when you try to access the webgui? Sometimes browsers will assume https, but you are trying to use http. So be sure you type "http" at the beginning of the address: http://192.168.4.41 or http://192.168.4.41:port in the browser's url bar

Hi @itimpi would you please remove HTML from the notifications from the Parity Check Tuning plugin? They are meant to be text only. I'd suggest using markdown formatting instead. I'm not sure if markdown in notifications would be rendered as html in the webgui, but markdown itself is pretty readable. This will prevent issues with emails that are sent as well as with notification agents that aren't expecting to get HTML.

According to your diags the ports nginx is trying to use are: PORT="80" PORTSSL="443" If you changed them to something else in config/ident.cfg, be sure to include the port when trying to access the webgui. Can you give more info on what you did here? Until you reboot, changing this setting in config/docker.cfg won't have any effect. To stop docker without rebooting, you can type this via SSH: /etc/rc.d/rc.docker stop but before doing that... I think nginx is not stopping properly, which means it can't restart properly. Please connect via SSH and type: /etc/rc.d/rc.nginx term followed by /etc/rc.d/rc.nginx start and paste the output of both commands back here. If this doesn't solve the problem, please provide updated diagnostics as well (type "diagnostics" and then grab the latest zip from the logs directory on the flash drive)

With the Dynamic options, remote access is disabled until you use the Connect Dashboard to enable it when needed. In your screenshot, clicking on the blue "Connect Dashboard" link will take you to the Connect Dashboard here: https://connect.myunraid.net/ Once signed in there, go to your server's details and click Start Remote Access For more info about the Remote Access features of Connect, see the docs here: https://docs.unraid.net/connect/remote-access/

What URL are you trying to use? What error message are you getting? Note that your myunraid.net url will not work because DNS Rebinding Protection is enabled on your network. Based on your current settings I would expect these to work: https://r620.local:5978 https://192.168.178.83:5978 If not, when signed in via ssh type `use_ssl no` and then try accessing: http://192.168.178.83:5975 That hasn't been updated in a while, you can try deleting config/plugins/theme.engine.plg from your flash drive and rebooting.

Oh I see the issue. Edit config/ident.cfg on the flash drive. Find this line: PORTSSL="88443" 88443 is too big, change that to a number between 1000 and 64000 Then run /etc/rc.d/rc.nginx start