Installing and using EOS client with other Linux distros


did anyone try (and succeeded) in mount an EOS volumn using other linux distros (Debian, Ubuntu)? EOS clearly targets (CERN) CentOS and is only provided via YUM repos and RPMs.

So I wonder if someone already managed to install the EOS client on .deb file based distros and if there is a clear path, or if I should not even try ;).

The background is that at CERN EOS takes over tasks that were previously provided by AFS, which is being phased out. Due to compability with newer software (and some UI issues), I can’t use CC7 and are using Ubuntu. Being able to mount EOS volumes under Ubuntu would be very interesting for me.



We are building the DEBIAN clients. You can find them here:

1 Like

Hi Andreas,

thanks for your reply. In fact I’ve already stumbled over this (indirectly) by browsing this article in the knowledge base:

However, the structure of the repo doesn’t look familiar to me and I did not manage the find the repo line I need to add to the apt repos so that it could read the information in it. It only contains the “commits” and “tags” folders, but doesn’t seem to contain and packages in these folders.

Do you know how I need to specify this repo? For the xrootd client, the line is:

deb artful master

I tried similar combinations for the eos repo, but none worked.


Ok, I finally managed to install the eos-client package on my Ubuntu by adding the following two lines to my /etc/apt/sources.list file:

deb artful release
deb artful tag

After that, I obtain and add the repo key:

curl -sL | sudo apt-key add -

After that, I was able to install the eos-client package:

sudo apt update
sudo apt install eos-client

Thanks for your help.


Also, in order to avoid the following warning messages:

N: Skipping acquire of configured file 'release/binary-i386/Packages' as repository ' artful InRelease' doesn't support architecture 'i386'
N: Skipping acquire of configured file 'tag/binary-i386/Packages' as repository ' artful InRelease' doesn't support architecture 'i386'

one could add the [arch=amd64] option on the respective sources list lines, e.g.:

deb [arch=amd64] artful release
deb [arch=amd64] artful tag


Hi all,

I was also looking for a way to mount /eos/… on other distributions (Archlinux in my case), so was basically looking for the source and instructions to build the EOS client. I guess the sources can be found somewhere in but there are lots of packages and I guess not all of them are needed.

Are there instructions somewhere how to build the EOS client and any dependencies?


Why not use a docker container of eosd?

Using :shared volume maps, host network stack, host pid space, and some additional capabilities, it runs fine sharing into the host namespace, as well as into other containers.

docker run --restart=always -d -ti --security-opt apparmor:unconfined \
–cap-add SYS_ADMIN --device=/dev/fuse --pid=host --net=host \
–name myeosdcontainer \
-v /eos:/eos:shared \
-v /var/log/eos/fuse:/var/log/eos/fuse \
-e CONFIGURATION=<url to centrally hosted eosd config> \

Of course, that container tag won’t work for you, but I believe we’ve released the Dockerfile on github. @crystal, could you please share a link when you get a chance?

Thanks for the quick reply and useful suggestion!

I have not run docker myself before, and to be honest am a bit sceptical whether it should be the canonical way of running a daemon permanently on a system? But maybe that’s just an old-school attitude, and that’s indeed a light-weight way of running this. Is it actually just the client that is run within this docker container, and I guess I’ll have to read up on what you mean by “that container tag won’t work for me”?

But maybe to be explicit: can I understand your message as that there won’t be any supported way to install an EOS client in my system directly? That would be a pity, as I was looking forward to moving away from afs (and its kernel modules) to a nice fuse-based client.


The container I list in that run command won’t work, because you can’t authenticate to our internal registry.

The advantage of the eosd inside a container is that EOS is written to run on a CentOS/RHEL alike OS. You won’t have to maintain the numerous libraries the EOS requires, and the element inside the namespace is the supported environment. When things go wrong, a debug report makes much more sense.

We run scheduled batch jobs with isolated eosd mounts inside them too, so any given system may have 50 or more “system wide” eosd mounts at a time, and if we ever have an issue with one, it’s isolated to only that batch job.

In fact, we even run EOS inside containers, with encrypted filesystems managed by a secrets manager in our orchestrator.

Hi David,

This setup of eosd running inside a container might be useful to us. Would it be possible to know how you created the docker image (i.e. a Dockerfile) ? Or is it nothing more than package install, config load and daemon run ?
Did you manage to set it up so that processes inside the other containers can be authenticated through kerberos authentication ?

