[root@tst-01 home]# ls -Z
drwxr-xr-x. ujjain   users          system_u:object_r:home_root_t:s0 ujjain
drwxr-xr-x. johndoe   users          system_u:object_r:home_root_t:s0 johndoe

The selinux context should be object_r:user_home_dir_t.

[root@tst-01 ~]# sesearch -T -t home_root_t
Found 10 semantic te rules:
   type_transition oddjob_mkhomedir_t home_root_t : dir user_home_dir_t;
   type_transition automount_t home_root_t : dir automount_tmp_t;
   type_transition lsassd_t home_root_t : dir user_home_dir_t;
   type_transition useradd_t home_root_t : dir user_home_dir_t;
   type_transition firstboot_t home_root_t : dir user_home_dir_t;
   type_transition smbd_t home_root_t : dir user_home_dir_t;
   type_transition quota_t home_root_t : file quota_db_t;
   type_transition sysadm_t home_root_t : dir user_home_dir_t;
   type_transition cups_pdf_t home_root_t : dir user_home_dir_t;
   type_transition postfix_virtual_t home_root_t : dir user_home_dir_t;

[root@tst-01 ~]# 

New home-directories are created with the wrong Selinux context. I can fix the selinux context with chcon, but this creates problems on multiple servers.

What can be the reason the context was set wrong in the first place?

  • 1
    What does sesearch -T -t home_root_t say?
    – Nathan C
    Commented Jul 9, 2013 at 13:22
  • I added the output as a comment!
    – ujjain
    Commented Jul 9, 2013 at 13:58

3 Answers 3


Adding to this question for future people who may come across it. If you are putting home directories on an NFS share, you will need to set the correct SELinux context. Assuming your nfs home directory is /nfshome, do the following:

[root@host /]# semanage fcontext -a -e /home /nfshome
[root@host /]# restorecon -vR /nfshome
  • Thank you, this is exactly what I needed. This should be a FAQ for any home directory not in /home/ (e.g. mine were in /data/). Commented Feb 13, 2017 at 16:40
  • This worked for me -- the first semanage ... line marks the /nfshome directory as having the same selinux context as the standard /home directory, and the second line verbosely and Recursively restores the security contexts of the /nfshome directory. I used it on a non-nfs /local/home dir. What I liked about it was not having to determine and explicitly set the contexts, but I just matched the contexts of a working, existing dir.
    – Dave X
    Commented Jul 9, 2018 at 22:48

In the case of user's $HOME directories, usually in /home/$USER, you don't need to use chcon, which changes the security context of files and directories, in the sense of diverting them from the policy, and, for what is worth, won't survive a system relabel. Rather, you need to find out what is the expected security context of the directories:

# matchpathcon /home/ujjain
# matchpathcon /home/johndoe

And if the context doesn't match the output of ls -lrtZ, restore the context:

# restorecon -v /home/ujjain
# restorecon -v /home/johndoe

Note that restorecon can be used recursively -R.

Regarding your question, the reason why this directories have a wrong label depends on the procedure used to create them (which you didn't specify) and the location of the /home directory (local filesystem vs. NFS, for example)


The issue appears to be here:

[root@tst-01 ~]# grep homedir /etc/pam.d/system-auth
session     optional      pam_mkhomedir.so skel=/etc/skel

Since the pam stack should not be making homedirs, the odd job module should be used to do the heavy lifting instead with the pam_oddjob_mkhomedir module since it requires fewer permissions and works well with SELinux.

  • 1
    Looks like a bug. Be sure to report it in BZ. Commented Jul 22, 2013 at 21:01
  • 1
    Yes, pam_mkhomedir does not make home directories with the correct SELinux contexts. This is confirmed by Red Hat and their recommendation is using pam_oddjob_mkhomedir.
    – ujjain
    Commented Jul 23, 2013 at 7:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .