Description of problem: The problem is that the rpc.statd is not running: rpc.statd[17919]: Version 1.0.9 Starting rpc.statd[17919]: rename (/var/lib/nfs/statd/sm to /var/lib/nfs/statd/sm.bak): Permission denied I managed to resolve this by removing /var/lib/nfs/statd/sm.bak and then it can be started by service nfslock start. The problem with rpc.statd only happens when there have been mounts and therefore there are files in /var/lib/nfs/statd/sm With selinux off nfslock starts correct. Also I found that the latest update of nfs-utils something was changed in the behaviour of the sm and sm.bak directories (see BZ#782455). Maybe selinux wasn't taken ino account here. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.SELinux enforcing 2.NFS as a cluster service 3.Problem only occurs if you have a NFS share in a cluster. For some reason the cluster manager writes the nfs locks to the NFS share itself. But if this NFS share is also a home directory the selinux label is probably user_u:object_r:user_home_t. So if cluster manager copies these files on startup to /var/lib/nfs/statd/sm it still has the user_u:object_r:user_home_t context where nfslock expects system_u:object_r:var_lib_nfs_t:s0 Actual results: Expected results: Additional info:
What avc's are you seeing? matchpathcon /var/lib/nfs/statd/sm.bak /var/lib/nfs/statd/sm.bak system_u:object_r:var_lib_nfs_t:s0
Do you see any AVCs when reproducing the problem? # ausearch -m avc -m selinux_err
Hi, are we able to reproduce this bug in our environment?
So this is not an selinux issue but belongs to the script doing the cp. One other solution would be to run restorecon after the copy.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Fix pending pull upstream at https://github.com/ryan-mccabe/resource-agents/commit/d32885baaeab0b58df42a5d52697e23ed6a14e52
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1316.html