How to fix fatal: bad ownership or modes for chroot directory in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 405 views

OpenSSH rejects the chroot directory because it has incorrect ownership or permissions. The directory must be owned by root and not writable by group or other users, for security reasons.

Quick fix

Fixes SSHD_CHROOT_PERMISSION

ls -ld /path/to/chroot
ls -ld /path/to
ls -ld /path
ls -ld /
  1. Check current ownership and permissions
  2. Set correct ownership on the chroot directory
  3. Set correct permissions on the chroot directory
  4. Fix parent directories if needed
ssh — error
ls -ld /path/to/chroot
ls -ld /path/to
ls -ld /path
ls -ld /
fatal: bad ownership or modes for chroot directory

What this error means

When SSHD is configured with ChrootDirectory to jail SFTP or SSH users, OpenSSH performs strict security checks on the chroot directory and its parent directories. If ownership or permission bits don't match OpenSSH's strict requirements, the connection fails immediately with this error. This is a deliberate security restriction to prevent privilege escalation attacks through chroot jails.

Typical symptoms

  • SFTP/SSH login fails immediately with no password prompt
  • Client sees 'Connection reset by peer' or 'Broken pipe' error
  • Server logs show 'fatal: bad ownership or modes for chroot directory'
  • Error message may specify the exact problematic directory in the path
  • Users with non-chrooted accounts connect normally, only chrooted users fail

Common causes

  1. The chroot directory is owned by a user other than root
  2. Parent directories in the path are owned by non-root users
  3. The chroot directory has world-writable permissions (e.g., 777 or 775)
  4. The chroot directory has group-writable permissions when it shouldn't
  5. The chroot directory has incorrect group ownership (not root/wheel)

How to fix "fatal: bad ownership or modes for chroot directory"

1Check current ownership and permissions

First, examine the current state of your chroot directory and its parent path:

bash
ls -ld /path/to/chroot
ls -ld /path/to
ls -ld /path
ls -ld /

Look for any directories that aren't owned by root or have write permissions for group/other users. The output should show:

bash
drwxr-xr-x  root  root

If you see permissions like drwxrwx--- or drwxrwxr-x or group ownership other than root/wheel, that's the problem.

2Set correct ownership on the chroot directory

Change the chroot directory to be owned by root:root (or root:wheel on BSD systems):

bash
sudo chown root:root /path/to/chroot

For example, if your chroot is /home/sftpuser:

bash
sudo chown root:root /home/sftpuser
3Set correct permissions on the chroot directory

Remove all write permissions for group and other users. The chroot directory must have exactly 755 permissions:

bash
sudo chmod 755 /path/to/chroot

This sets:
- Owner (root): read, write, execute (rwx)
- Group: read, execute only (r-x)
- Other: read, execute only (r-x)

Verify with:

bash
ls -ld /path/to/chroot

Should show: drwxr-xr-x

4Fix parent directories if needed

OpenSSH checks the entire path from root to the chroot directory. Each parent directory must also be owned by root and not writable by group/other:

bash
sudo chown root:root /path/to
sudo chmod 755 /path/to

Repeat for each directory in the path. For most systems, /, /home, /var, etc. should already be correct, but check if you're using custom paths.

5Create writable subdirectories for the user inside chroot

Users need a place to write files inside the chroot. Create a subdirectory owned by the user:

bash
sudo mkdir -p /path/to/chroot/upload
sudo chown sftpuser:sftpuser /path/to/chroot/upload
sudo chmod 755 /path/to/chroot/upload

The user will only be able to write to subdirectories they own, not to the chroot root itself. This is the expected and secure behavior.

6Reload SSH and test the connection

After fixing ownership and permissions, reload the SSH daemon (be careful not to lock yourself out):

bash
sudo sshd -t

If the test passes, reload:

bash
sudo systemctl reload ssh
# or on some systems:
sudo systemctl reload sshd

Then test the SFTP connection from a client:

bash
sftp sftpuser@yourserver

You should now get a password prompt and be able to connect.

Advanced notes

Why is OpenSSH so strict about chroot ownership? If a non-root user owned the chroot directory, they could modify files within it (including binaries or configuration for internal-sftp), potentially leading to privilege escalation. By requiring root ownership and read-only permissions for non-root users, OpenSSH ensures the chroot jail cannot be tampered with from within.

On BSD systems, the group may be 'wheel' instead of 'root', but the principle is the same: the directory must be owned by root and not writable by others.

If using 'internal-sftp' (recommended), ensure your sshd_config has: ForceCommand internal-sftp in the Match block. This avoids needing shell binaries in the chroot.

Frequently asked questions

What does "SSHD_CHROOT_PERMISSION" mean?
When SSHD is configured with ChrootDirectory to jail SFTP or SSH users, OpenSSH performs strict security checks on the chroot directory and its parent directories. If ownership or permission bits don't match OpenSSH's strict requirements, the connection fails immediately with this error. This is a deliberate security restriction to prevent privilege escalation attacks through chroot jails.
How do I fix "SSHD_CHROOT_PERMISSION"?
OpenSSH rejects the chroot directory because it has incorrect ownership or permissions. The directory must be owned by root and not writable by group or other users, for security reasons.
What causes "SSHD_CHROOT_PERMISSION"?
The chroot directory is owned by a user other than root Parent directories in the path are owned by non-root users The chroot directory has world-writable permissions (e.g., 777 or 775)
Is the "SSHD_CHROOT_PERMISSION" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading