How to Fix “SFTP fatal: bad ownership or modes for chroot directory” in Ubuntu 12.04


2 views

The error message fatal: bad ownership or modes for chroot directory "/home/DUMP" occurs when the SSH daemon detects improper permissions on your chroot directory. This is a security measure to prevent directory traversal vulnerabilities in SFTP configurations.

For SFTP chroot to work properly, the chroot directory and all its parent directories must:

  • Be owned by root
  • Not be writable by any other user or group
  • Have strict permission settings (typically 755)

Your current DUMP directory has problematic permissions:

drwxrwxrwx  5 root     root      4096 aug 18 02:25 DUMP

The 777 permissions (represented by rwxrwxrwx) are too permissive for a chroot directory.

Here's how to fix the permissions:

sudo chown root:root /home/DUMP
sudo chmod 755 /home/DUMP

For directories inside DUMP that users need to access:

sudo mkdir -p /home/DUMP/High\ Definition
sudo chown magnarp:sftponly /home/DUMP/High\ Definition
sudo chmod 770 /home/DUMP/High\ Definition

If you need more flexibility, consider this alternative sshd_config setup:

Subsystem sftp internal-sftp

Match group sftponly
    ChrootDirectory /home/%u
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

Then set up each user's home directory with proper permissions:

sudo mkdir -p /home/magnarp/DUMP
sudo chown root:root /home/magnarp
sudo chmod 755 /home/magnarp
sudo chown magnarp:sftponly /home/magnarp/DUMP
sudo chmod 770 /home/magnarp/DUMP

If issues persist:

  • Check SELinux status with sestatus
  • Verify all parent directory permissions up to /home
  • Test with verbose logging: sudo /usr/sbin/sshd -d

When configuring SFTP with chroot on Ubuntu 12.04 (and newer versions), you may encounter the frustrating error:

fatal: bad ownership or modes for chroot directory "/home/DUMP"

This typically occurs when the directory ownership and permissions don't meet OpenSSH's strict security requirements for chroot environments.

OpenSSH enforces these mandatory conditions for chroot directories:

1. The directory must be owned by root (uid 0)
2. The directory cannot be writable by group/others
3. No parent directory can be writable by group/others
4. The directory must have 755 permissions (drwxr-xr-x)

Your current DUMP directory has problematic permissions:

drwxrwxrwx  5 root     root      4096 aug 18 02:25 DUMP

The 777 permissions (rwx for everyone) violate requirement #2. Additionally, symbolic links in chroot environments have special considerations we'll address later.

# Fix directory ownership and permissions
sudo chown root:root /home/DUMP
sudo chmod 755 /home/DUMP

# Set correct permissions for subdirectories that users need to access
sudo mkdir /home/DUMP/user_files
sudo chown magnarp:sftponly /home/DUMP/user_files
sudo chmod 770 /home/DUMP/user_files

For your specific case with the "High Definition" directory, instead of symlinks (which have security implications in chroot), consider:

# Option 1: Bind mount (more secure than symlinks)
sudo mkdir /home/DUMP/High\ Definition
sudo mount --bind /home/DUMP/High\ Definition /home/magnarp/High\ Definition

# Option 2: Configure additional chroot directory
Match group sftponly
    ChrootDirectory /home/DUMP:/home/magnarp
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

Here's a verified working configuration for your sshd_config:

Subsystem sftp internal-sftp

Match group sftponly
    ChrootDirectory /home/%u:/home/DUMP
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

# For system-wide chroot to /home/DUMP:
Match group sftponly
    ChrootDirectory /home/DUMP
    # Required for proper directory traversal
    AuthorizedKeysFile /home/DUMP/%u/.ssh/authorized_keys
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

If issues persist:

1. Check SELinux/AppArmor status (may need adjustments)
2. Verify all parent directory permissions up to /
3. Test with verbose SSH logging: ssh -vvv user@host
4. Check auth.log for detailed error messages