systemctl access denied when root
Solution 1
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.
Solution 2
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.
Solution 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.
Related videos on Youtube
spraff
Updated on September 18, 2022Comments
-
spraff almost 2 years
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 over 7 yearsI get no output instead of
Removed symlink
and afterwardssystemctl disable avahi-daemon.socket
fails as before, producing the same line inaudit.log
-
Elouan Keryell-Even over 7 yearsCan you try to disable selinux enforce mode?
setenforce 0
-
spraff over 7 years
systemctl disable avahi-daemon.socket
succeeds aftersetenforce 0
withoutsystemctl daemon-reexec
(and I realise now theunmask
is your command, not mine :-)) Is it okay to just do this andsetenforce 1
after? -
Elouan Keryell-Even over 7 years@spraff I don't know, I'm a SELinux newbie ha ha. Imma mention
setenforce 0
in my answer then. -
user1130976 over 7 years@spraff you can run
setenforce 1
after. that resets it to enforce. -
Ramhound about 7 yearsYou 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.
-
Younes over 6 yearsPlease don't
setenforce 0
. This is a bad practice in production environment. Please usesystemctl daemon-reexec
instead. -
Pancho Jay over 6 years
systemctl daemon-reexec
worked on RHEL 7.4. -
aaaaaa about 6 years
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 doessetenforce 0
do? Why it sets the enforce status to permissive of course! -
rogerdpack about 5 yearswhich log file showed the message?
-
buergi about 5 yearsThanks. Solved my problem I had after upgrading an archlinux distro after a long time.
-
Roy Shilkrot over 4 yearsworked on Ubuntu 18.10 - Thanks!
-
gwik over 4 yearsSame issue while force dist-upgrading ubuntu cosmic. Worked, thx.
-
Rebs about 4 yearsIt 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.
-
Muhammad Mehran Khan Attari about 4 yearsIt worked on Ubuntu 20.04 (upgraded from 18.10) and saved me a ton of headaches. Bundle of thanks
-
sodimel almost 4 yearsTried to upgrade lubuntu 18.10 to lubuntu 20.04 and had this error with
whoopsi
service. Thesystemctl daemon-reexec
did the trick, thanks :) -
4t8dds over 2 yearsI 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.