When I run

sudo systemctl disable avahi-daemon.socket

I get

Failed to execute operation: Access denied

But it's run as root, how can access be denied? (CentOS 7)

  • Are you running in a container, like Docker or LXC or LXD? Do you know for sure you are or are not in a container? Sep 16, 2016 at 23:38
  • I'm running a fresh CentOS install in VirtualBox. Does that count as a container?
    – spraff
    Sep 16, 2016 at 23:50
  • No, VirtualBox isn't a container, it's a virtual machine. They're fundamentally different. Most likely you need to run journalctl -xe to figure out why this is happening. Sep 18, 2016 at 20:52
  • 1
    Note that this error message ("Failed to execute operation: Access denied") can also occur when trying to access a non-existing service in enforcing mode. In permissive mode, you would get "Failed to execute operation: No such file or directory". Dec 1, 2016 at 16:24

3 Answers 3


I also work on CentOS 7, and had a similar issue:

# systemctl unmask tmp.mount
Failed to execute operation: Access denied

The denial has to do with SELinux. This can be your case if you are running SELinux in enforcing mode:

# getenforce

In my case, the systemctl error had produced an USER_AVC denial in SELinux log file, /var/log/audit/audit.log:

type=USER_AVC msg=audit(1475497680.859:2656): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { enable } for auid=0 uid=0 gid=0 path="/dev/null" cmdline="systemctl unmask tmp.mount" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:null_device_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'


This article states that it is due to a bug in systemd, and provides a work around:

systemctl daemon-reexec

Secondary solution

If the above did not work, you can set SELinux mode to permissive:

setenforce 0

and it should work fine. However, this 2nd solution has security implications.

  • I get no output instead of Removed symlink and afterwards systemctl disable avahi-daemon.socket fails as before, producing the same line in audit.log
    – spraff
    Oct 4, 2016 at 14:38
  • 1
    systemctl disable avahi-daemon.socket succeeds after setenforce 0 without systemctl daemon-reexec (and I realise now the unmask is your command, not mine :-)) Is it okay to just do this and setenforce 1 after?
    – spraff
    Oct 4, 2016 at 21:14
  • 1
    Please don't setenforce 0. This is a bad practice in production environment. Please use systemctl daemon-reexec instead.
    – Younes
    Oct 10, 2017 at 9:16
  • 1
    systemctl daemon-reexec worked on RHEL 7.4.
    – Pancho Jay
    Mar 22, 2018 at 19:48
  • 1
    systemctl daemon-reexec did not work for me, I'm on fedora 28. setenforce 0 did work. Normally I'm against these security hacks but I'm swimming in my own hair out of frustration with working with nonsense apis such as 'daemon-reexec' and 'setenforce 0'. What does setenforce 0 do? Why it sets the enforce status to permissive of course!
    – aaaaaa
    Jun 13, 2018 at 21:58

In my case, I had just upgraded systemd and any systemctl command was failing:

# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied

However according to the init manpage, you can do the same thing by sending SIGTERM to the daemon running as PID 1, which worked:

kill -TERM 1

This reloaded the daemon, after which all the systemctl commands started working again.

  • 2
    Thanks. Solved my problem I had after upgrading an archlinux distro after a long time.
    – buergi
    May 31, 2019 at 20:19
  • 3
    worked on Ubuntu 18.10 - Thanks! Jan 3, 2020 at 18:01
  • Same issue while force dist-upgrading ubuntu cosmic. Worked, thx.
    – gwik
    Mar 13, 2020 at 21:45
  • 2
    It worked on Ubuntu 20.04 (upgraded from 18.10) and saved me a ton of headaches. Bundle of thanks Jun 27, 2020 at 14:10
  • I got the same issue. I upgraded my OS and then systemctl did not work for me. And this helps. Thanks. My version is centOS 8.
    – 4t8dds
    Dec 24, 2021 at 12:42

Neither solution worked for me. It turned out there was a missing = sign on one of the lines in my .service file. I discovered this by looking /var/log/messages and saw an error there that was more descriptive. So the Access Denied was misleading. It was not a really a security problem.

  • 3
    You should provide more detail on how you solve this question. For instance you talk about a more verbose error message, but do not indicate, what the error messag was exactly. Without this information, this would be better served as a comment, because this answer without this information is incomplete.
    – Ramhound
    Apr 12, 2017 at 21:35
  • which log file showed the message?
    – rogerdpack
    May 16, 2019 at 21:37
  • It appears this is triggered by any invalid syntax in the file (not just the = as you mention). Double check your service files for errors if you see this.
    – Rebs
    Apr 30, 2020 at 5:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.