SELinux Context Relabeling Fails After Restorecon

Linux & Unix Intermediate 👁 6 views 📅 Jun 30, 2026

When relabeling files with restorecon, it fails silently or errors out. Usually happens after a system update or untarring files. Here's why and how to fix it.

You run restorecon -Rv /some/directory and it either does nothing (no errors, but files keep wrong labels) or spits out filespec_add: selabel_lookup failed. This usually happens after a system update that changed SELinux policy, or after you untarred a bunch of files from a different system. I've seen this exact thing on RHEL 8, CentOS 7, and Ubuntu 20.04 with SELinux enabled.

Root Cause

The culprit here is almost always that the file context database — the map that tells restorecon what label each file should get — is missing entries for new files or old files moved from a different system. If you untarred files from a non-SELinux system (like a backup from a BSD box or a Windows share), those files arrive with no SELinux context at all. Or, after a policy update, some default contexts changed but the database didn't refresh. Restorecon can't relabel what it doesn't know about.

Step-by-Step Fix

  1. Check current contexts. Run ls -Z /path/to/broken/files. Look for unconfined_u:object_r:default_t or system_u:object_r:unlabeled_t. Those are your problem files.
  2. Update the file context database. Run sudo setfiles -F /etc/selinux/targeted/contexts/files/file_contexts. This rebuilds the internal database from the policy. Don't skip this step.
  3. Now try restorecon again. Run sudo restorecon -Rv /path/to/directory. Watch for errors like selabel_lookup failed. If you see that, you have files with no matching rule.
  4. Fix missing rules with semanage. For files that still fail, you need to add a context rule manually. Example: if you have a file in /opt/customapp that should be httpd_sys_content_t, run sudo semanage fcontext -a -t httpd_sys_content_t "/opt/customapp(/.*)?". Then run restorecon -Rv /opt/customapp again.
  5. If still broken, force relabel on reboot. Create a file called /.autorelabel with sudo touch /.autorelabel and reboot. The init system will relabel everything on next boot. This catches cases where the database itself is inconsistent.

What to Check If It Still Fails

If you followed all that and it's still not working, check these three things:

  • Is SELinux actually enforcing? Run getenforce. If it says Disabled, you need to enable it in /etc/selinux/config and reboot. Restorecon does nothing when SELinux is off.
  • Are you using the right policy type? Run sestatus and check the policy version. If you're on mls but your files are from a targeted system, contexts won't match. Switch to targeted in the config file.
  • Is the filesystem mounted with context options? Check mount output. If you see context= in the mount options, it overrides everything. Remove that from /etc/fstab and remount.

One last thing: if you're running on a VM with shared folders (like VirtualBox shared folders), SELinux doesn't apply to those at all — they use the host's labels. Don't bother with restorecon there. Just set the context in the VM's local filesystem.

"I've spent hours on this. Now you don't have to." — Marcus

Was this solution helpful?