Skip to main content

Error 500003 when creating a MagicINFO user: the fix

Despite its "SQL Error" label, error 500003 when you create a user is usually MagicINFO's password policy. The server refuses passwords that contain a three-character run such as 123 or abc, or the same character three times in a row, and it writes the real reason only to its application log.

Symptoms​

  • Add User fails to save the new account, even though every field looks valid.
  • Through the REST API, POST /MagicInfo/restapi/v2.0/ums/users returns HTTP 500 with "errorCode":"500003" and an empty or generic message.
  • The database log shows nothing, because nothing ever reached the database.
  • The request fails almost instantly, in well under a second.

Cause​

MagicINFO checks the new password before it writes anything. When the check fails, the server raises a general error, and the REST layer reports any such error as 500003, the same code it uses for database failures. So the label points you at SQL while the cause is the password.

The rules that catch people out are not shown in the Add User dialog:

  • No sequential run of three characters, such as 123 or abc. To be safe, avoid descending runs such as 321 too.
  • No character repeated three or more times in a row, such as aaa or 111.

Random password generators break the second rule surprisingly often, so a script that creates users with generated passwords can fail on some runs and work on others.

There is a second, API-only cause. If the request body names the user group but leaves out its numeric groupId, the server fails internally and also answers 500003. The web interface always sends the id, which is why this never shows up in the browser.

Fix​

  1. Read the real reason. Open MagicINFO's application log, runtime\logs\wsrm.log in the installation folder (C:\MagicInfo Premium by default), and search for MESSAGE_USER_NOTICE_PASSWORD or saveUser at the time of the attempt. A MESSAGE_USER_NOTICE_PASSWORD… entry confirms a password-policy rejection. The service's console log usually shows nothing.
  2. Choose a compliant password. Avoid runs and triple repeats, and still meet the length and character-mix rules described in Password policy. A passphrase made of unrelated words with digits and a symbol usually passes.
  3. For generated passwords, reject any candidate that contains three identical characters in a row or three consecutive letters or digits, and generate again.
  4. For the REST API, send the full body: the user fields nested under userInfo, plus groupName, organizationName, roleName and the numeric groupId of the organisation's user group (for example its default group):
{
  "groupId": 123,
  "groupName": "default",
  "organizationName": "Example Org",
  "roleName": "Administrator",
  "userInfo": {
    "userId": "jane.doe",
    "userName": "Jane Doe",
    "email": "[email protected]",
    "password": "<compliant password>",
    "phoneNum": "",
    "team": ""
  }
}
  1. Plan for the first sign-in. On servers that require two-step verification, a new user's first sign-in asks for authenticator enrolment. Through the API this first sign-in returns 401011. That is expected and is not a permissions problem. See MagicINFO REST API: sign in with TOTP.

How to confirm it worked​

The new account appears in the user list (through the API: HTTP 201). The user can sign in and complete two-step verification. Searching wsrm.log for that time shows no new MESSAGE_USER_NOTICE_PASSWORD entry.

Checked against MagicINFO Server 21.1070 behaviour, October 2026.

Prefer not to run the server yourself? MiCloud hosts MagicINFO for you.

Last updated on