Workbench: Change status from Inactive to Active?

Dear Posit Community!
We have a free Academic license for Workbench at my college, and we need your help!

Users who do not login for a long period of time have their status changed to "Inactive" and can no longer login. I need to know how to change this. Note, this is not the same as "Locked" status which I do know how to control.

I have a student who dropped the class 2 years ago and is now retaking the course; however, she cannot login due to Inactive status. Similarly, I have some faculty members who have not logged into Workbench for a couple of years and are also in Inactive status with no ability to login.

I find nothing about this in the Workbench documentation. However, someone previously asked this question here, but no public solution was given (

Thank you in advance! :slight_smile:
~Eric Carreira
Holyoke Community College


I'm also interested in this topic as I'm having the same issue and can find no way to resolve it.


Hello @jbagnoli ,
I reached out to Posit support and received the response below. Hope it helps you.

If you are running a version of Workbench older then 2022.12.0 you may want to consider upgrading as there are some fixes related to this issue in the newer releases. There are two possible solutions to resolve this issue both require manipulating the database. I would make sure to back up the database first. The first is to delete the inactive user and have them log back in to get reactivated. The second is to update the last sign in time for the user. Below are the steps for both solutions.

Here is the solution for sqlite databases:

Please back up the current database for security:

* *$ sudo rstudio-server stop * *

* *$ sudo cp /var/lib/rstudio-server/rstudio.sqlite /var/lib/rstudio-server/rstudio.sqlite.backup.20230830* *

The first solution is to delete that user from the database and let them log in to get reactivated.
Please run these commands

* *$ sudo sqlite3 /var/lib/rstudio-server/rstudio.sqlite* *

* *sqlite> delete from licensed_users where user_name = "username";* *

The other solution is to update the last_sign_in column to a string like: 2023-08-30T05:11:07.788892Z so they show up as active and don't need to be reactivated. In sqlite the command would look like this:

* *$ sudo sqlite3 /var/lib/rstudio-server/rstudio.sqlite* *

* *sqlite> update licensed_users set last_sign_in = '2023-08-30T05:11:07.788892Z' where user_name = 'username';* *


If your database is PostgreSQL please follow these instructions instead;
If possible, we recommend performing a backup before proceeding.

The equivalent fix for PostgreSQL would be to run one of the following on the rstudio database after stopping RStudio on each node to be safe.

To delete the user:

* *delete from licensed_users where "user_name" like 'username';* *

or to update the last sign-in timestamp:

* *update licensed_users set last_sign_in = '2023-08-30T17:11:31.658350Z' where "user_name" like 'username';* *

Though we might want to hold off on this after seeing the output of the following.

Prior to making any Postgres DB changes, it would be good to see the output of the list of users of a select query in the database.

On each of the workbench servers, substituting username for the user with the issue:

* */usr/lib/rstudio-server/bin/rstudio-server list-users | grep username* *

On the PostgreSQL server, when connected to the rstudio database, and substituting username for the user with the issue:

* *select * from licensed_users where "user_name" like 'username';* *

If after trying the steps above the issue persists please provide a diagnostic.
sudo rstudio-server run-diagnostics

I also wrote to them about the same issue as you, in my case they recommended updating the Workbench version as soon as possible as I had far too old one. In the first case, I got rid of the inactive user and re-added it, but it seems to me that a much better move, remains to update when someone last logged in.

1 Like

Thanks Eric. Support is talking to me but I will try these. I had upgraded the server as a potential solution, but it didn't fix the problem for our group.

1 Like

We changed the last login field and it was successful! :slight_smile:

1 Like

Turns out our problem was slightly different. The SQL database was corrupt and had to be rebuilt.