Mintplex-Labs/anything-llm · warning
Unauthorized
Error message
Unauthorized
What it means
This 401 'Unauthorized' from POST /system/update-password (server/endpoints/system.js:615) is an intentional guard, not an exception or an auth failure of your request. The endpoint manages the single shared instance password (AUTH_TOKEN); when multiUserMode(response) is true the instance has per-user accounts, so changing a global password is meaningless and rejected with 401 before any work happens. Password changes in multi-user mode belong to each user's account settings (or admin-driven reset/recovery flows).
Source
Thrown at server/endpoints/system.js:617
false,
response?.locals?.user?.id
);
response.status(200).json({ newValues, error });
} catch (e) {
console.error(e.message, e);
response.sendStatus(500).end();
}
}
);
app.post(
"/system/update-password",
[validatedRequest],
async (request, response) => {
try {
// Cannot update password in multi - user mode.
if (multiUserMode(response)) {
response.sendStatus(401).end();
return;
}
let error = null;
const { usePassword, newPassword } = reqBody(request);
if (!usePassword) {
// Password is being disabled so directly unset everything to bypass validation.
process.env.AUTH_TOKEN = "";
process.env.JWT_SECRET = "";
} else {
// An all-asterisk value is indistinguishable from the UI's masked
// placeholder, so updateENV would silently drop it while JWT_SECRET
// still rotates - reject it before mutating anything.
if (/^\*+$/.test(String(newPassword))) {
response.status(200).json({
success: false,
error: "Password cannot consist of only asterisks (*).",
});View on GitHub (pinned to 20f6d3546c)
Solutions
- Use the per-user password flow instead: the user's account settings page, or /system/recover-account + /system/reset-password for recovery
- Update/clear cached frontend bundles so the single-user password dialog no longer appears
- Treat the 401 as expected behavior - do not retry with different credentials
- Only invoke /system/update-password on instances where multi-user mode was never enabled
Defensive patterns
Strategy: validation
Validate before calling
const { multiUserMode } = await (
await fetch("/api/system/multi-user-mode")
).json();
if (multiUserMode) {
// do not call /system/update-password - route the user to account settings
navigate("/settings/account");
} else {
await updateInstancePassword(newPassword);
} Prevention
- Gate the single-user password UI on GET /system/multi-user-mode before showing it
- Cache-bust frontend bundles after enabling multi-user mode so stale dialogs disappear
- In multi-user mode use account settings or /system/recover-account + /system/reset-password
- Treat 401 here as a mode mismatch, never as bad credentials
When it happens
Trigger: Calling POST /api/system/update-password on any instance where multi-user mode was enabled via /system/enable-multi-user; frontend code from an older deployment still invoking the single-user password dialog after migration to multi-user.
Common situations: Migrating a single-user instance to multi-user while old UI tabs or scripts remain cached; automation written against the single-user API replayed after enabling multi-user.
Understand the failure class
- Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.
Related errors
- Forbidden
- User is suspended.
- Public token is required to validate a temporary auth token.
- Invalid token.
- Token expired.
AI-assisted analysis of Mintplex-Labs/anything-llm@20f6d3546c (2026-08-18).
Data as JSON: /api/errors/e0b80fe026afc745.
Report an issue: GitHub.