We have a CryoSPARC project that is currently browsable but cannot be modified. Creating/deleting jobs or clearing a Live session produces “Project import failed.” Current version is v5.0.7.
Historical context: the server suffered an OS-drive failure in December 2023. The CryoSPARC installation/database were on that disk and the original DB was lost. The separate project storage survived. CryoSPARC was freshly installed on Dec. 24, 2023, and the surviving filesystem project P14 was attached into the rebuilt instance as P3 on Jan. 9, 2024.
The current P3 project document shows:
imported_at: 2024-01-09T18:19:50Z
import_status: failed
Despite that failed status, the user reports the project worked normally afterward and continued to be used for more than two years, including Live sessions in March 2026. The system was upgraded to CryoSPARC v5 on April 20, 2026. The inability to modify this project was only noticed recently.
We have investigated the on-disk project without modifying it:
457 J* directories exist.
456 contain a syntactically valid job.json whose UID matches the directory.
The current job_manifest.json contains only 318 job UIDs.
Every job in the manifest has a directory, but there are 139 additional valid job directories absent from the manifest.
The only directory without job.json is J246. J246 is listed in job_manifest.json, but its directory contains only an empty events.bson and an empty gridfs_data/. api.jobs.find_one("P3","J246") returns 404 / “Could not find job P3 J246.” Our retained storage backup contains the same skeletal J246 and no recoverable job.json.
The current root metadata timestamps are also notable:
cs.lock — Jan. 9, 2024
project.json — Dec. 4, 2025
workspaces.json — Mar. 24, 2026
job_manifest.json — Mar. 24, 2026
So the project metadata continued to be updated long after the original failed attachment.
We have not detached the project, edited job_manifest.json/workspaces.json/project.json, removed J246, or modified the database.
We have already collected:
cryosparcm snaplogs
a compressed ls -al listing of the project directory
copies of project.json, job_manifest.json, and workspaces.json
Our main question is the safest recovery path while preserving the work created after the 2024 failed attachment. Would you recommend making an unattached copy/snapshot of P14 and constructing a synthetic manifest from the 456 valid J*/job.json files, thereby excluding J246? Is there any special handling required to preserve the workspaces and Live sessions created after the failed attachment?
We can provide the logs and metadata files privately if useful.