ljm42

*** *** ***
Edit - more detail is available here https://unraid.net/blog/ssl-certificate-update-2
*** *** ***
 
Thanks for the diagnostics. This is Unraid 6.11.1 with an old unraid.net certificate. Those started expiring at the beginning of January: https://unraid.net/blog/ssl-certificate-update . We'll be posting an updated blog post soon but this will get you back up and running:
 
Connect to the server using telnet/ssh and run:
  use_ssl no
Now you will be able to access the webgui using:
  http://ipaddress
(if you have trouble logging in after making this change, close all tabs that pointed to the server and clear your browser cache)
 
Navigate to the Settings → Management Access page in the Unraid webgui and click the "Upgrade Cert" button.
 
Click on the Certificate URL and verify you can access the server via the ipaddress.hash.myunraid.net certificate. You can change the "Use SSL/TLS" setting back to Yes or Strict if all is well.
 
When you get the chance, I'd recommend upgrading from 6.11.1 to 6.11.5, there have been many improvements.

It looks to me like the Telenet "Modem" is also a router, and you are in a double-NAT situation. Port forwarding is a pain with this setup, you need to forward port 32400 on the Telenet to port 32400 on the Asus, and then port forward 32400 on the Asus to Unraid. Or you may have luck putting the Asus in the Telenet's DMZ and then just setting up port forwards on the Asus.
 
Ultimately, I would avoid this situation if at all possible. Either get rid of the Asus and just do everything on the Telenet, or put the Telenet into "bridge" mode so it is just a modem and not a router (this will also disable its wireless capabilities)

On Settings -> Management Access, your "Use SSL/TLS" setting is set to "no".
 
With that setting, I would expect this to work:
  http://192.168.104.11
but not this:
  https://192.168.104.11
(note that one is http, the other is https)

Hi, this will be fixed in the next My Servers plugin release.  Thanks!

Your system is in Strict mode, so https://ipaddress is not defined as that url is not valid for the myunraid.net certificate.
 
You can use http://ipaddress (note http not https) to be redirected to the myunraid.net url.
 
If there are DNS issues and the myunraid.net url is not available, see https://wiki.unraid.net/My_Servers#How_to_access_your_server_when_DNS_is_down 

First, be aware that the dashboard will only show the remote access url if you are currently remote from your system, i.e. accessing the dashboard from outside of your house. If you are in your house it shows the local access url.
 
If that doesn't explain the issue, double check that Remote Access is still enabled and double check your port forward. Setup instructions are here:
  https://wiki.unraid.net/My_Servers#Configuring_Remote_Access_.28optional.29

Sorry for the trouble. This should be resolved by the work we are doing in the next plugin release.

You can think of the dashboard as list of your licenses, rather than a list of your physical servers. This is a license which you are not currently using, but is available to be downloaded and applied to another server.

There is a bug that happens directly after a reboot. It will be fixed in the next plugin release (soon), in the meantime you can open a web terminal and type:
unraid-api restart  

So the problem was this multibyte UTF-8 character: ˆ (which is not the same as ^)
 
This was fixed in 6.11.4, you can now use multibyte characters in passwords if desired:
  https://forums.unraid.net/topic/131122-unraid-os-version-6114-available/
 

Would you please open a web terminal and run:
unraid-api restart Does that fill in the blanks after a few minutes?
 
We are looking into an issue that happens when the system first boots
 
 
Also, please wait a few minutes and then give me the output of this so I can confirm what version you are running:
unraid-api report  

All caps really isn't necessary
 
First, go to the Plugins tab and confirm you have the latest version of the plugin, currently 2022.09.28.1258 2022.11.02.0859
 
Then open a web terminal and type:
rm /boot/config/plugins/dynamix.my.servers/myservers.cfg unraid-api restart  
Then *reload the webgui* and you will now be signed out of Unraid.net with no errors. Go ahead and sign back in and you'll be all set.
 
If you still have issues, please provide a screenshot showing the error message, and upload your diagnostics.zip file (from Tools -> Diagnostics)

No, as long as you've assigned unique ports to each service it should be fine

You have Unraid 6.11.1, so on the Settings -> Management Access page it lists the available urls for each scenario. In scenario one (Use SSL = No) only the two http urls should be list listed. Hopefully that is clear that the two https urls are not going to work?
 
If you are seeing something different please provide a screenshot of this page in scenario one. I need to see all the settings and the Local Access urls that are listed.
 
> displays sign-in screen but refuses signin as root
 
Your browser is confused because of switching SSL on and off. Two possibilities:
 
One - if you already have a tab open to https://rocky.local then the server will get confused if you disable https and try to access http://rocky.local in another tab.  So close all tabs pointing to the server but one. It may help to completely restart your browser or even your client computer to make sure there really are no hidden tabs open.
 
Two - Your browser may have cached a response that was valid for SSL being enabled but is no longer valid after disabling it. So after doing the above, try accessing the site in private/incognito mode. That will most likely work, so to fix it in your main browser you'll need to clear your cache.

Your scenario two results don't make sense I think this is more of the browser confusion mentioned above. Any time you change Use SSL from No to Yes or Yes to No you may need to repeat the steps above.
 

Sorry for the trouble, please see the discussion here https://forums.unraid.net/topic/126124-cannot-provision-ca-signed-certificate-fixed-briefly-currently-broken-again-multiple-weeks/page/2/#comment-1181483 
 

We are working through some stability issues, should be good at this time.

It sounds like Remote Access is no longer configured, here are instructions for setting it up:
  https://wiki.unraid.net/My_Servers#Configuring_Remote_Access_.28optional.29
 

The webgui can't start because port 80 is already in use, there is probably a docker container set to use port 80
Oct 25 11:52:03 Unraid nginx: 2022/10/25 11:52:03 [emerg] 11873#11873: bind() to 0.0.0.0:80 failed (98: Address already in use) Oct 25 11:52:03 Unraid root: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)  
Does anyone remember the easiest way to recover from this in 6.9.2? Docker containers still start in safe mode.

Yep, as mentioned in in the Discord thread we're looking at a fix to cache these lookups

That shows that the system is connected fine. If the dashboard says it is offline, that implies your browser is blocking websocket communication. While looking at the dashboard, open the Javascript Web Tools (CTRL-Shift-I in most browsers) and check the console tab, any errors? Copy / paste them here. You might also try private/incognito mode, or a different browser entirely.

@Autchirion And just like that we've got the fix  
  https://forums.unraid.net/topic/129257-6111-vpn-tunnel-failing/page/2/#comment-1182737 
 

There are multiple threads open about this issue, please see my comment here:  https://forums.unraid.net/topic/128043-my-servers-will-not-do-flash-backup/#comment-1167192
 

I agree it is odd, but apparently Docker is able to find a way to start the container even when the tunnel it is configured to use has not been started.

We are looking into our options. For now, you'll want to take care not to start the container until the tunnel has been started.

Server to Server will work, or import the config. If you don't setup a port forward that just means the other side can't initiate the connection, you will always have to initiate it from Unraid.

I don't see any messages on my server either so I'd say it "succeeds silently". If there aren't any messages you are probably fine.