Lock-file access error, define location of lockfiles?

I’m running a power analysis on a cluster which spawns >100 processes running mne.stats.permutation_t_test in long loops.

I’m getting an error related to a file lock once in a while

/xxx/anaconda3/envs/default/lib/python3.13/contextlib.py:141: RuntimeWarning: Could not acquire lock file after 5 seconds, consider deleting it if you know the corresponding file is usable:
/%HOME%/.mne/mne-python.json.lock

I don’t really understand where the process iis using the file lock, seems to be somewhere deeper inside the code?

However, the culprit is probably our network drive on which the $HOME is hosted, which sometimes has access delays. As I’m running on a cluster, the home is only accessible via network.

Is there any way to tell MNE where to store configs, e.g. with an env var? Or not use the lock files? If I could define a lockfile for each process independently that would be fine.

according to Claude Code investigation it is called here:


  The chain is:                                                                                                                                                                           
  permutation_t_test (line 90)                                                                                                                                                            
    → parallel_func (parallel.py:95)                                                                                                                                                      
      → get_config("MNE_CACHE_DIR")                                                                                                                                                       
        → _load_config → _open_lock (utils/config.py:257)
          → filelock.FileLock(..., timeout=5)  ← warning thrown here

I found the culprit! n_jobs=None is not equivalent to setting n_jobs=1 , even though it’s advertised as such!

Internally, the whole parallel_func chain is triggered when n_jobs=None, whereas it is skipped with n_jobs=1. Therefore, the config is loaded to check for MNE_CACHE_DIR, which isn’t necessary anyway because n_jobs is None.

Not sure if this is a bug or intended behaviour?

The n_jobs description for mne.stats.permutation_t_test says:

None (default) is a marker for ‘unset’ that will be interpreted as n_jobs=1 (sequential execution) unless the call is performed under a joblib.parallel_config context manager that sets another value for n_jobs.

Is the mne.stats.permutation_t_test call being made under a joblib.parallel_config context manager? If so, I’d say this isn’t a bug, otherwise could be worth looking into.

Nope, no joblib.parallel_config

i’ve opened an issue here: GitHub · Where software is built