Cannot export particles from a finished job

Import and Export
1

I combined 3 particle stacks for a final 3D construction and now I want to export these particles to continue the analysis on a new disc as I ran out of space. I managed to perform the “restack” job, but when I open the output and try to “export” the particles, I get a quick appearing message of something like particles Job exported, and then the blue bar showing the progress of the export process does not move at all, and the message “Exporting particles from P8 J111” stays on the screen forever without any progress. I tried exporting other particles in that project, did not work, exporting a volume did not work, restarting cryosparc, did not work. As I mentioned that the disc is almost full, so I deleted some jobs that are not related to the particles I want to extract and now have a 3% capacity out of 14 terabytes. So I do not think it is a problem of disc space, since I can run jobs.

The last thing I was going to try was to shutdown cryosparc and the processor itself. But I am very puzzled as to why this is happening. I am not getting any error messages, so is there anyway to know what is preventing the export job from running???

2

@Noha_Elshamy What version of CryoSPARC do you use?

What was the exact job type?

Did you delete those jobs through CryoSPARC GUI’s Delete Job action?
Were those jobs deleted from the same project as the 3D construction you mentioned?
Do you remember the job types of the deleted jobs?

3

I am now using CryoSPARC 4.7.1

Exact Job type I tried to export a “mask” from a Homogenous refinement Job (Same project)- Particles from a Homogenous refinement Job (Different Project)

I deleted those jobs from the GUI of CryoSPARC “delete job”. The jobs I deleted were mostly from the same project but different workspace (Non -Uniform refinement and Reference-based motion correction)- and failed/ low resolution reconstruction (Non Uniform and Homogenous refinement) from same project and same workspace.

4

So restarting the machine itself did not make a difference and the particles still cannot export. Is there any way with which I can know if it is a problem of disc space??? Also, is there any way around exporting the particle data through the cryoSPARC GUI???

5

Please can you run the commands (suitable for CryoSPARC v4.7.1, not for v5)

project_uid=P8 # according to your first post
cryosparcm log command_core | grep -A 1 "Exporting .*$project_uid"
df -hT $(cryosparcm cli "get_project_dir_abs('$project_uid')")

and post their outputs.
(These commands check for relevant log entries and available disk space.)

6

Here are the outputs:

\[cryosparc@Yoshitsune /\]$ cryosparcm log command_core | grep -A 10 -E "Exporting .\*P8.\*J592|export_job.\*P8.\*J592"

2026-09-18 15:35:02,931 export_output_result_group INFO     | **Exporting particles from P8 J592** (result names \['blob', 'alignments3D', 'ctf', 'location', 'alignments2D', 'pick_stats', 'location'\])

2026-09-18 15:35:02,935 run                  ERROR    | POST-RESPONSE-THREAD ERROR at export_output_result_group_run

2026-09-18 15:35:02,935 run                  ERROR    | Traceback (most recent call last):

2026-09-18 15:35:02,935 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_command/commandcommon.py", line 73, in run

2026-09-18 15:35:02,935 run                  ERROR    |     self.target(\*self.args)

2026-09-18 15:35:02,935 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_command/command_core/\__init_\_.py", line 7035, in export_output_result_group_run

2026-09-18 15:35:02,935 run                  ERROR    |     rc.export_output_result_group(project_uid, job_uid, output_result_group_name, result_names, logger=lambda msg: job_send_streamlog(project_uid, job_uid, msg), notification_id = notification_id)

2026-09-18 15:35:02,935 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_compute/jobs/runcommon.py", line 1490, in export_output_result_group

2026-09-18 15:35:02,935 run                  ERROR    |     mkdir_p(os.path.expandvars(abs_export_dir))

2026-09-18 15:35:02,935 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_compute/jobs/runcommon.py", line 719, in mkdir_p

2026-09-18 15:35:02,935 run                  ERROR    |     os.makedirs(path, exist_ok=True)

\--

2026-09-18 15:59:18,963 export_output_result_group INFO     | **Exporting particles from P8 J592** (result names \['blob', 'alignments3D', 'ctf', 'location', 'alignments2D', 'pick_stats', 'location'\])

2026-09-18 15:59:18,968 run                  ERROR    | POST-RESPONSE-THREAD ERROR at export_output_result_group_run

2026-09-18 15:59:18,968 run                  ERROR    | Traceback (most recent call last):

2026-09-18 15:59:18,968 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_command/commandcommon.py", line 73, in run

2026-09-18 15:59:18,968 run                  ERROR    |     self.target(\*self.args)

