ljm42

Sorry for the trouble. I'd like to raise visibility on this, but I am not clear what the proposed change is. Starting with a non-working wgX.conf file, please go to the VPN Settings page in Unraid 6.12.4 and make a dummy change, then Apply. Does that fix the issue? If not, please show a before/after snippet of the wgX.conf file to make it clear what the bad value is and what you are proposing that it be changed to. Thanks!

Odd. Double check that the plugin is uninstalled, and then reboot.

Containers with custom IPs work well on ipvlan too, but if you want to keep using macvlan just follow the instructions in the 6.12.4 release notes and you'll be fine too.

Go to Settings -> Network Settings -> eth1 and set the "address assignment" option(s) to none, then press the Port Down button. That should do the trick. Stopping the Docker service will stop the containers gracefully, it is fine to do that.

The diags were taken pretty soon after a reboot so they don't show evidence of the problem. But I'm guessing the system is crashing due to macvlan call traces. The quick fix is to go to Settings > Docker, switch to advanced view, and change the "Docker custom network type" from macvlan to ipvlan. For more info, see the 6.12.4 release notes: https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces

Glad you are back up and running. I wonder what configuration file was the issue.

Unraid works best when the main NIC is eth0. So one option is to change the order of the NICs on Settings -> Network -> Interface Rules so the Intel is eth0 through eth3 and the Realtek is eth4. But I think your plan of disabling the Realtek nic is better. In general, Realtek NICs have more issues than Intel NICs. Complex bonding is possible, but requires your switch to be configured properly as well. Issues with this will be very difficult for you to troubleshoot as it is unlikely anyone else in the community has your same combination of hardware with the same config. If speed is important, as an alternative you might consider upgrading to a 2.5gb or 10gb switch with corresponding NICs. I wouldn't expect Connect to need any special treatment throughout this, as long as eth0 is your main NIC. > PS If I change the IP assigned to the server will Unraid 'automagically' manage changes to the docker app to host port mappings? If Unraid set the IPs then I would expect the change to be automatic. Of course, anywhere that you manually typed the old IP would probably need to be manually updated.

When you enable/disable SSL there is a warning in the webgui: Basically, your browser is remembering that it used to use SSL for this url and it wants to keep using it. If you run into this, you need to close any other browser tabs that are pointed to the server and then clear your browser's cache. That should convince your browser to let you log in using the newly configured url.

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

Docker containers are not proxied through Unraid, so Unraid's certificate has no bearing on a container's certificate. You'd want to ask for help setting up that container in the forum thread for that container. The local TLD is used for URLS, such as: http://server.local https://server.local The https url will use a self-signed certificate which causes browser warnings. But other than that it is fine. If you had your own domain you could enter "mydomain.com" in that field and then the urls would be: http://server.mydomain https://server.mydomain This also requires you to have DNS and provide your own certificate. More details in the docs provided earlier Separate from that, once you provision a myunraid certificate you can access the server via a unique myunraid.net url using a valid certificate that we provide.

It seems that you are trying both fixes from the release notes rather than just one: Fix 1: change macvlan to ipvlan. If you are happy with that then you are done. Fix 2: if you want to use macvlan then disable bridging. This removes the option for ipvlan and always enables macvlan At this point you are using the second fix. That is fine. I modified the release notes to try and make it more clear that if you change macvlan to ipvlan, you are done! No more changes needed. If bonding is enabled you will see bond0, if bonding is disabled you will see eth0. Either works fine.