EOS 5.2 on Alma Linux 9.3 fresh install


I’ve just installed eos 5.2 on Alma Linux 9.3 as a server and client, but before starting using it I’m facing a permission denied when issuing the command:

eos space define default
error: errc=3010 msg=“[ERROR] Error response: permission denied”

I think that it is a dumb question, but anyway, couldn’t find a solution yet.


Hi Wander,

This usually means that you don’t have an admin role when connecting to EOS. The easiest way to see who you are authenticated as by the server, is to run the following command:
eos whoami

Then probably you want to run your eos commands as root since then you can pick up the sss key and be authenticated as an admin on the EOS instance. It’s important to also enable sss mapping on you instance using the following command eos vid enable sss.


Hello Elvin,

Thanks for your attention.
Looks like eos is being authenticated as nobody (99), even being started as root:

EOS Console [root://] |/> whoami
Virtual Identity: uid=99 (99) gid=99 (99) [authz:sss] host=silix domain=localdomain

I don’t have any eos_user user on my /etc/passwd and don’t know if I must create one, since I didn’t find any instructions to do that.

I’m also confused about hostnames and networks, since the mgm log file is showing this:

=====> mgmofs.hostname: localhost.܈.
=====> mgmofs.hostpref: localhost
231122 08:36:08 122161 MgmOfs_Config: Unable to convert hostname to IP address: Name or service not known; no such file or directory
------ xroot protocol initialization completed.
------ eos-mgm mgm@localhost:1094 initialization completed.
231122 08:37:37 122332 XrootdXeq: root.123283:27@silix pvt IP46 login as eosnobody

My Internet connection comes from Wi-Fi DHCP ( but I’m trying to use a local network ( where I have other machines planed to be used as FST nodes in my initial tests.

The “eos vid anable sss” do not work at the moment:

[root@silix ~]# eos vid enable sss
error: errc=3010 msg=“[ERROR] Error response: permission denied” (errc=3010) (Unknown error 3010)
[root@silix ~]#


Hi Wander,

I think the root of your problems is the fact that the MGM can not properly get the hostname which needs to be FQDN for the machine it’s running on. Check what is the output of the hostname -A command and see if it matches your expectations, but clearly the xrootd process can not get a proper hostname. What is does underneath is to simply call the C function gethostname, so this should be easy to debug.


Hello everyone following this topic.
Just to inform that I finally have EOS running on Alma 9:

[root@silix qdb]# eos


EOS Copyright (C) 2011-2020 CERN/Switzerland

This program comes with ABSOLUTELY NO WARRANTY; for details type `license’.

This is free software, and you are welcome to redistribute it

under certain conditions; type `license’ for details.


EOS Console [root://localhost] |/>

[root@silix qdb]# uname -r

After trying to implement things with two different networks, I let one down and could follow ahead.
I’ll try now some clients - Windows, Mac and Linux.

Thanks @esindril!

I have the same issue, could you share your method to resolve this permission problem

Hello Markliulei,

That was a long fight, but basically I turn down one of my networks (10.0.0.x) and made the EOS work on the other NIC (192.168.X.Y)·
Maybe if I send you some of my configurations, it could help you.

[root@silix ~]# cat /etc/hosts localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6



The fully qualified hostname of current MGM







sec.protocol sss -c /etc/eos.client.keytab -s /etc/eos.keytab

sec.protbind localhost.localdomain unix sss
sec.protbind localhost unix sss
sec.protbind * only sss unix

mgmofs.broker root://localhost.localdomain:1097//eos/

mgmofs.instance eosdev

mgmofs.fstgw localhost.localdomain:3001

xrootd.seclib libXrdSec.so
sec.protocol unix
sec.protocol sss -c /etc/eos.client.keytab -s /etc/eos.client.keytab
sec.protbind * only unix sss

fstofs.broker root://localhost.localdomain:1097//eos/
fstofs.autoboot true
fstofs.quotainterval 10
fstofs.metalog /var/eos/md/

fstofs.qdbcluster localhost:777
fstofs.qdbpassword_file /etc/eos.keytab

export EOS_MGM_URL=root://localhost

Hope this can help you.

We had a similar problem. When we run the following command and got

$ eos whoami
Virtual Identity: uid=99 (2,99) gid=99 (2,99) [authz:sss] host=[::ffff:] domain=0.0.1]

The host is not recognized as localhost. We added one line to /etc/hosts:

::ffff:  localhost localhost.localdomain localhost6 localhost6.localdomain6

and restarted mgm, mq and sync. Then we got:

eos whoami
Virtual Identity: uid=0 (0,2,3,99) gid=0 (0,2,4,99) [authz:sss] sudo* host=localhost domain=localdomain

User root on mgm server is recognized as root correctly.

BTW, we have only one network 10.5.32.x/24, and I’m not sure if it’s related to this problem.

Thanks byujiang!

That’s what I see here too before fix the problem.
What happens in my opinion is that one can make mistakes given the many files to configure the system.
So, before one can put things working, it’s easy to make a mess setting different values to the same variables in different configuration files…