SFTP Permission Denied? Find Out Which Layer Is Rejecting You

An SFTP Permission denied message can point to an SSH login failure, a remote filesystem restriction, or a server configuration problem. Changing file permissions before identifying which one you have can make things worse—especially on a chrooted SFTP server.

Start with the exact error and when it appears. That usually tells you which layer to investigate.

First, separate authentication from file access

If the message is:

Permission denied (publickey).

SSH authentication failed. SFTP hasn't reached the point where it can read or write a remote file, so changing the remote directory's permissions won't help. Try SSH to the same host and account:

ssh -v user@host

If that fails with the same message, troubleshoot the offered key, username, and server-side key configuration. This SSH public-key authentication troubleshooting guide walks through those checks.

If you can log in over SSH but an upload or directory operation fails, the problem is more likely the target path or the SFTP server's configuration.

Check the path and its permissions

Use SSH to inspect the directory you're trying to write to:

ssh user@host "ls -ld /remote/path"

The output shows the directory's owner, group, and permission bits. For example, a directory owned by root:root with mode 755 can generally be listed by other users, but only its owner can write to it. Being able to see a directory in an SFTP client doesn't mean you can upload into it.

Check these possibilities before changing anything:

• The account doesn't own the directory and isn't a member of its owning group.
• The directory belongs to a service account, such as www-data, nginx, or deploy.
• The path is inside an SFTP chroot, so the path shown to the SFTP user may not match the same path on the server's real filesystem.
• The filesystem is mounted read-only. On Linux, inspect the mount covering the path with findmnt -T /remote/path and look for ro in its options.
• The filesystem is full or the user's quota is exhausted. Check space with df -h /remote/path; if quotas are enabled, quota -s can show the connecting user's quota.

For errors like Couldn't create directory, remote open(...): Permission denied, or Couldn't write to file, the server has typically rejected a file operation. The precise wording varies by client and by which operation failed.

If SSH works but SFTP fails immediately

When SSH login succeeds but SFTP closes, cannot list files, or fails on every operation, look beyond ordinary file permissions. The server might have a problem with its SFTP subsystem, a user- or group-specific Match block, ForceCommand, or ChrootDirectory.

A chroot setup has an important ownership rule: the chroot directory and every directory component leading to it must be owned by root and must not be writable by group or other users. A violation can cause sshd to reject the SFTP session before an upload begins. The server log may contain a message like:

fatal: bad ownership or modes for chroot directory "/srv/sftp/alice"

On a system using systemd, check the SSH service logs with:

journalctl -u sshd

Some distributions name the unit ssh instead. Debian and Ubuntu may also log authentication events to /var/log/auth.log; RHEL-family distributions may use /var/log/secure.

The usual chroot layout keeps the chroot root locked down and gives the user a separate writable directory inside it. For example:

# Keep the chroot root owned by root and not group/other-writable
sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice

# Give the user a writable directory inside the chroot
sudo mkdir /srv/sftp/alice/upload
sudo chown alice:alice /srv/sftp/alice/upload
sudo chmod 700 /srv/sftp/alice/upload

The user writes to /upload from inside the chroot. Don't try to fix a chroot error by making the chroot root writable: sshd may refuse the session for exactly that reason. If you need to inspect the server directives involved, see this guide to editing and validating sshd_config.

Make the narrowest safe change

Avoid chmod 777 as a general fix. It grants every local user read, write, and execute access to the directory, and it can break a chroot's ownership requirements.

Instead, match the change to the access model:

• If the directory should be writable by a group, add the account to that group or grant group write access where appropriate.
• For a directory that should belong to the SFTP user, correct its ownership rather than opening it to everyone.
• For chrooted users, keep the chroot root protected and grant write access only to a suitable subdirectory.
• For recurring deployments, use an account and group with the intended access rather than broadening permissions for an interactive user.

After changing group membership, reconnect before testing: the existing session may not have the new membership.

A quick way to narrow it down

1. Permission denied (publickey) before a file listing? Check SSH authentication.
2. A specific upload or mkdir fails? Inspect that remote directory's owner, group, and permissions.
3. SSH works but SFTP fails immediately or everywhere? Check server logs and the SFTP subsystem, Match rules, ForceCommand, and chroot settings.
4. Permissions look right? Check for a read-only mount, full disk, or quota limit.

The key is to identify which operation failed before changing permissions. A targeted fix protects the rest of the server—and avoids turning a file-transfer problem into an access-control one.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.