On 13 June 2013 14:20, Vishesh kumar <linuxtovishesh at gmail.com> wrote: > You can also use audit2allow, audit2allow will write allow rule for you. > > Not a good option in this case considering there's reasonable likelihood of messed up labelling... While the tool audit2allow will create a module that will allow the activities blocked in the log without case it can cause the system to be opened up to issues... With the incorrect labelling in the first place (seriously... the base targeted selinux policy in now way should be blocking the mounting of an lvm volume) it could leave you in a ... weird... situation... much better to work out what is causing incorrect labels in the first place... Doing a quick check of semanage fcontext -l | grep '/dev/mapper' on one of my systems it looks like it should be labelled system_u:object_r:fixed_disk_device_t:s0 ... OP - what does that show you your system thinks it should be labelled as? Doing semanage fcontext -l | grep 'quota_db_t' on one of my systems shows that label should be on: /a?quota\.(user|group) /boot/a?quota\.(user|group) /etc/a?quota\.(user|group) /var/a?quota\.(user|group) /var/lib/openshift/a?quota\.(user|group) /var/lib/stickshift/a?quota\.(user|group) /var/spool/(.*/)?a?quota\.(user|group) So it looks like someone has been playing silly buggers with contexts ... the main question then is if they added it to the system policy via semanage fcontext or if they did chcon ... if the former then it'll need to be cleared out the policy (double check if they did by looking in /etc/selinux/targeted/contexts/files/file_contexts.local ) but if the latter a restorecon (or fixfiles but restorecon probably nicer to use) should fix it.