How to Disable SELinux on Fedora Linux

Docker containers refusing to start, custom services failing with cryptic permission errors, legacy applications that will not cooperate with mandatory access controls: these are the situations where you need to disable SELinux on Fedora. SELinux is a powerful security layer that ships enabled by default, but when it blocks something you need to run, knowing how to turn it off (and back on) saves hours of troubleshooting.

Every Fedora release (43, 42, and all earlier versions) ships SELinux in enforcing mode. Switching to permissive is a quick, reversible test. Editing the config file disables the policy permanently, while grubby shuts down the kernel module entirely. Whichever method you pick, re-enabling later requires a filesystem relabel to restore security contexts.

Check SELinux Status on Fedora

Before making changes, confirm what mode SELinux is running in. The sestatus command shows the full picture:

sestatus

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      35

This guide uses sudo for commands that need root privileges. If your user is not in the sudoers file yet, follow the guide on how to create a sudo user on Fedora.

For a quick one-word check, getenforce returns Enforcing, Permissive, or Disabled:

getenforce

Enforcing

SELinux Mode Comparison

Fedora uses SELinux in targeted policy mode by default, meaning it enforces rules on specific system services while leaving most user processes unconfined. The three modes control how strictly those rules apply:

Mode	Enforcement	Logging	When to Use
Enforcing	Blocks policy violations	Yes (/var/log/audit/audit.log)	Production systems, any security-sensitive environment
Permissive	Allows everything	Yes (logs what would be blocked)	Troubleshooting, testing policy changes, isolating SELinux as the cause of failures
Disabled	None	No	Development environments, compatibility testing (requires relabel to re-enable)

Temporarily Disable SELinux on Fedora

Switching to permissive mode lets everything run while still logging what SELinux would have blocked. This is the fastest way to test whether SELinux is causing a problem, and the change reverts automatically on the next reboot.

sudo setenforce 0

Confirm the mode changed:

getenforce

Permissive

SELinux is still loaded and logging violations to /var/log/audit/audit.log, but it will not block anything. To switch back without rebooting:

sudo setenforce 1

Permanently Disable SELinux on Fedora

Editing /etc/selinux/config prevents SELinux from loading its policy at boot. Use sed for a one-liner or open the file in a text editor:

sudo sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

Alternatively, open the file with nano and change the SELINUX= line manually:

sudo nano /etc/selinux/config

Set the value to:

SELINUX=disabled

Reboot for the change to take effect:

sudo reboot

After the system restarts, verify SELinux is off:

sestatus

SELinux status:                 disabled

Disable SELinux at Kernel Level with grubby on Fedora

On modern Fedora releases, the config file method prevents the policy from loading but does not fully shut down the SELinux kernel module. For complete kernel-level disablement, pass selinux=0 on the boot command line with grubby:

sudo grubby --update-kernel ALL --args selinux=0

Reboot and confirm:

sudo reboot

sestatus

SELinux status:                 disabled

To reverse the kernel parameter later, remove the argument and reboot:

sudo grubby --update-kernel ALL --remove-args selinux

The config file method is sufficient for most troubleshooting and development work. Use the kernel parameter when you specifically need the SELinux module itself unloaded, such as benchmarking without any LSM overhead or working around kernel-level SELinux bugs.

Re-Enable SELinux on Fedora

Reactivating SELinux requires modifying the configuration and triggering a filesystem relabel. Skipping the relabel step can cause boot failures or severe permission errors because files created while SELinux was off have no security context labels.

If you used the grubby kernel parameter method, remove it first:

sudo grubby --update-kernel ALL --remove-args selinux

Next, set the config file back to enforcing (or permissive if you prefer to test first):

sudo sed -i 's/^SELINUX=disabled/SELINUX=enforcing/' /etc/selinux/config

Create the autorelabel marker so the system relabels every file on the next boot:

sudo touch /.autorelabel

Reboot the system:

sudo reboot

The relabeling process takes longer than a normal boot, sometimes 10-30 minutes on large filesystems. Do not interrupt it or force a shutdown during relabeling.

Once the reboot completes, verify SELinux is active:

sestatus

SELinux status:                 enabled
Current mode:                   enforcing

Troubleshoot SELinux Issues on Fedora

Filesystem Relabeling Takes Extremely Long

After you re-enable SELinux following a period of disablement, the system relabels every file with the correct security context. On systems with large filesystems or millions of files, this process can take 30 minutes or longer.

During relabeling, you will see:

*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.
***

Monitor progress by switching to a different virtual console (Ctrl+Alt+F2) and checking the relabeling log:

sudo tail -f /var/log/messages | grep setfiles

Do not interrupt the relabeling process. If you cancel it, the system will remain in an inconsistent state that requires a forced relabel on the next boot by recreating the /.autorelabel file.

System Fails to Boot After Configuration Change

If you encounter boot failures after modifying /etc/selinux/config, the configuration file may contain syntax errors or an invalid mode value.

Boot into rescue mode by selecting the rescue kernel from the GRUB menu, then check the configuration file:

sudo cat /etc/selinux/config | grep SELINUX=

Valid values are enforcing, permissive, or disabled. Correct any typos and reboot. If the file is severely corrupted, recreate it with the default content:

sudo tee /etc/selinux/config <<EOF
SELINUX=enforcing
SELINUXTYPE=targeted
EOF

Application Still Blocked After Switching to Permissive Mode

If an application continues failing after switching to permissive mode, the issue is not SELinux-related. Verify the current mode is actually permissive:

getenforce

Permissive

Check the application’s logs and system journal for the actual error:

sudo journalctl -xe

Common non-SELinux causes include firewall rules blocking network connections, incorrect file permissions, missing dependencies, or configuration errors. For Docker on Fedora, check container-specific permissions and volume mount contexts. For network services, verify firewall rules allow the required ports with Firewalld on Fedora and confirm SSH access on Fedora if connecting remotely.

Denied Operations Still Appearing in Audit Log After Disable

After setting SELINUX=disabled in the configuration file, SELinux continues running until you reboot. Check the actual status:

sestatus

If the output shows Current mode: enforcing or permissive, the configuration change has not taken effect yet. Reboot the system to apply the configuration file changes. If you need immediate disablement without rebooting, use sudo setenforce 0 to switch to permissive mode temporarily.

Frequently Asked Questions

Conclusion

SELinux is either out of the way or narrowed down to permissive logging, depending on how far you needed to go. If you re-enable later, create /.autorelabel before rebooting. Skip that step and the system spends the next boot fighting context mismatches.

While SELinux is off, configure Firewalld on Fedora for network filtering. Fail2Ban with Firewalld on Fedora blocks repeated brute-force attempts, and ClamAV on Fedora handles file-level malware scanning.