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

  1. Use the per-user password flow instead: the user's account settings page, or /system/recover-account + /system/reset-password for recovery
  2. Update/clear cached frontend bundles so the single-user password dialog no longer appears
  3. Treat the 401 as expected behavior - do not retry with different credentials
  4. 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

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

Related errors


AI-assisted analysis of Mintplex-Labs/anything-llm@20f6d3546c (2026-08-18). Data as JSON: /api/errors/e0b80fe026afc745. Report an issue: GitHub.