ljm42

Both issues are about giving access to specific network interfaces. In the other topic the interface is called vhost0. In your topic it is called br0.60. Both should be fixed in the next release.

Thanks for reporting, this will be fixed in the next release

This looks to be the same as https://forums.unraid.net/topic/145706-remote-tunneled-access-wireguard-clients-lose-access-to-anything-but-server-upon-docker-start/ , it will be fixed in the next release

I added this to the first post to bring it up to date: # for 6.12 and newer use /dev/mdXp1 # for 6.11 and older use /dev/mdX For 6.12+ you would need to change this line in the previous script from: drive=/dev/md$dom to: drive=/dev/md${dom}p1

Thanks for reporting this issue @iarp and @Mainfrezzerfor the workaround. This will be fixed in the next release.

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)