This issue has to do with SELinux.
An SELinux policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)"
You can either try and deal with this or disable SELinux. It's generally advisable to NOT disable software that's attempting to make your system more secure, but if it's a desktop or not a production type of system, these are easier approaches to find more accepting.
To disable SELinux and put it into
$ setenforce 0
setenforce: SELinux is disabled
To make this permanent you can edit this file,
/etc/selinux/config and change the line
SELINUX= so that it says either
disabled. A reboot is required to pick up the change from this file.
Another culprit that may lead to this scenario has to do with the root directory's permissions. There's a "solution" logged on Redhat's main solutions site titled: What is "DBus.Error.AccessDenied: An SELinux policy prevents this sender from sending this message to this recipient" ?.
The issue is this:
Permissions on / have been set to 700 ; restoring to 555 solved the issue
Ensure permissions on / are 555 ; if not adjust them by chmod 555 /
You can further verify if this is your issue using the
abrt. You'll typically see this message when you log into a system that's suffering from this misconfiguration:
ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1444824402
Investigating the ABRT failure:
$ abrt-cli list --since 1444824402
reason: bus.py:122:__new__:DBusException: org.freedesktop.DBus.Error.AccessDenied: An SELinux policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)
time: Wed 14 Oct 2015 06:56:16 AM EDT
cmdline: /usr/bin/python -Es /usr/bin/firewall-cmd --zone= --change-interface=eth0
uid: 0 (root)
Run 'abrt-cli report /var/spool/abrt/Python-2015-10-14-06:56:16-905' for creating a case in Red Hat Customer Portal
The Autoreporting feature is disabled. Please consider enabling it by issuing
'abrt-auto-reporting enabled' as a user with root privileges
systemd also reports this failure state:
$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
avahi-daemon.service loaded failed failed Avahi mDNS/DNS-SD Stack
libstoragemgmt.service loaded failed failed libstoragemgmt plug-in server daemon
ovirt-guest-agent.service loaded failed failed oVirt Guest Agent
postfix.service loaded failed failed Postfix Mail Transport Agent
rngd.service loaded failed failed Hardware RNG Entropy Gatherer Daemon
systemd-logind.service loaded failed failed Login Service
tuned.service loaded failed failed Dynamic System Tuning Daemon
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
7 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.