Jellystat wont start. It loops through the following and the jellystat page wont load. on board AI just keeps throwing the same response over and over. Jellystat Database (internal database) -Unhealthy- Up (unhealthy) Jellystat - Crashing AI: "I'm not proposing repair-db-auth jellystat yet — nothing I've read from this box in this conversation shows jellystat's database login out of sync (rundoctor: db-auth-desync-jellystat). Read first: rundoctor (its failed checks name the repair each one needs) or getsnapshot / gethealth (which apps are stopped or unhealthy). If no read shows it, this repair is not the answer — say what you actually found instead."
12 replies
Chris wrote:
Sorry—you’re getting the same AI checklist instead of help. One possible cause is that Jellystat’s generated database password didn’t reach the app when it was started, but the unhealthy status alone doesn’t confirm that, so please don’t run a database repair or reset anything yet. Could you reply with the SparkBox version shown on your dashboard and whether this began just after enabling Jellystat or after an update? That will let us choose a safe next check; leave the Jellystat data in place.
EineBeBoP wrote:
Current version: 1.6.826 Ugreen NAS unit. Just began after enabling, but I ported the install from another drive and its failed since. I don't mind starting fresh and wiping the data from jellystat
Chris wrote:
Sorry—the on-board AI repeated a generic checklist instead of addressing the move, and I should have asked about that first. On a migrated install, a database-backed app's generated database credential may not have reached its database when the app was enabled; the unhealthy label alone does not confirm that this is the cause. Please don't wipe Jellystat yet. One check: was Jellystat's database already in use on the old drive, or did Jellystat first fail on this drive? That tells us whether replacing its data could lose anything. I've corrected what I know about this migration scenario so the same generic response isn't repeated for the next person.
EineBeBoP wrote:
I had used jellystat previously, yes. It worked fine before the migration.
Chris wrote:
Thanks—that confirms Jellystat was working before the move, so its existing database may contain data worth keeping. The unhealthy status alone doesn't tell us whether the old database came across or whether its login is now mismatched. Before changing anything, can you confirm whether you copied Jellystat's data/database along with the SparkBox install? Please don't wipe it yet.
EineBeBoP wrote:
I have no interest in the previous data. I used a sparkbox backup to migrate so I assume it moved the data, but I dont know for sure
Chris wrote:
Understood—you don't need to recover the previous Jellystat data, and we don't need to establish whether the backup included it. The unhealthy database status still doesn't tell us why it won't start, so please don't delete or reset it yet. Could you share just the first error line from Jellystat's internal database log, with any passwords, tokens, or addresses removed? Stop there; that will tell us what safe next step fits.
EineBeBoP wrote:
2026-10-02T04:36:48.500461625Z 2026-10-02 04:36:48.500 UTC [1353] DETAIL: Connection matched file "/var/lib/postgresql/data/pghba.conf" line 128: "host all all all scram-sha-256" 2026-10-02T04:37:03.602630270Z 2026-10-02 04:37:03.601 UTC [1365] FATAL: password authentication failed for user "jellystat"
Chris wrote:
Thanks, that log confirms Jellystat's database is rejecting its saved login, so the app and database credentials are out of sync after the migration. On your UGREEN box, run sudo sparkbox repair-db-auth jellystat once and follow the confirmation prompt; it takes a safety copy and resynchronizes the login without replacing the database. If it reports it cannot make the safety copy, stop there and share just that message with any secrets removed.
EineBeBoP wrote:
Thats fixed it, thanks!
Chris wrote:
Glad that fixed it—thanks for confirming!
Chris wrote:
One more note on why the on-board AI kept repeating itself: the text you saw was its own internal instructions leaking into the reply, and it would only offer the database repair after one specific check, even though your database log already showed the cause. SparkBox 1.6.836, out now, fixes both. The assistant now explains in plain words when it holds back a repair, and pasting a database's "password authentication failed" line into the chat is enough for it to offer the database login repair itself (it still saves a copy of the database first and asks you to confirm). Nothing to do on your box: Jellystat is already fixed. Thanks for the clear report, it's what let us find this.