Sharing the exca cache on the same machine: chmod issues for non-owners

[BelCorentin]

Hi,

As I'm trying to reuse the cache of an existing user, I encounter the following problem:

2026-06-03 17:45:11 - WARNING - exca.cachedict.core:136 - Failed to set permission to 511 on [/data/shared/neuralset_cache/Bonnaire2026/name](https://vscode-remote+ssh-002dremote-002bext1.vscode-resource.vscode-cdn.net/data/shared/neuralset_cache/Bonnaire2026/name)=Bonnaire2026,query=timeline_index1,infra_timelines.version=v1-ab707c8e/name=EmptySentenceCleaner-9c2f9e47/name=SyntaxEnhancer-c1cd2c0b/cache
([Errno 1] Operation not permitted: '/data/shared/neuralset_cache/Bonnaire2026/name=Bonnaire2026,query=timeline_index1,infra_timelines.version=v1-ab707c8e/name=EmptySentenceCleaner-9c2f9e47/name=SyntaxEnhancer-c1cd2c0b/cache')

Problem is that exca is trying to chmod some folders (to lock the cache) but since I don't own the folder, I can't do it (even though I'm part of the group owning the folder.

Am I missing something obvious here? Or is there something that could be tackled at exca level ?

[teonbrooks]

I have a related issue to this. exca doesn't change permissions to some of the intermediate folders it creates, which can lead to permission errors when sharing a cache.

I encountered this as we are building on neuralreport and we have a shared cache. here's a diagnosis of the issue from our fave friend, Claude:

permissions not applied to intermediate cache directories created by mkdir(parents=True)

Summary

When an infra's permissions is set (e.g. 0o777 for a shared cluster cache), the
intermediate directories that exca creates on the way to the leaf uid folder do
not get chmod'd — only the cache root and the final leaf folder do. On a
multi-user tree this blocks a second user from writing, because those intermediate
directories keep the umask-reduced default mode (e.g. 0o775) instead of the
requested 0o777.