hi, here’s how we build our docker containers:

it’s worth noting that we do use different config values in production (via environment variables) - but that repo should have all you need to build the containers and run up a sample test cluster.

you’ll need to:

  • generate your own containers/content/eos.keytab file
  • ./build && ./setup -a
  • to use fusex, you’ll need to edit containers/content/config/eosxd/fuse.conf manually for now
    • we don’t use fusex in production though, still trialling it out on our dev cluster

you can (and should) specify your own registry to push the images to, if you want to actually use them. by default the images build without a repository, and the docker-compose file uses those to build a test cluster locally.

@franck-jrc we don’t use kerberos auth, but it would be interesting to see that done.

1 Like

Hi and many thanks for your instructions, I managed to install eos-client on Ubuntu.
Just a question: once it’s installed, how do I actually mount EOS to /eos?

I am running disco dingo. Can I build the deb package from the source?



If it’s still relevant, perhaps this link can help you setup a fuse mount as easy as possible:


1 Like

Hello Stefano,

Yes, EOS can be successfully built on recent distros (such as cosmic and disco). I’ve actually built it today on disco. However, some small tweaks need to be done.
At the same time, we plan to provide deb packages for a newer distribution very soon. If you’re willing to wait a couple of days (hopefully end of this week), you’ll be able to install the packages from our repository.

Nevertheless, if you want to build it from source:

  1. You’ll need XRootd packages (will have to compile/build packages as well)
  2. EOS has many dependencies. The best way to install them is by following our dependencies files in debian/control. For disco, change occurrences of libprotobuf10 to libprotobuf17.
    The commands to run after you have done this change:
mk-build-deps --build-dep debian/control
gdebi -n eos-build-deps-depends*.deb

The gdebi command will fail if it can’t find xrootd packages. In case you don’t want to build XRootd packages in step 1 (but instead go for make install), the easiest way is to also remove the xrootd dependencies from the debian/control file

  1. Required cmake options: -DCLIENT=1
cmake <eos-repo> -DCLIENT=1
make install
  1. The eos client should be installed

This is a very short brief and many problems may appear throughout the process.

Feel free to e-mail me for more details.


Dear Mihai,
thanks a lot for the detailed instructions.
I have to admit that I will be very glad to wait for the binary packages, anyway (^^)

Thanks a lot for your support


Ubuntu Disco packages are now available.
To install them, please add the following XRootd and EOS repositories to your sources list:

deb ' disco master'

deb ' disco commit'
curl -sL | apt-key add -
apt-get update -y

For the moment, only the commit-based packages are available.
The releases/tags packages will become available later on.

Best Regards,

Hi all,
First of all big thanks to Mihal for maintaining the ubuntu repo! :smile:

Now, I have a problem, with a funny behaviour: I can install eos on my ubuntu 19.04 (and I had exactly the same problem with 18.04), and I can happily access the cms files(like this [1]) but at the same time I cannot access the home directories.
My username is mersi and yet I cannot even access home-m:

ls /eos/home-m
ls: cannot open directory ‘/eos/home-m’: No such file or directory

Which is also curious because home-m appears in the list of directories in /eos
Now, in theory I configured my system exactly as another machine I have with Scientific Linux CERN SLC release 6.10 (Carbon), which works.

Is there a trick I do not know to get it running on ubuntu, or maybe a way to debug what’s going wrong?

Thanks in advance

[1] /eos/cms/store/data/Commissioning2015/Cosmics/RECO/PromptReco-v1/000/234/014/00000/12E5CDD7-04B4-E411-9FC3-02163E012A56.root

Hello Stefano,

The ubuntu_disco branch has been merged into dev.

From now on, commit releases should appear at disco commit

while tag releases (starting from 4.4.48) under disco tag

I’m not sure I understand the example from [1] (to me, it displays a file name, not a command).
Are you trying to access via FUSE (eosd mount) or FUSEX (eosxd mount)?
In both cases, looking at the config file may provide more info.

However, I think for debugging, it’s best to message me in private or send an e-mail to, explaining the steps you’ve done so far and the problem you encounter.

Note: the fuse(x) logs can be found under /var/log/eos/

Best Regards,