This article is of a kind – “/.autorelabel” file does not work, because the enable of SELINUX ended with unreachable server.

Enabling the SELINUX should be easy as

1. just editing a text file – /etc/selinux/config to include

   SELINUX=enforcing
   

2. relabel all (or at least the root) file systems by creating the “/.autorelabel” file.
3. restarting the system. The boot process will detect the “/.autorelabel” file and relabel the file systems and then it will restart the system in the normal boot order.

But this time the relabeling did not happen as usual (It happened on CentOS 8, but probably could happen in any Linux distribution?). The server never got reachable again and on the screen, there were multiple errors – all of “Permission denied”!

It is better when enabling SELINUX to set “permissive” mode at first and relabel the root file system with “/.autorelabel” and then to enable “enforcing” mode of SELINUX.

Using “permissive” first for the relabel process guarantees you would have your server back after the process because the SELINUX rules are not enforced.
Here is the better procedure of enabling the SELINUX:

1. just editing a text file – /etc/selinux/config to include

   SELINUX=permissive
   

2. relabel all (or at least the root) file systems by creating the “/.autorelabel” file.
3. restarting the system. The boot process will detect the “/.autorelabel” file and relabel the file systems and then it will restart the system in normal boot order.
4. edit the /etc/selinux/config to enable “enforcing” mode

   SELINUX=enforcing
   

5. Restart (it’s better) or just enable SELINUX enforcing live with:

   setenforce 1
   

Our screenshots log of the relabel failure process

SCREENSHOT 1) No autorelabel initiated on boot despite the presence of “/.autorelabel” file.

Multple “Permission Denied” errors and many reports from “audit” – the SELINUX log daemon. The host is unreachable – no network started. No logging is possible!

SCREENSHOT 2) A page up above the first screen – more “Permission Denied” errors.

SCREENSHOT 3) Second page up above the first screen – the SELINUX rules loaded successfully but no autorelabel process initiated.

A successful relabel process on boot

SCREENSHOT 1) Successful start of the relabel process.

We’ve changed the SELINUX mode to be “permissive” and everything is back to normal, the “/.autorelabel” file initiated the relabel on the next boot.

SCREENSHOT 2) The relabeling of the file system is in progress.

There is a progress counter.

SCREENSHOT 3) The relabel process finished successfully and the reboot is initiated.

The next reboot the “/.autorelabel” file won’t exists and the system will boot normally.