Skip to content

Managing users

Every command should be ran as the akkoma user from it's home directory. For example if you are superuser, you would have to wrap the command in su akkoma -s $SHELL -lc "$COMMAND".

From source note about MIX_ENV

The mix command should be prefixed with the name of environment your Akkoma server is running in, usually it's MIX_ENV=prod

Create a user

./bin/pleroma_ctl user new <nickname> <email> [option ...]

mix pleroma.user new <nickname> <email> [option ...]

Options

  • --name <name> - the user's display name
  • --bio <bio> - the user's bio
  • --password <password> - the user's password
  • --moderator/--no-moderator - whether the user should be a moderator
  • --admin/--no-admin - whether the user should be an admin
  • -y, --assume-yes/--no-assume-yes - whether to assume yes to all questions

List local users

 ./bin/pleroma_ctl user list

mix pleroma.user list

 ./bin/pleroma_ctl user invite [option ...]

mix pleroma.user invite [option ...]

Options

  • --expires-at DATE - last day on which token is active (e.g. "2019-04-05")
  • --max-use NUMBER - maximum numbers of token uses

List generated invites

 ./bin/pleroma_ctl user invites

mix pleroma.user invites

Revoke invite

 ./bin/pleroma_ctl user revoke_invite <token>

mix pleroma.user revoke_invite <token>

Delete a user

 ./bin/pleroma_ctl user rm <nickname>

mix pleroma.user rm <nickname>

Delete user's posts and interactions

 ./bin/pleroma_ctl user delete_activities <nickname>

mix pleroma.user delete_activities <nickname>

Sign user out from all applications (delete user's OAuth tokens and authorizations)

 ./bin/pleroma_ctl user sign_out <nickname>

mix pleroma.user sign_out <nickname>

Activate a user

 ./bin/pleroma_ctl user activate NICKNAME

mix pleroma.user activate NICKNAME

Deactivate a user and unsubscribes local users from the user

 ./bin/pleroma_ctl user deactivate NICKNAME

mix pleroma.user deactivate NICKNAME

Deactivate all accounts from an instance and unsubscribe local users on it

 ./bin/pleroma_ctl user deactivate_all_from_instance <instance>

mix pleroma.user deactivate_all_from_instance <instance>

 ./bin/pleroma_ctl user reset_password <nickname>

mix pleroma.user reset_password <nickname>

Disable Multi Factor Authentication (MFA/2FA) for a user

 ./bin/pleroma_ctl user reset_mfa <nickname>

mix pleroma.user reset_mfa <nickname>

Set the value of the given user's settings

 ./bin/pleroma_ctl user set <nickname> [option ...]

mix pleroma.user set <nickname> [option ...]

Options

  • --admin/--no-admin - whether the user should be an admin
  • --confirmed/--no-confirmed - whether the user account is confirmed
  • --locked/--no-locked - whether the user should be locked
  • --moderator/--no-moderator - whether the user should be a moderator

Add tags to a user

 ./bin/pleroma_ctl user tag <nickname> <tags>

mix pleroma.user tag <nickname> <tags>

Delete tags from a user

 ./bin/pleroma_ctl user untag <nickname> <tags>

mix pleroma.user untag <nickname> <tags>

Toggle confirmation status of the user

 ./bin/pleroma_ctl user confirm <nickname>

mix pleroma.user confirm <nickname>

Set confirmation status for all regular active users

Admins and moderators are excluded

 ./bin/pleroma_ctl user confirm_all

mix pleroma.user confirm_all

Revoke confirmation status for all regular active users

Admins and moderators are excluded

 ./bin/pleroma_ctl user unconfirm_all

mix pleroma.user unconfirm_all

Fix following state

Sometimes the system can get into a situation where it think you're already following someone and won't send a request to the remote instance, or won't let you unfollow someone. This bug was fixed, but in case you encounter these weird states:

 ./bin/pleroma_ctl user fix_follow_state localuser remoteuser@example.com

mix pleroma.user fix_follow_state localuser remoteuser@example.com

The first argument is the local user's nickname - if you are myuser@myinstance, this should be myuser.

The second is the remote user, consisting of both nickname AND domain.

If you are a weird follow state situation and cannot resolve it with the above, you may need to co-operate with the remote admin to clear the state their side too - they should provide the arguments backwards, i.e fix_follow_state remote local.