User accounts lost after update to v4.0

After update to v4.0, I cannot log in the web and then I checked the cryosparcm listusers it’s blank

(base) [ cryosparcuser]$ cryosparcm listusers
| Name                    | Email                             | Admin    |
(base) [ cryosparc_database]$ cryosparcm status
CryoSPARC System master node installed at
Current cryoSPARC version: v4.0.0

CryoSPARC process status:

app                              RUNNING   pid 263142, uptime 1:00:33
app_api                          RUNNING   pid 263174, uptime 1:00:31
app_api_dev                      STOPPED   Not started
app_legacy                       STOPPED   Not started
app_legacy_dev                   STOPPED   Not started
command_core                     RUNNING   pid 262893, uptime 1:00:59
command_rtp                      RUNNING   pid 262971, uptime 1:00:51
command_vis                      RUNNING   pid 262959, uptime 1:00:52
database                         RUNNING   pid 262753, uptime 1:01:02

License is valid

global config variables:
export CRYOSPARC_DB_PATH="/home/cryosparcuser/cryosparc/cryosparc_database"

Please can you post the output of this command:
cryosparcm cli "get_scheduler_targets()"

Hi we’ve also had this same issue:

This is the exact output from

cryosparcm cli "get_scheduler_targets()"


Not sure which system details might be relevant here but let us know if you need any more info. Thanks!

@zyx @BPP01
If still available, please can you post the terminal output of your
cryosparcm update session.
Please also post a listing of your database directory:

eval $(cryosparcm env)

end email us the output of
cryosparcm errorreport

Hi I didn’t know which email address to use but have sent you all those details in a personal message. Thanks,

Thank you for the information.
I cannot confirm (based on the modification times) that older information is still being stored in the database directory. Here are some additional question to help us understand what is going on:

Has the CryoSPARC instance been strictly only updated, not installed, since it was last used successfully?

Is there any chance that the original database has been deleted through a filesystem command or the CryoSPARC instance been pointed to a different directory?

Has there ever been an attempt to restore the database from a backup? (Please do not attempt a backup at this point.)

Please can you paste the output of this query:

  1. enter a mongo shell:
    cryosparcm mongo
  2. the query:

CryoSPARC has only been updated not installed since last successful use.

The original database wasn’t deleted through a filesystem command as we always use the same exact set of commands to update the software.

There have been no attempts to restore the database from a backup yet.

Response from query in mongo shell:

meteor:PRIMARY> db.sched_config.find()
{ "_id" : ObjectId("633ebad45d3f9643a264ded4"), "name" : "lanes", "value" : [ ] }
{ "_id" : ObjectId("633ebad45d3f9643a264ded7"), "name" : "targets", "value" : [ ] }
{ "_id" : ObjectId("633ebad45d3f9643a264deda"), "name" : "interleave_projects", "value" : true }


Hi guys do you have any updates on this? We’re fairly stuck otherwise.

Should we be trying to create new accounts and then import the projects or something along those lines? What’s the best way forwards for us at the moment?


If you have a recent database back up, you may restore it (guide).
The alternative is similar to what you had in mind

The process of importing projects has been superseded by a new method: as of v4, one attaches unlocked project directories to the CryoSPARC instance.
Users would have to created manually, as would worker connections.

Ok thanks so much - just re-attaching the projects with a new user seems to be working ok so far. Will let you know if we find any issues down the line with this approach.

If we want to backup the database before updates in future does the cryosparc server, ideally, need to be shutdown first or is it safe to back it up while data is potentially still been written to it?


Did you consider regular backups to mitigate the impact of potential server malfunction?

That depends on the backup method. As of October 2022,
cryosparcm backup uses mongodump, which, to some extent, tolerates writes by applications, but there are caveats.
Alternatively, one must ensure there are no writes while the database is backed up using cp or rsync.