Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have configured sshd_conf on my centos box as below:

Match group pilots
ChrootDirectory /home/pilots
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no

and the directory /home/pilots like this:

# ls -al /home/pilots
total 12
drwxr-x---. 3 root pilots 4096 Mar 10 14:20 .
drwxr-xr-x. 7 root root     4096 Mar 10 14:10 ..
drwxrwxr-x. 2 root pilots 4096 Mar 10 15:21 data
-rwxrwxrwx. 1 root root        0 Mar 10 14:20 topLevel

If I sftp in as a user in the pilots group WITHOUT the ChrootDirectory Directive enabled, I can cd to the /home/pilots folder (or a subdirectory thereof) and do a ls or get without difficulty. However, if I enable the ChrootDirectory directive, while I can still sftp in, and can cd to data, I can not do a ls or get in either directory. Trying ls, for example, gives a remote readdir("/"): Permission denied error, and trying to get topLevel gives File "/topLevel" not found. I was thinking maybe I wasn't in the directory I was expecting, but the ability to cd data would appear to indicate the chroot did work as intended.

looking at the messages log, I see the following when the ls is denied:

type=1400 audit(1394494944.504:50): avc:  denied  { read } for  pid=22758 comm="sshd" name="pilots" dev=dm-0 ino=400504 scontext=unconfined_u:system_r:chroot_user_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=dir

So there's a record of the denial. Still doesn't tell me why though.

What might I be doing wrong?

Couple of potentially important notes:

  • The users in question exist on a remote LDAP server, accessed via sssd
  • Access control must be by group, as many users will need read access to this same folder. Thus the ownership remaining root.

Edit: On further investigation, it appears this is related to SELinux - doing an echo 0 >/selinux/enforce fixes the issue, albeit in a kludgy, killing an ant with a sledgehammer kind of way. If possible, I'd like to know the "proper" fix.

share|improve this question
up vote 2 down vote accepted

I found the solution on this page. To summarize, after configuring sftp as per the above configuration, the following two commands needed to be run to allow access with SELinux enabled:

setsebool -P ssh_chroot_rw_homedirs on
restorecon -R /home/$USERNAME

In this case, the second command would be restorecon -R /home/pilots. After this, sftp works as expected, even when chrooted, without having to disable SELinux completely.

share|improve this answer
Unfortunately, this didn't work for me; but disabling SELinux allows it to work. – Matthew Moisen Apr 13 at 5:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.