2026-09-18 15:59:18,968 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_command/command_core/\__init_\_.py", line 7035, in export_output_result_group_run

2026-09-18 15:59:18,968 run                  ERROR    |     rc.export_output_result_group(project_uid, job_uid, output_result_group_name, result_names, logger=lambda msg: job_send_streamlog(project_uid, job_uid, msg), notification_id = notification_id)

2026-09-18 15:59:18,968 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_compute/jobs/runcommon.py", line 1490, in export_output_result_group

2026-09-18 15:59:18,968 run                  ERROR    |     mkdir_p(os.path.expandvars(abs_export_dir))

2026-09-18 15:59:18,968 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_compute/jobs/runcommon.py", line 719, in mkdir_p

2026-09-18 15:59:18,968 run                  ERROR    |     os.makedirs(path, exist_ok=True)

\--

2026-09-24 18:01:20,369 export_output_result_group INFO     | **Exporting particles from P8 J592** (result names \['blob', 'alignments3D', 'ctf', 'location', 'alignments2D', 'pick_stats', 'location'\])

2026-09-24 18:01:20,398 run                  ERROR    | POST-RESPONSE-THREAD ERROR at export_output_result_group_run

2026-09-24 18:01:20,398 run                  ERROR    | Traceback (most recent call last):

2026-09-24 18:01:20,398 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_command/commandcommon.py", line 73, in run

2026-09-24 18:01:20,398 run                  ERROR    |     self.target(\*self.args)

2026-09-24 18:01:20,398 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_command/command_core/\__init_\_.py", line 7035, in export_output_result_group_run

2026-09-24 18:01:20,398 run                  ERROR    |     rc.export_output_result_group(project_uid, job_uid, output_result_group_name, result_names, logger=lambda msg: job_send_streamlog(project_uid, job_uid, msg), notification_id = notification_id)

2026-09-24 18:01:20,398 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_compute/jobs/runcommon.py", line 1490, in export_output_result_group

2026-09-24 18:01:20,398 run                  ERROR    |     mkdir_p(os.path.expandvars(abs_export_dir))

2026-09-24 18:01:20,398 run                  ERROR    |   File "/home/cryosparc/cryosparc_master/cryosparc_compute/jobs/runcommon.py", line 719, in mkdir_p

2026-09-24 18:01:20,398 run                  ERROR    |     os.makedirs(path, exist_ok=True)

\[cryosparc@Yoshitsune /\]$ df -hT "$(cryosparcm cli "get_project_dir_abs('P8')" | tr -d "'\\"")"

Filesystem     Type  Size  Used Avail Use% Mounted on

/dev/sdd1      xfs    13T   13T  412G  97% /mnt/3extra_hdd

\[cryosparc@Yoshitsune /\]$ df -iT "$(cryosparcm cli "get_project_dir_abs('P8')" | tr -d "'\\"")"

Filesystem     Type    Inodes  IUsed     IFree IUse% Mounted on

/dev/sdd1      xfs  862410160 378850 862031310    1% /mnt/3extra_hdd
7

Interesting. Please can you also post the output of the commands

