Esse problema tem a ver com o 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)"
Você pode tentar lidar com isso ou desabilitar o SELinux. É geralmente aconselhável NÃO desativar o software que está tentando tornar seu sistema mais seguro, mas se for um desktop ou não um tipo de sistema de produção, essas são abordagens mais fáceis de achar mais aceitáveis.
Para desativar o SELinux e colocá-lo no modo permissive :
$ getenforce
Enforcing
$ setenforce 0
setenforce: SELinux is disabled
Para torná-lo permanente, edite este arquivo, /etc/selinux/config , e altere a linha SELINUX= para que ele indique permissive ou disabled . Uma reinicialização é necessária para retirar a alteração desse arquivo.
/ permissions
Outro culpado que pode levar a esse cenário tem a ver com as permissões do diretório raiz. Há uma "solução" registrada no site de soluções principais da Redhat intitulado: O que é "DBus.Error.AccessDenied: Uma política do SELinux impede que o remetente envie esta mensagem para este destinatário "? .
A questão é esta:
Permissions on / have been set to 700 ; restoring to 555 solved the issue
A correção:
Ensure permissions on / are 555 ; if not adjust them by chmod 555 /
Você pode verificar se esse é seu problema usando o abrt . Você normalmente verá essa mensagem quando fizer login em um sistema que esteja sofrendo com essa configuração incorreta:
ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1444824402
Investigando a falha da ABRT:
$ abrt-cli list --since 1444824402
id 050f5a46e0749583aaf102958b2ab1cc976133d9
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
package: firewalld-0.3.9-11.el7
uid: 0 (root)
count: 2
Directory: /var/spool/abrt/Python-2015-10-14-06:56:16-905
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
O systemd também reporta este estado de falha:
$ 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'.