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)

spraff
  • 2,106
  • 5
  • 37
  • 58
  • 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? – allquixotic 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. – allquixotic 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". – danmichaelo Dec 01 '16 at 16:24

3 Answers3

37

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.

Elouan Keryell-Even
  • 831
  • 1
  • 10
  • 14
  • 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 04 '16 at 14:38
  • Can you try to disable selinux enforce mode? `setenforce 0` – Elouan Keryell-Even Oct 04 '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 04 '16 at 21:14
  • @spraff I don't know, I'm a SELinux newbie ha ha. Imma mention `setenforce 0` in my answer then. – Elouan Keryell-Even Oct 05 '16 at 09:32
  • @spraff you can run `setenforce 1` after. that resets it to enforce. –  Dec 06 '16 at 12:22
  • 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 09:16
  • 1
    `systemctl daemon-reexec` worked on RHEL 7.4. – Pancho Jay Mar 22 '18 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 '18 at 21:58
  • Tried to upgrade lubuntu 18.10 to lubuntu 20.04 and had this error with `whoopsi` service. The `systemctl daemon-reexec` did the trick, thanks :) – sodimel Aug 01 '20 at 16:56
  • @Younes and if `systemctl daemon-reexec` doesn't work? – KernelDeimos Sep 05 '22 at 00:47
33

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.

Malvineous
  • 2,501
  • 2
  • 26
  • 35
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.

Jon
  • 41
  • 1
  • 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 05:30