Voms-proxy-init command not found in AlmaLinux9

Hello everybody,

I have already used CentOS 7(gcc11) platform in SWAN configuration for my coffea analysis. There, in order to access /eos/ and CMS datasets I used to set up a grid VO certificate in my home directory and I could access CMS datasets using XDROOT after executing the following commands in SWAN terminal:

‘‘export VO_CMS_SW_DIR=/cvmfs/cms.cern.ch’’

‘‘source $VO_CMS_SW_DIR/cmsset_default.sh’’

‘‘voms-proxy-init --rfc --voms cms -valid 192:00’’

Recently I decided to use AlmaLinux 9(gcc13) platform to be able to use jupyterlab. I set up my certificate but when I run ‘‘voms-proxy-init --rfc --voms cms -valid 192:00’’ in terminal I get the error:

“bash: voms-proxy-init: command not found”.

Does anybody know what is the problem?
How can I access /eos/ and CMS data in SWAN’s AlmaLinux 9 platform?

Thank you in advance for your help.

Dear Mohammad,

Indeed the generation of proxy certificates on the Alma9 image is still missing.

I have created the following task for the SWAN team to add the corresponding functionality:


Thank you for reporting, I suggest we follow the progress of the task in the link above.


1 Like

Also note that if the data is on /eos/cms, you should be able to access it normally now in Alma9 too. What we are missing is x509-based access to external data sources.

1 Like

Thank you very much dear Enric.

Your answer, created another question for me. Can I have access to CMS datasets on DAS normally without a proxy certificate in SWAN? I mean suppose I find my dataset on DAS and I want remote access to the root files in that dataset. Name of the file is
Can I get access to this file in my notebook without proxy certificate?

Coffea-casa package implemented a facility to handle access to remote files without certificate on its own cloud infrastructure. It replaces




Do we have such facility on SWAN?

Hi Mohammad,

I’m afraid we do not have any means to get you credentials to access that CMS data store automatically. They probably store that dataset on their local xcache server which they must configure with tokenized access, that is probably why you do not need the proxy certificate. We have an equivalent functionality for data that is on EOS, you can access it via xrootd or via local fuse client without kinit, but we don’t have the same for that CMS data store.


Since as a CMS user I would find this useful for SWAN as well, here’s what they do in Coffea-Casa: First Steps at Coffea-Casa @ UNL — coffea-casa 2023.11.16+39.g015f705 documentation

Coffea-casa handles the issue of certificates internally through xcache tokens so that its users do not explicitly have to import their certificates, though this dynamic requires adjustiment of the redirector portion of the path to the root file requested.


In addition to handling authentication, XCache will cache files so that they are able to be pulled more quickly in subsequent runs of the analysis. It should be expected, then, that the first analysis run with a new coffea-casa file will run slower than ones which follow afterwards.

Thanks for sharing this, Artur. I’d need to check if such XCache servers with tokenized access are configured at CERN. I’ll inform here if that’s the case after checking with my colleagues.

1 Like

Anyway as I said previously, for datasets on EOS we already have automatic credential generation when you start your session, so this would only be useful for tokenized access of cached external datasets.