Ask Your Question

Failed to mount POSIX Message Queue, Kernel File System... after hard reset; permission denied

asked 2018-04-28 02:31:40 -0500

przemhb gravatar image

My Fedora 27 x64 (4.14.14-300) run on GB-BACE-3160 Brix PC. The PC uses 320GB HDD. The system is used as a simple server, so it works 24h.

From time to time - a few weeks or so - it freezes. HDD keeps writing something (repetitive, although irregular sound). No reaction to keyboard, mouse, remote SSH access. I have tried to leave it overnight, but it does not recover, so I am forced to hard reset it.

This time something has broken. Booting fails. See

It says "Failed to mount POSIX Message Queue File System", "Failed to start Remount and Kernel File Systems", "Failed to mount Kernel Debug File System", "Failed to mount Huge Pages File System" and lots of other failures comes after these.

In emergency mode I have ran fsck. It says file systems are clean. Smartctl -h and short+long tests found the disk to be perfectly healthy.

In all these cases "Failed at step EXEC spawning /usr/bin/mount: Permission denied" is given as a reason.

What happen and how to fix this? What is causing system to freeze from time to time? How to diagnose it and prevent it?

I will be thankful for your help.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-05-07 14:41:10 -0500

przemhb gravatar image

I've changed SELinux to Permissive mode in /etc/selinux/config and system booted, so I've checked local modifications to SELinux config files and file_contexts:

#semanage fcontext -C -l
fcontext SELinux   type        Context
/usr/bin/mount     all files   system_u:object_r:samba_share_t:s0

I have noticed context for the mount is suspicious.

The problem was, indeed, caused by improper file context of the /usr/bin/mount file: sambasharet.

The file context change wasn't caused by some error due to hard reset, but... by my imprudent decision to follow the first suggestion of SELinux Alert Browser. This first suggestion was to change /usr/bin/mount file context to sambasharet to allow smbd to access getattr.

The solution was:

  1. Using emergency console remount filesystem in RW mode: mount / -oremount,rw
  2. Change SELinux mode to Permissive (optional)
  3. Restart system (optional)
  4. Delete invalid file context, restore default and relabel the file:

    [root@atlas ~]# ls -Z /usr/bin/mount
    systemu:objectr:sambasharet:s0 /usr/bin/mount
    [root@atlas ~]# semanage fcontext -d /usr/bin/mount
    [root@atlas ~]# restorecon -v /usr/bin/mount
    Relabeled /usr/bin/mount from systemu:objectr:sambasharet:s0 to systemu:objectr:mountexect:s0
    [root@atlas ~]# ls -Z /usr/bin/mount
    systemu:objectr:mountexect:s0 /usr/bin/mount

  5. switch SELinux to enforcing mode (optional)

  6. reboot system.
edit flag offensive delete link more

Question Tools

1 follower


Asked: 2018-04-26 15:59:25 -0500

Seen: 432 times

Last updated: Apr 26 '18