jitsi/jitsi-meet · warning · JitsiConferenceErrors

PASSWORD_NOT_SUPPORTED

PASSWORD_NOT_SUPPORTED

Error message

room passwords not supported

What it means

The room-lock middleware maps a lib-jitsi-meet conference error, JitsiConferenceErrors.PASSWORD_NOT_SUPPORTED, to a user-facing 'password not supported' dialog. It means the backend (Jitsi Meet deployment / prosody room configuration) does not allow password-protecting the room, so the client's setPassword call failed with this specific error code. It is expected behavior on deployments where room locking is disabled server-side.

Source

Thrown at react/features/room-lock/middleware.ts:134

 * @param {Store} store - The redux store in which the specified action is being
 * dispatched.
 * @param {Dispatch} next - The redux {@code dispatch} function to dispatch the
 * specified action to the specified store.
 * @param {Action} action - The redux action {@code SET_PASSWORD_ERROR} which
 * has the error type that should be handled.
 * @private
 * @returns {*}
 */
function _setPasswordFailed(store: IStore, next: Function, action: AnyAction) {
    if (typeof APP !== 'undefined') {
        // TODO Remove this logic when displaying of error messages on web is
        // handled through react/redux.
        const { error } = action;
        let descriptionKey;
        let titleKey;

        if (error === JitsiConferenceErrors.PASSWORD_NOT_SUPPORTED) {
            logger.warn('room passwords not supported');
            descriptionKey = 'dialog.passwordNotSupported';
            titleKey = 'dialog.passwordNotSupportedTitle';
        } else {
            logger.warn('setting password failed', error);
            descriptionKey = 'dialog.lockMessage';
            titleKey = 'dialog.lockTitle';
        }
        APP.store.dispatch(showErrorNotification({
            descriptionKey,
            titleKey
        }));
    }

    return next(action);
}

View on GitHub (pinned to 98de6219cc)

Solutions

1. Enable room locking server-side: set muc_room_locking = true (and allow muc_room_default_lock) in the prosody MUC component config and restart prosody.
2. If on a managed deployment (e.g., JaaS), check the feature flags / deployment settings for room locking support.
3. If passwords are intentionally unsupported, disable the lock UI client-side (hide the security dialog password section) so users cannot trigger the error.

Example fix

-- prosody config before
muc_room_locking = false

-- prosody config after
muc_room_locking = true

if (isModerator(state) && conference && serverSupportsRoomLock()) {
    dispatch(setPassword(conference, undefined, password));
}

null

null

When it happens

Trigger: Dispatching setPassword / clicking 'Add password' in the security dialog while connected to a deployment whose prosody muc config has room locking disabled (muc_room_locking = false), or a JaaS/managed deployment where passwords are not enabled. Also triggered when a moderator attempts to lock a breakout or specialized room type that rejects passwords.

Common situations: Self-hosted prosody with 'muc_room_locking = false; muc_room_default_lock = false' in the VirtualHost config, JaaS deployments without the password feature flag, or version mismatches where the server config no longer permits locking.

Related errors

• setting password failed

AI-assisted analysis of jitsi/jitsi-meet@98de6219cc (2026-08-28). Data as JSON: /api/errors/7924f91cee42874b. Report an issue: GitHub.