28

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)

4
  • 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 '16 at 23:38
  • I'm running a fresh CentOS install in VirtualBox. Does that count as a container?
    – spraff
    Sep 16 '16 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 '16 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 '16 at 16:24
34

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
Enforcing

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=?'

Solution

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.

9
  • 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 '16 at 14:38
  • Can you try to disable selinux enforce mode? setenforce 0 Oct 4 '16 at 14:47
  • 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 '16 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 '17 at 9:16
  • 1
    systemctl daemon-reexec worked on RHEL 7.4.
    – Pancho Jay
    Mar 22 '18 at 19:48
26

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.

4
  • 2
    Thanks. Solved my problem I had after upgrading an archlinux distro after a long time.
    – buergi
    May 31 '19 at 20:19
  • 3
    worked on Ubuntu 18.10 - Thanks! Jan 3 '20 at 18:01
  • Same issue while force dist-upgrading ubuntu cosmic. Worked, thx.
    – gwik
    Mar 13 '20 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 '20 at 14:10
3

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
  • 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 '17 at 21:35
  • which log file showed the message?
    – rogerdpack
    May 16 '19 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 '20 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.