Copying folders via SFTP on Ubuntu 24.04 LTS often fails due to strict ownership requirements in the chroot jail configuration. The primary cause is incorrect directory permissions where parent directories are not owned by root, preventing the SFTP subsystem from establishing a secure, isolated environment for the user.
Understanding the ChrootDirectory Requirement
When configuring OpenSSH for SFTP-only access with a chroot jail, security dictates that the target directory and all its ancestors must be owned by
root and not writable by any other user or group. This ensures that the unprivileged SFTP user cannot escape the jail or modify system files. If you attempt to copy a folder into a directory where the parent path has incorrect ownership, the SSH server will reject the request with a permission denied error, even if the specific target folder seems accessible.
Verifying Directory Ownership and Permissions
The most common mistake is setting the data directory as owned by the user while forgetting that the entire path up to the mount point must remain under root control. You need to inspect the ownership of each component in the path using the
ls -ld command. For example, if your chroot is
/home/sftpuser, both
/home and
/home/sftpuser must show
root:root as the owner.
sudo ls -ld /home /home/sftpuser
If the output shows
sftpuser:sftpuser for
/home or
/home/sftpuser, the SFTP connection will fail when trying to write new folders. To fix this, you must change the ownership back to root for the parent directories while allowing the user to write only to their specific subdirectory.
sudo chown root:root /home
sudo chown root:root /home/sftpuser
After securing the parent directories, create a writable subdirectory for the actual file storage. This subdirectory can be owned by the SFTP user.
sudo mkdir /home/sftpuser/data
sudo chown sftpuser:sftpuser /home/sftpuser/data
This structure satisfies the SSH daemon's requirement that the chroot path is immutable by the user, while still providing a functional space for uploading files.
Configuring the SSH Daemon Correctly
Once the filesystem permissions are aligned, you must ensure the SSH configuration points to the correct internal path. In
/etc/ssh/sshd_config, you should define a Match block for the SFTP group or specific user. The
ChrootDirectory directive must reference the top-level directory that is owned by root.
Match Group sftponly
ForceCommand internal-sftp
ChrootDirectory /home/sftpuser
AllowTcpForwarding no
X11Forwarding no
Notice that
ChrootDirectory is set to
/home/sftpuser. Inside the chroot, the user will see this directory as the root (
/). Therefore, when they try to copy a folder, they are effectively writing to
/data inside the jail, which maps to
/home/sftpuser/data on the host system. If you previously set
ChrootDirectory to
/home, the user would have no writable space because
/home itself is owned by root.
Restart the SSH service to apply these changes.
sudo systemctl restart sshd
Testing Folder Copy Operations
With the permissions and configuration corrected, test the SFTP connection using an SFTP client or the command line. Attempt to upload a folder containing multiple files. If the operation succeeds, the issue was indeed related to the chroot ownership hierarchy. If it still fails, check the system logs for detailed error messages.
sudo tail -f /var/log/auth.log
Look for lines indicating "fatal: bad ownership" or "ChrootDirectory path does not exist." These logs will confirm whether the SSH daemon is rejecting the connection due to permission violations. Ensure that SELinux or AppArmor policies are not interfering, although standard Ubuntu installations usually rely on POSIX permissions for this specific SFTP restriction.
For users experiencing broader connectivity issues after changing network configurations, you might find similar troubleshooting steps useful in our guide on
Ubuntu 22.04 VM on KVM/virt-manager Not Connecting to Internet, as network stack changes can sometimes impact SSH stability.
Frequently Asked Questions
Why can I log in but cannot create folders?
You can log in because authentication succeeds, but folder creation fails because the directory you are trying to write to is not writable by your user. In a chroot setup, the root of the jail must be owned by root, so you must create a subdirectory within it that is owned by you.
Can I use a different user instead of root for the chroot path?
No, the ChrootDirectory and all its parent directories must be owned by root. This is a strict security requirement of OpenSSH to prevent privilege escalation. Allowing non-root ownership would let the user modify the jail boundary.
How do I check if my SSH config is valid?
Run
sudo sshd -t to test the configuration syntax. This command will return an error message if there are invalid directives or conflicting settings before you restart the service.
What if I get permission denied on existing files?
Check the permissions of the specific file or folder you are trying to modify. Even if the directory is writable, individual files may have restrictive permissions like
600 or
400 that prevent modification by the owner or group.
Does this affect FTP clients or only SFTP?
This configuration specifically affects SFTP connections handled by the SSH daemon. Traditional FTP servers like vsftpd have different configuration methods and do not use the OpenSSH chroot mechanism, so their permission models are independent of this setup.