You restored a backup and now services fail
You restored a backup from a non-SELinux machine to your Fedora system. Or you moved a database directory to a new partition without preserving labels. Or you upgraded from Fedora 39 to 40 and a custom service suddenly crashes. The logs scream AVC: denied. You tried chmod 777 and it didn't help. The problem isn't Unix permissions. The problem is SELinux contexts are wrong.
The system thinks your config file belongs to a user's home directory, or your socket is labeled for a different service. The kernel enforces the policy and blocks the access. You need to rescan the filesystem and apply the correct labels based on the current policy.
What's actually happening
SELinux doesn't just check if user root can read a file. It checks if the process running as httpd_t is allowed to read a file labeled httpd_sys_content_t. When you copy files, move partitions, or restore backups, the extended attributes that carry these labels often get lost or mismatched. The kernel sees a file labeled user_home_t and a process asking for var_lib_t. The policy says no. The result is a denial, even if the Unix owner and mode look perfect.
Think of it like a party with strict dress codes. Every guest has a badge showing their role. Every room has a sign showing which roles are allowed inside. If you bring a guest from another party, they might have the right key to the door, but their badge says "Kitchen Staff" and the room sign says "Management Only". The bouncer denies entry. Relabeling is the process of reissuing badges to everyone based on where they are standing. It scans every file, checks the path against the policy rules, and stamps the correct label.
Running restorecon recursively on the root filesystem manually is inefficient and risky. It runs while services are active, which can cause transient denials as files are relabeled underfoot. The autorelabel mechanism runs before services start, ensuring a clean state. It is the supported method for full filesystem repairs.
The fix
Create the marker file to tell the init system to run the relabeling daemon on the next boot.
sudo touch /.autorelabel
# Creates the marker file in the root directory.
# The init system checks for this file early in the boot sequence.
# Its presence triggers the full filesystem scan before services start.
Reboot the system immediately. The system detects the file during boot. The init process invokes the relabeling daemon. You will see a message on the console indicating that SELinux is relabeling the filesystem. This process can take several minutes depending on the number of files. On a modern SSD with 500,000 files, expect 5 to 10 minutes. On a spinning disk with millions of files, it can take an hour. Be patient. Do not interrupt the boot.
sudo reboot
# Restarts the system immediately.
# The bootloader hands control to the kernel, which passes to init.
# Init sees /.autorelabel and invokes the relabeling daemon.
The relabeling daemon runs setfiles against the policy file. It walks the filesystem tree and updates the security context of every inode. When it finishes, the system continues the normal boot sequence. The /.autorelabel file is removed automatically. If the file remains after boot, the relabeling failed or was interrupted.
Reboot before you debug. Half the time the symptom is gone.
Verify it worked
Confirm SELinux is enforcing and check a specific file's context.
getenforce
# Prints the current mode: Enforcing, Permissive, or Disabled.
# A successful relabel usually leaves the system in Enforcing mode.
# If it prints Disabled, SELinux was turned off in the bootloader.
ls -Z /etc/passwd
# Shows the security context of the file.
# Look for the type field, like system_u:object_r:etc_t:s0.
# The type must match the policy expectation for that path.
Check the service that was failing. If Apache was refusing to read a config, start it again. If the service starts and the logs are clean, the relabel fixed the issue.
systemctl status httpd
# Shows the current state and recent log lines for the service.
# Look for active (running) and no recent AVC denials.
# Always check status before restarting to see if the unit is already healthy.
Run ls -Z on the failing file before you guess. The context tells the truth.
Common pitfalls and errors
Relabeling resets all contexts to the defaults defined in the policy. If you have custom contexts applied manually, or if you used semanage fcontext to add rules for non-standard paths, relabeling restores those paths to the standard labels. You lose custom work. If you rely on custom contexts, back them up or reapply your semanage rules after the relabel.
If the boot hangs during relabeling, check the journal for filesystem errors or policy issues. Sometimes a corrupted filesystem blocks the scan.
journalctl -b -1 -u systemd-relabel.service
# Shows logs from the previous boot for the relabeling unit.
# Look for errors from setfiles or filesystem read failures.
# The -b -1 flag targets the last boot, which is where the relabel ran.
If you see Error: setfiles failed or Permission denied in the logs, the filesystem might have errors. Run a filesystem check from a rescue environment. SELinux cannot relabel files it cannot read.
Fedora uses the targeted policy by default. Relabeling applies the targeted policy rules. If you switched to minimum or strict, relabeling applies those rules instead. Ensure the policy type matches your expectations.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Relabeling fixes the labels, but manual edits in /usr/lib/ drift and break on package updates.
Snapshot the system before the relabel if you have custom contexts. Future-you will thank you.
When to use this vs alternatives
Use touch /.autorelabel when you need to fix contexts across the entire filesystem after a major migration, backup restore, or partition move.
Use restorecon -Rv /path when only a specific directory has wrong labels and you want to fix it instantly without a reboot.
Use semanage fcontext when you need to add a permanent rule for a non-standard path before running restorecon.
Use setenforce 0 when you are debugging a denial and need to temporarily allow access while you investigate the policy.
Use journalctl -xe when you see a denial and need to read the explanatory text and jump to the end of the log.
Stay on the default targeted policy if you are running standard services. Custom policies drift and break on updates.