ljm42

We have a 6.12.4 rc release available with significant changes to networking, would appreciate your help confirming it resolves this issue:
 
 

If you are still on 6.12.1, please upgrade to 6.12.3 and provide diagnostics ( << click the link ), preferably after the problem happens
 
 
Depending on the problem, these may help:
/etc/rc.d/rc.php-fpm restart /etc/rc.d/rc.nginx reload  
 

You would need to contact your ISP to get a new WAN IP.
 
Be sure to setup a custom/random WAN Port for the server:
https://docs.unraid.net/connect/remote-access
Or disable the port forward if you don't want to use it any more.

This log is currently limited to 10MB, so it isn't going to fill your log partition on its own. In the next release we are going to cap it at 2MB IIRC

This system has call traces related to macvlan, please see the release notes:
https://docs.unraid.net/unraid-os/release-notes/6.12.0#known-issues

What version are you comfing from?
 
Your SSL port is set to 80443, but the max is 65535
 
Carefully edit the config/ident.cfg file on the flash drive and change this line:
PORTSSL="80443" to something else, like:
PORTSSL="40443" (or any other number between 1000 and 65k that isn't in use by a Docker container)
 
Then reboot the system.  Based on your settings, the webgui should be available at these urls:
  http://192.168.1.75:8080
  http://Tower.local:8080

Update - if the array can't stop due to "Retry unmounting shares" in 6.12.0 - 6.12.2, the quick fix is to open a web terminal and type:
umount /var/lib/docker The array should then stop and prevent an unclean shutdown.
 
(It is possible the array won't stop for other reasons, such as having a web terminal open to a folder on the array. Make sure to exit any web terminals or SSH sessions in this case)
 
We have a fix in the 6.12.3-rc3 prerelease, available here:
The fix is in the 6.12.3 release, available here:
It would be helpful if some of the folks who have been having an issue stopping the array could upgrade and confirm the issue is resolved in this version. No need, this fix is confirmed.  Thanks to everyone who helped track this down!

Please upgrade to 6.12.3 and try again, it includes fixes for networking and Docker:
https://forums.unraid.net/topic/142116-unraid-os-version-6123-available/
 
Be sure to read that announce post to prevent issues when shutting down the array in 6.12.2

Unraid Connect Remote Access is only able to give you access to the Unraid webgui, not to your Docker containers. If you need to access Docker containers or VMs or other items on your network, you'll want to setup WireGuard VPN:
  
 
 

You are having a conflict between the built-in WireGuard and the WireGuard Easy Docker container.
 
You should use either the built-in WireGuard or a Docker container, but not both.
 
If you want to use the built-in WireGuard, delete the Docker container and see:
  https://forums.unraid.net/topic/84226-wireguard-quickstart/
 
 
If you want to use a Docker container for WireGuard, go to Settings -> VPN Manager and make sure nothing there is running or set to autostart. Then *just* use the Docker container from here on out.   Support for the "WireGuard Easy" Docker container is here:
  https://forums.unraid.net/topic/117195-support-smartphonelover-wireguard-easy/

The issue is that you have two WireGuard configs that are using the same IP address. Assuming they are wg0 and wg1, run these commands
wg-quick down wg0 wg-quick down wg1 Then run:
/etc/rc.d/rc.nginx reload  
That should give you access to the webgui. Navigate to Settings -> VPN Manager and review wg0 and wg1 and make sure they are setup for different network pools and IPs before restarting the tunnels.

This test will be improved. But you can prevent the warning in the meantime by deleting config/vsftpd.user_list from your flash drive.

We are working on a fix for nginx with IPv6 but for now you should go to Settings -> Network Settings and change eth0 to "IPv4 only" if that works in your environment.
 
Also, please see my comment here about browsers potentially causing issues with backgrounded tabs:
https://forums.unraid.net/bug-reports/stable-releases/612-unraid-webui-stop-responding-then-nginx-crash-r2451/page/3/?tab=comments#comment-25245
 

Unrelated to the release, you can turn help on/off by clicking the question mark icon in the upper right corner of the page.

Fix Common Problems has the answer:
Fix Common Problems: Error: macvlan call traces found  
See this from the 6.12.0 release notes:
https://docs.unraid.net/unraid-os/release-notes/6.12.0#call-traces-related-to-macvlan

The webgui has blocked iframes for some time now.
 
In 6.12 or with the Connect plugin installed, there is an exception to allow connect.myunraid.net to iframe it. There isn't a config option to allow other websites to iframe it.

This is part of a call trace related to macvlan. See this part of the 6.12.0 release notes:
https://docs.unraid.net/unraid-os/release-notes/6.12.0#call-traces-related-to-macvlan 

Hey everyone, Unraid 6.12.1 should resolve the issues in this thread:
https://forums.unraid.net/topic/140824-unraid-os-version-6121-available/
 
Well, unless you are running SSL on port 445, you'll still need to tweak that setting to prevent a conflict:
https://forums.unraid.net/topic/140510-complete-webui-breakage-after-6120-update/#comment-1271735
 
If you can't currently access the webgui in 6.12.0, see the manual upgrade process here:
https://docs.unraid.net/unraid-os/manual/upgrade-instructions/#manual-upgrade-or-downgrade
 
If you continue to have issues, please start a new thread and be sure to include your diagnostics.zip from 6.12.1

Let's see if this helps...
 
This is the url to your Unraid webgui:
  https://ip-dashed.hash.myunraid.net:port
 
This is the url to your docker container's webgui:
  https://myip:port/somepassboltgeneratedhash
 
They are not related in any way. The certificate used for the Unraid webgui has no bearing on the certificate used for the docker container.

Since you are having issues with the Passbolt container, I'll recommend that you ask your questions in the support thread for that container:
  https://forums.unraid.net/topic/119569-support-smartphonelover-passbolt/
The folks there will be the most knowledgeable about how to configure SSL for that container.
 

This can definitely work. So eth0 on each server should be connected to your normal switch. If eth0 on both is 10g and you have a 10g switch then I wouldn't bother with the steps below. But if one or both servers can't connect to the main network at 10g then the steps below will let the two servers talk to each other at 10g while still using eth0 to talk to everything else.
 
Direct connect the 10g nics on each server and statically assign them to a new subnet with unique IP addresses and no gateway.
 
In my case, my eth0 IPs were:
server1: 192.168.10.50 server2: 192.168.10.160  
So I made my direct-connected 10g eth1 IPs:
server1: 192.168.11.50 server2: 192.168.11.160 so it would be easy to keep them straight.
 
I generally say to avoid jumbo frames, but since this subnet will *only* have these two computers on it, as long as you change the MTU of both to 9000 then jumbo frames should give a small speed boost. It is critical that every computer on this network have the same MTU.
 
When connecting between the systems it is *important* to use the IP addresses on this subnet and not a name like "tower". You want to be sure the servers actually talk over this network.
 

 

nginx: 2023/06/15 10:08:43 [emerg] 3876#3876: bind() to 127.0.0.1:445 failed (98: Address already in use)  
nginx is unable to start SSL on port 445. When picking custom ports for things, it is best to use high numbers (over 1000, less than 64,000) that will never conflict with built-in ports.
 
I'd recommend carefully editing config/ident.cfg on your flash drive and changing:
PORTSSL="445" to something higher, like:
PORTSSL="3443" (assuming that isn't in use by a Docker container)
 
Once that is done you may be able to get the webgui by typing:
/etc/rc.d/rc.nginx reload Or it may take a reboot.

You can't use WireGuard to join two networks that have overlapping subnets.  So if one is 192.168.1.x and the other is 192.168.2.x then you are fine (assuming the subnet mask on both is 255.255.255.0). 
 
But if both networks use 192.168.1.x then you can't join those networks.  In that case you can use the "Remote Access to Server" option and connect to the server via the server's tunnel ip. You will have access to the server only, nothing on the remote network.

You can probably disable the onboard NIC in your BIOS.
 
Or you can go to Settings -> Network Settings -> Interface rules and adjust so that the 10GB nic is eth0
 
Either way, note that when your server reboots it will get a different IP address from the router since the 10GB nic has a different mac address. It might help to have a monitor on the server so you can see the ip address on the console when the system boots.

You have a myunraid.net certificate, which uses URLs in the format:
  https://[ip-address].[hash].myunraid.net
 
If eth0 does not have an IP address, nginx is unable to start because it can't generate a server name for that URL. So we see this in your syslog:
May 29 00:47:53 Talonhawk root: Starting Nginx server daemon... May 29 00:47:53 Talonhawk root: nginx: [emerg] invalid number of arguments in "server_name" directive in /etc/nginx/conf.d/servers.conf:63  
For now, please make sure eth0 has an IP address.
 
This shortcoming will be addressed in 6.12.

You have configured Unraid to use port 84 for both http and https traffic, this will not work. They need to be on different ports.
 
The defaults are:
  HTTP port:   80
  HTTPS port:  443
 
The only reason to change the defaults is if you want to run Docker containers on those ports.
 
On your flash drive there is a config/ident.cfg file. Edit that and change these entries so that they are unique on the system and do not conflict with any Docker containers:
PORT="84" PORTSSL="84"  
After doing that, run:
/etc/rc.d/rc.nginx reload Or restart the server