ljm42

Yeah, jumbo frames should be avoided. You have FCP installed, so it should have warned you and provided a link to: https://forums.unraid.net/topic/120220-fix-common-problems-more-information/page/2/#comment-1167702

Glad you are back up and running! Clearing your browser's cache is the quick fix, more detail here: https://forums.unraid.net/topic/145929-cannot-log-into-the-webui/#comment-1313523

Strict mode is available after you scroll down and provision a myunraid.net certificate More information about using SSL is available here: https://docs.unraid.net/unraid-os/manual/security/secure-webgui-ssl/

The Remote Access feature provides access to the Unraid webgui only. If you need access to Docker container GUIs you need to setup VPN.

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.

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