namei -l $(cryosparcm cli "get_project_dir_abs('$P8')")/exports/groups/*
cryosparcm log command_core | grep -A 5 "2026-09-24 18:01:20,398"
8

Here you are;

[cryosparc@Yoshitsune /]$ cryosparcm log command_core | grep -A 5 “export_output_result_group” | tail -n 6
File “/home/cryosparc/cryosparc_master/cryosparc_compute/jobs/runcommon.py”, line 1490, in export_output_result_group
mkdir_p(os.path.expandvars(abs_export_dir))
File “/home/cryosparc/cryosparc_master/cryosparc_compute/jobs/runcommon.py”, line 719, in mkdir_p
os.makedirs(path, exist_ok=True)
File “/home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/lib/python3.10/os.py”, line 225, in makedirs
mkdir(name, mode)
[cryosparc@Yoshitsune /]$ namei -l /mnt/3extra_hdd/cryoSPARC/CS–f2-1/exports
f: /mnt/3extra_hdd/cryoSPARC/CS–f2-1/exports
dr-xr-xr-x root root /
drwxr-xr-x root root mnt
drwxrwxrwx root root 3extra_hdd
drwxrwxrwx 1012 1012 cryoSPARC
drwxrwxrwx cryosparc cryosparc CS–f2-1
drwxrwxr-x 1011 1011 exports
[cryosparc@Yoshitsune /]$ namei -l /mnt/3extra_hdd/cryoSPARC/CS–f2-1/exports/groups
f: /mnt/3extra_hdd/cryoSPARC/CS–f2-1/exports/groups
dr-xr-xr-x root root /
drwxr-xr-x root root mnt
drwxrwxrwx root root 3extra_hdd
drwxrwxrwx 1012 1012 cryoSPARC
drwxrwxrwx cryosparc cryosparc CS–f2-1
drwxrwxr-x 1011 1011 exports
drwxrwxr-x 1011 1011 groups

9

Thanks @Noha_Elshamy. The directory information indicates inconsistent file ownerships that interfere with result export. It is typically expected that

  1. CryoSPARC services and cryosparcm commands are all run under a “designated”, non-privileged Linux account.
  2. A Linux account with the same numeric ID and username as the account above exists on the CryoSPARC master computer and all CryoSPARC worker computers.
  3. CryoSPARC project directories and their subdirectories and files are owned by that Linux account.
  4. File ownerships of a detached project directory may have to be adjusted before attaching if the project directory was detached from a CryoSPARC instance with a different “designated” Linux account.

The inconsistent ownerships may have arisen in various ways. For example, cryosparcm commands may have been run “by force”

  • on a different computer that has access to the same shared storage as the “real” CryoSPARC master computer.
  • or under Linux account other than the “designated” Linux account.

The insecure and permissive permissions on the project directory suggest an attempt to address previous problems caused by inconsistent file ownerships.

Restoration of CryoSPARC function depends on the current state that can be characterized with these commands (CryoSPARC v4, not v5):

cryosparcm env | grep -v CRYOSPARC_LICENSE_ID
namei -l /home/cryosparc/cryosparc_master/bin/cryosparcm
ps -eo user:16,pid,ppid,start,cmd | grep -e cryosparc_ -e mongo
cryosparcm cli "get_scheduler_targets()"
10

Here is the output:

[cryosparc@Yoshitsune /]$ cryosparcm env | grep -v CRYOSPARC_LICENSE_ID
export “CRYOSPARC_MASTER_HOSTNAME=Yoshitsune”
export “CRYOSPARC_PATH=/home/cryosparc/cryosparc_master/deps/external/mongodb/bin:/home/cryosparc/cryosparc_master/bin”
export “CRYOSPARC_MONGO_EXTRA_FLAGS=”
export “CRYOSPARC_INSECURE=false”
export “CRYOSPARC_DB_ENABLE_AUTH_FLAG=–auth”
export “CRYOSPARC_DB_CONNECTION_TIMEOUT_MS=20000”
export “CRYOSPARC_MONGO_CACHE_GB=4”
export “CRYOSPARC_COMMAND_VIS_PORT=39003”
export “CRYOSPARC_MONGO_FCV=3.6”
export “CRYOSPARC_COMMAND_RTP_PORT=39005”
export “CRYOSPARC_HTTP_APP_PORT=39000”
export “CRYOSPARC_ROOT_DIR=/home/cryosparc/cryosparc_master”
export “CRYOSPARC_FORCE_USER=false”
export “CRYOSPARC_HOSTNAME_CHECK=Yoshitsune”
export “CRYOSPARC_MONGO_PORT=39001”
export “CRYOSPARC_DB_PATH=/home/cryosparc/database”
export “CRYOSPARC_CLICK_WRAP=true”
export “CRYOSPARC_HTTP_LIVEAPP_LEGACY_PORT=39006”
export “CRYOSPARC_LIVE_ENABLED=true”
export “CRYOSPARC_COMMAND_CORE_PORT=39002”
export “CRYOSPARC_SUPERVISOR_SOCK_FILE=/tmp/cryosparc-supervisor-7a7de3655815c405eac5569b8fa9fe55.sock”
export “CRYOSPARC_BASE_PORT=39000”
export “CRYOSPARC_DEVELOP=false”
export “CRYOSPARC_CLUSTER_JOB_MONITOR_INTERVAL=10”
export “CRYOSPARC_DB_ENABLE_AUTH=true”
export “CRYOSPARC_HEARTBEAT_SECONDS=180”
export “CRYOSPARC_CONDA_ENV=cryosparc_master_env”
export “CRYOSPARC_PROJECT_DIR_PREFIX=CS-”
export “CRYOSPARC_FORCE_HOSTNAME=false”
export “CRYOSPARC_CLUSTER_JOB_MONITOR_MAX_RETRIES=1000000”
export “PATH=/home/cryosparc/cryosparc_master/deps/external/mongodb/bin:/home/cryosparc/cryosparc_master/bin:/home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/bin:/home/cryosparc/cryosparc_master/deps/anaconda/condabin:/home/cryosparc/cryosparc_master/bin:/home/cryosparc/.local/bin:/home/cryosparc/bin:/apps/relion-5.0.1/bin:/usr/lib64/openmpi/bin:/apps/ctffind-4.1.14:/apps/imod_5.1.9/bin:/home/noha/.local/bin:/home/noha/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin”
export “LD_LIBRARY_PATH=”
export “LD_PRELOAD=/home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/lib/libpython3.10.so”
export “PYTHONPATH=/home/cryosparc/cryosparc_master”
export “PYTHONNOUSERSITE=true”
export “CONDA_EXE=/home/cryosparc/cryosparc_master/deps/anaconda/bin/conda”
export “CONDA_PREFIX=/home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env”
export “CONDA_PROMPT_MODIFIER=(cryosparc_master_env)”
export “CONDA_SHLVL=1”
export “CONDA_PYTHON_EXE=/home/cryosparc/cryosparc_master/deps/anaconda/bin/python”
export “CONDA_DEFAULT_ENV=cryosparc_master_env”
[cryosparc@Yoshitsune /]$ namei -l /home/cryosparc/cryosparc_master/bin/cryosparcm
f: /home/cryosparc/cryosparc_master/bin/cryosparcm
dr-xr-xr-x root root /
drwxr-xr-x root root home
drwx------ cryosparc cryosparc cryosparc
drwxr-xr-x cryosparc cryosparc cryosparc_master
drwxr-xr-x cryosparc cryosparc bin
-rwxr-xr-x cryosparc cryosparc cryosparcm
[cryosparc@Yoshitsune /]$ ps -eo user:16,pid,ppid,start,cmd | grep -E “cryosparc_|mongo” | grep -v grep
cryosparc 6657 1 Sep 24 python /home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/bin/supervisord -c /home/cryosparc/cryosparc_master/supervisord.conf
cryosparc 6768 6657 Sep 24 mongod --auth --dbpath /home/cryosparc/database --port 39001 --oplogSize 64 --replSet meteor --wiredTigerCacheSizeGB 4 --bind_ip_all
cryosparc 6875 6657 Sep 24 /home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/bin/python3.10 /home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/bin/flask --app cryosparc_command.command_core run -h 0.0.0.0 -p 39002 --with-threads
cryosparc 6907 6657 Sep 24 /home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/bin/python3.10 /home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/bin/flask --app cryosparc_command.command_vis run -h 0.0.0.0 -p 39003 --with-threads
cryosparc 6946 6657 Sep 24 /home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/bin/python3.10 /home/cryosparc/cryosparc_master/deps/anaconda/envs/cryosparc_master_env/bin/flask --app cryosparc_command.command_rtp run -h 0.0.0.0 -p 39005 --with-threads
cryosparc 7002 6657 Sep 24 /home/cryosparc/cryosparc_master/cryosparc_app/nodejs/bin/node ./bundle/main.js
[cryosparc@Yoshitsune /]$ cryosparcm cli “get_scheduler_targets()”

{‘cache_path’: ‘/scratch/cs’, ‘cache_quota_mb’: None, ‘cache_reserve_mb’: 10000, ‘desc’: None, ‘gpus’: \[{‘id’: 0, ‘mem’: 25153634304, ‘name’: ‘NVIDIA RTX PRO 4000 Blackwell’}, {‘id’: 1, ‘mem’: 25153634304, ‘name’: ‘NVIDIA RTX PRO 4000 Blackwell’}\], ‘hostname’: ‘Yoshitsune’, ‘lane’: ‘default’, ‘monitor_port’: None, ‘name’: ‘Yoshitsune’, ‘resource_fixed’: {‘SSD’: True}, ‘resource_slots’: {‘CPU’: \[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23\], ‘GPU’: \[0, 1\], ‘RAM’: \[0, 1, 2, 3, 4, 5, 6, 7\]}, ‘ssh_str’: ‘cryosparc@Yoshitsune’, ‘title’: ‘Worker node Yoshitsune’, ‘type’: ‘node’, ‘worker_bin_path’: ‘/home/cryosparc/cryosparc_worker/bin/cryosparcw’}

I was advised to run this:

sudo chown -R cryosparc:cryosparc /mnt/3extra_hdd/cryoSPARC/CS–f2-1/exports

To solve the problem

11

Seems plausible. You may want to also investigate how the directory came to be owned by the (non-existing on the current master computer) Linux user with ID 1011, to avoid similar future issues.