ljm42

Please upload your diagnostics.zip file (from Tools -> Diagnostics). Also provide the output from these two commands: php /usr/local/emhttp/plugins/dynamix/include/UpdateDNS.php -v unraid-api report -v

OK NPM is a reverse proxy, which we don't yet support.

From your diagnostics, your [servername] is "Threadripper", your [LocalTLD] is "local" and Use SSL is set to "yes". So your url is: https://[servername].[LocalTLD] or more exactly: https://Threadripper.local That url should be listed in your ALLOWED_ORIGINS, right? So that url should work without an "unexpected token" error. What url are you trying to use that gives an "unexpected token" error? Note that you can adjust your [servername] on the Settings -> Identification page and [LocalTLD] on Settings -> Management Access. LocalTLD should not be blank.

If the URL successfully resolves to your server then it can't be "dns cache poisoning" right? Or maybe I am misunderstanding what you mean by that term. I'm still not clear, are you accessing the server via one of the URLs listed in ALLOWED_ORIGINS, or are you using something else? Please try all of the urls in ALLOWED_ORIGINS, do any of them work without this "unexpected token" message or do they all have that message?

@Mathy The "unexpected token" message generally means you are accessing the server via a URL that it is not configured to use. I'm excited to say that this error message will be much improved in the next My Servers plugin release. Open a web terminal and run: unraid-api report -vv In the ALLOWED ORIGINS area of the report it will list out the configured urls, you need to use one of those url to access your server. Specifically note that reverse proxy urls are not listed there and are not supported.

Thanks for sending that information @Mathy The issue is that at some point you commented out the authentication information for backup.unraid.net in .ssh/config To fix this, on your flash drive, edit the config/ssh/root/config file and remove the # from the front of these three lines: #Host backup.unraid.net #IdentityFile ~/.ssh/unraidbackup_id_ed25519 #IdentitiesOnly yes Or delete the lines entirely and our script will add them back in. edit: in our next release we will recover from this automatically

Interesting. It is connecting to the right server but the authentication is all wrong. Please send me a direct message with the following info. There may be some private data here so send it directly to me rather than posting here in the forum. Open a web terminal and run these commands, then copy/paste everything to the message: ls -al /root ls -al /root/.ssh/ cat /root/.ssh/config cat /root/.ssh/unraidbackup_id_ed25519.pub Also attach your diagnostics.zip file (from Tools -> Diagnostics) Thanks

Your Local Tunnel Firewall and Peer Allowed IPs are definitely wrong. Rather than untangle it, I'd recommend that you delete this tunnel and docker container, then start over by following the guide in the first post carefully step by step. I can't think of any settings you should need to change that aren't mentioned in the guide. Also, I'm not sure what version of Unraid you are running but I'd recommend upgrading to Unraid 6.11.5 first so you have the latest code.

Open a web terminal and run: unraid-api restart Wait a few minutes, then run this again unraid-api report -v If it still isn't able to connect, we are in the process of finalizing a new release which should resolve this.

Specifically which of the urls listed in ALLOWED_ORIGINS are you using to access the server? If you can access the server with that url then DNS cache poisoning is not the issue. If you are using a url that is NOT listed in ALLOWED_ORIGINS (such as running through a reverse proxy) then the "unexpected token" error message is normal. Reverse proxies (or accessing via any url not listed in ALLOWED_ORIGINS) are not supported.

Is the peer file on your iphone current? It needs to be manually updated whenever you make a change to the wireguard config on the server.

@count-zero @krh1009 @Mathy I am still trying to track this down. Everything appears to be setup correctly on our end, but I can see that you and a handful of others are getting this Permission Denied error despite that. Would you please open a web terminal and show the output from this command? ssh -T [email protected] If everything is working correctly you should see: If you see something else, please show the output of this command in verbose mode: ssh -T -v [email protected] (I am trying to determine if it is getting blocked by our server or if perhaps there is a firewall that is preventing you from connecting with our server)

On the static route, why is the distance set to "2"? Try "1".

The "unexpected token" message means you are accessing the server via a URL that it is not configured to use. I'm excited to say that this error message will be much improved in the next My Servers plugin release. Open a web terminal and run: unraid-api report -vv In the ALLOWED ORIGINS area of the report it will list out the configured urls. I'm guessing you are using a url that is not in that list?

I would add static routes in your router rather than trying to script it on individual computers. BTW we have a separate guide for setting up LAN to LAN WG here: https://forums.unraid.net/topic/88906-lan-to-lan-wireguard/

Seems like this would do the trick. I would probably start by double checking the static route and making sure there is nothing in the router that is firewalling the traffic. Also make sure you haven't inadvertently blocked anything with the Local Tunnel Firewall in the WireGuard config.

Have you ruled out the Local Tunnel Firewall feature? You can click the "?" in the upper right corner of the page to turn on help and see how it works.

What url are you using to access the server? If it is a myunraid.net url then you should not see that message. If it is still the old unraid.net url then you haven't completed the migration. If you have questions, let me know what version of Unraid you have and where you are in the migration instructions (first post of this thread)

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)

Yeah browsers are complicating things by assuming https. If you are happy with http for the webgui that is fine, if you want to use https Unraid offers two options: * a self-signed cert (which browsers also complain about) * a Let's Encrypt certificate on a custom myunraid.net url (no complaints from browsers) Instructions are here: https://wiki.unraid.net/Manual/Security#Securing_webGui_connections_.28SSL.29 ... FYI, now that you are on Unraid 6.11.5 you can go to Settings -> Management Access and get a list of the Local Access urls valid for your system. With current settings you should see: * http://ipaddress * http://HomeNAS As you change settings to enable SSL, this list of urls will change. I highly recommend that you go to the Apps tab and install the "Fix Common Problems" plugin, it will let you know if there are any common configuration problems you should fix. It will have a suggestion for your "Local TLD" setting.

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)

I can't say that I understand what you did, but I'm glad that you got it working

You can read about the different allocation methods here: https://wiki.unraid.net/Manual/Shares#Allocation_method

In certain conditions (usually when there is unexpected output from a cron job or the 'at' command), Linux will send an email to root of the local server. If you have email notifications configured that message will get forwarded to your notification email account. It may look like it went to '[email protected]' but clearly it didn't, as it ended up in your account. The fact that the email was sent is not a bug, but ideally the cron job or at command would be fixed to not have unexpected output. It looks like something in the 6.9.2 diagnostics is triggering this for you. There have been many improvements to the diagnostics script in the nearly two years since Unraid 6.9.2 was released. To get them you simply need to upgrade to the latest release of Unraid.

This will be fixed in the next My Servers plugin release