Troubleshooting¶
Checks for the LibreChat outcomes the published getting-started page names.
Image notes are /opt/sushi/docs/README.md and /opt/sushi/docs/DEMO.md.
The service is not ready immediately after boot¶
Cause: first boot creates the encryption and session identity, then the application waits for your database configuration. An unconfigured status is expected at that point.
Fix: finish Create the owner.
Run sudo sushi-librechat configure before create-owner, and wait until
librechat.service has connected.
The database connection fails¶
Cause: the endpoint is unreachable, the database user lacks the permissions the application needs, the TLS certificate chain does not verify, or the network path is blocked. Certificate verification stays on.
Fix: correct the endpoint, the credentials, the certificate chain, and
the outbound path. Then run sudo sushi-librechat configure again. For a
custom CA, use a mode 0600 JSON file with mongodb_uri and
mongodb_ca_file, and pass only the filename to
configure --connection-file. Keep the URI out of the command line. Preserve
the data while you fix this.
create-owner does not change the existing account¶
Cause: an administrator is already stored. create-owner does not
replace that account.
Fix: sign in with the existing owner. Do not delete the database or
/etc/librechat to obtain a second first owner.
demo.sh exits 3¶
Cause: bash /opt/sushi/docs/demo.sh prepares a challenge and then waits
for you to send it from the browser. Exit 3 means the check is incomplete.
It is not a successful demo, and it is not a crash by itself.
Fix: sign in at http://localhost:3080, select Bedrock / Amazon Nova
Lite, start a new conversation that is not temporary, send the printed
challenge once, wait for the completed response, and then run:
Success prints SUSHI_CUSTOMER_DEMO_PASSED. If the wait times out, the
challenge is still stored. Inspect the UI and run the verify command again
before you send another challenge.
The acceptance file already exists¶
Cause: the published Python command opens
~/.config/librechat/acceptance.json so that it will not replace an existing
file.
Fix: keep the file if it is correct. The getting-started page says to retain an existing correct file. Do not delete it to print the password again.
The prior-result check refuses to run¶
Cause: /opt/sushi/bin/librechat-acceptance --verify-prior-only needs an
earlier successful receipt and no challenge still waiting. It checks saved
message hashes. It does not convert an unfinished check into a success.
Fix: finish the browser challenge and the verify command first. After a
restart, run the prior-result command only when that receipt exists. The
listing usage text also names
sudo -iu ubuntu bash /opt/sushi/docs/demo.sh --verify-prior-only. These
pages do not treat that form as a proven alias of librechat-acceptance.
Saved provider credentials cannot be read after a restore¶
Cause: the restore omitted the original encryption keys in
/etc/librechat, or the identity was replaced. The published guide says
losing those keys can make stored provider credentials unreadable.
Fix: restore /etc/librechat (including the original identity.env),
/var/lib/librechat, and an application-consistent copy of the external
database together. Keep the existing identity. See
Backups.
Last updated November 1, 2026 · Suggest an improvement