pujitm

Rest in peace, Ronald. Your work brought joy and light to many lives. You will be dearly missed.

huh, thanks. if i'm understanding this correctly, the api isn't actually starting after you run unraid-api restart right? could you paste the contents of /usr/local/unraid-api/ecosystem.config.json -- maybe it's corrupted?

btw your asks were well-received. short-term, we're trying hard to get Unraid 7.2 and the new Unraid API right, but we've definitely gotta give Connect some love

what unraid version are you running? also, does running unraid-api restart fix this specific error? and does your server show up in the Connect Dashboard (ie it's online and you can see the server's details)?

strange, what's the output of ls -al /usr/local/unraid-api/? is either ecosystem.config.json or /usr/local/unraid-api/node_modules/pm2/bin/pm2 a directory on your server?

@elibosley can confirm/deny, but I believe this was an infra issue on our end.

Thanks for the thoughtful writeup! I don't think your expectations are unreasonable at all. I'll bring it up to the team tomorrow.

if it helps, i was playing around with nushell & fish on unraid several months ago and switched between them explicitly instead overriding the default shell. was a fun/seamless experience! also, if you're trying to solve for a custom/pretty/low-effort prompt line, https://starship.rs/ is compatible with bash.

Running this command via terminal could help: unraid-api plugins add unraid-api-plugin-connect -b if it doesn't, could you provide the versions of your connect plugin and the api? unraid-api versionwill get you the latter.

Hey yall! We published an update to help fix the recent instability & downtime of Connect. --- 4.9.5 (2025-07-10) Bug Fixes * connect: rm eager restart on ERROR_RETYING connection status (#1502) (dd759d9)

Hey everyone! New plugin/API update -- you can find the full changelog on Github. tl;dr API Key & plugin management, performance fixes, and refactoring Connect into an API plugin.

@Arcau interesting. one possibility is that the settings aren't persisting. the config file is at `/boot/config/plugins/dynamix.my.servers/myservers.cfg` -- could you check whether the file changes when you update your settings (or log in/out of Connect)? i'm basically just trying to figure out/rule out whether your flash drive is dying.

> I'm unable to access the interface directly do you mean via remote access? could you provide more details about your setup?

ugh, that's gotta be frustrating. in the meantime, have you tried switching to a dynamic (i.e. upnp) setup? also, hopefully not a big deal, but the first part of your connect url is visible in the screenshot (in the url bar). crop that next time 😉

could you link the relevant issue for the folder thing? i hear ya on the notification spam when you uninstalled. the stock webgui flashes all unread notifications on every page load, but connect only flashes incoming notifications and keeps unreads in the sidebar. to prevent that spam, archive or delete notifications. hope that helps!

thanks for raising this issue. will investigate further.

@CcHookeye that sounds borderline traumatic. sorry you're dealing with that. just as a sanity check, do you have both 'Use UPnP' and 'Use SSL' set to yes on your unraid server?

did you try restarting nginx specifically (instead of rebooting the whole server or restarting the api)? also, have you customized the nginx config? i'm having trouble reproducing. commands for reloading/restarting nginx: # light-weight, pretty quick /etc/rc.d/rc.nginx reload # full restart /etc/rc.d/rc.nginx restart

gotta love node_modules dude. there were a couple other issues with node_modules/.bin in the past, but it's possible that the underlying issues there are now resolved and we can go back to using it as the pm2 entrypoint. using the script in .bin seems better bc (at least locally for me) it basically looks for local node overrides (via NODE_PATH or in basedir) before falling back to the global node. lmk if i'm missing something, but i've gathered 2 underlying issues here: issues with node sometimes not being on path (i.e. when PATH is either malformed or the environment is non-interactive, eg via sh) CI symlinks (from github actions) are leaking into final bundle Currently reviewing/testing fixes for these.

Please share! Would be awesome to see & learn from.

oh man. @rbroberts let me check with the team. We caught this issue during testing--sorry that it actually made it out, especially without an immediate fix/update. funnily enough @Gex2501, changing the path we used for pm2 was part of the fix. const PM2_PATH = join(import.meta.dirname, '../../', 'node_modules', 'pm2', 'bin', 'pm2');

great to hear. does it still seem like there's an issue on the api side? btw this use case is exactly the kind of stuff we're building the api for, so anything we can do to smooth out rough edges, make things simpler, etc, just let us know. I'm also curious: what was the most frustrating/painful part of this for you?

Huh. Will investigate--sorry this is happening.

Oh! This actually looks simple. Your var/log only has 57M available, but /var/log/unraid-api contains ~68M of logs, which is more than that, so it doesn't have enough space to copy it (as part of logrotate). Short term, you can delete the log files inside /var/log/unraid-api. The log output location was recently changed to /var/log/graphql-api.log recently for compatibility with the diagnostics tool. We also fixed an issue that generated a crap ton of logs. Long-term, if you have long-uptimes and this issue persists, you could look into increasing the amount of ram allocated to /var/log. I found another forum post talking about it, and there seem to be many results on google as well.

fixed in today's release