elibosley

Thank you for the report on the $i18n issue. We're looking into this on our update application.

Thanks for highlighting this. We're in a strange intermediate phase of moving the header to a new Vue Component driven approach, while still dealing with legacy CSS to do this, which is causing these UI regressions. We'll get an updated Connect release out sometime in the next couple weeks with a fix for this as well as the other CSS issues that some users are seeing, and I appreciate your patience while we move towards a more flexible UI for the future.

7.2.2 is also out if you want to upgrade, includes the API that the Connect plugin you installed ships with to fix the flashing. The max_children setting means that there is a lot of activity on your server's webGUI, causing a lot of workers to be spawned by PHP - do you have a lot of containers, etc. that might cause this to happen?

Thanks for flagging this. I’ll see what I can do about this as well this week.

This is definitely an error on our new install check. Thanks for flagging this we will sort it out.

Thanks for this info. Definitely some strange edge cases around installs, not sure what this is caused by but we’ll see what we can do.

100% heard and understood. We're hesitant to restrict this for 7.2 but will likely improve this in 7.3 (and future Connect plugin releases before 7.3 stable). If you have a specific request related to this, please submit a feature request on the Unraid API Github (https://github.com/unraid/api). Thanks so much for bringing this up and please keep suggesting features! We're doing our best to build the stuff you guys are asking for!

We are pretty sure this is related to nchan not to Unraid Connect. Please try running this in SSH console and see if you are able to access the webGUI. /etc/rc.d/rc.nginx reload

This thread is being discontinued in favor of live updates from Github, follow them here: https://github.com/unraid/api/releases We may also post additional changelog updates in the Discord server (https://discord.unraid.net) and will continue to monitor the forums for support, we just won't continue to post release notes here.

It was indeed an infrastructure issue on our end . The delay in the solution working was due to our script needing to backfill every sign in into our auth system. If you continue to have issues signing in, try going to the keys page in the account app, then back to the register server page. This will force a token refresh and validate the sign in.

It is not but I’m working on a more permanent solution now. These internal keys should be generated on first boot and not regenerated, We will be moving to a more maintainable system in a coming release.

I’m really not sure what causes this. When you refresh your webgui it’s definitely not installed? Does the unraid-api command do anything? Seems like an issue with some finalization check we do but I don’t know why it would cause the API to not actually be installed.

Just delete them all and restart the API. I need to figure out why this occurs sometimes.. (unraid-api restart is the command)

Your Connect plugin is very out of date. Update it and it will show up.

Every key is read by a file watcher - I wonder if our watch system doesn’t fire reliably on the flash drive. We will continue to investigate!

Please try to use Settings -> Management Access and utilize the GUI to create keys / manage the sandbox. It may work for you and resolve this pain.

Are you sure your flash drive is good? Try writing a file on your flash drive and see if you can read it or delete it, sometimes broken drives can cause this when they fail into read only mode.

This is currently a bit broken, we removed the check in logic from servers and are relying on a legacy data point for this. There will be a new version of mothership published in the next month or two that will resolve this for good.

Actually, rebooting shouldn’t be necessary, it seems like your api may have failed to configure and resolved on a reboot but ideally this would not require a reboot! Sorry about this.

Just followed up on that GitHub thread. I’m very interested in solving this for you and others, and I think I need a bit more logging and information about what the exact request from HA is that is failing.

You may need to forward your server or be on wan, there is a system called nat reflection that can allow the wan address to be used internally but it is likely that from within your own network you will only be able to use the lan address (and that’s expected).

Awesome! Let me know if you continue to have issues (feel free to direct message me your IP address as well) as that will allow me to see if you’re being rate limited by our firewall!

We were having issues with the backing server for Connect, which have been fixed now. Please try signing out and back in on your server again!

This all seems to be related to the issue we discovered today causing problems with the database backing mothership. Please try signing out and back in and let me know if issues persist.

This was a bug in our registration system. This is now fixed, please try again!