How to Fix SFTP Permission Denied and Upload Errors

Separate login errors from file-operation errors

If the password or key is rejected, the user has not authenticated. If directory listing works but upload, delete or rename is denied, authentication succeeded and the file system or SFTP policy blocked that operation.

Record the exact operation and remote path. If the same account can write to another directory, the problem is probably specific to the destination rather than the whole account.

Common causes of SFTP permission denied

Client-side checks

1. 1
   Verify the remote path

   A displayed path can differ from the real server path inside a chroot; confirm the current remote directory.

2. 2
   Try a simple test file

   A small file with a safe name separates permission problems from size and naming rules.

3. 3
   Test an allowed directory

   Compare with a known upload or home subdirectory assigned to the account.

4. 4
   Inspect the connection log

   Identify the failed SFTP request and the status message returned by the server.

Check ownership and permissions on Linux

Creating a file requires appropriate access on the parent directory, not just the file itself. Check the user’s effective groups and every directory component along the path.

Applying 777 can hide the actual ownership problem and let unrelated users change data. Set the intended owner and group, then grant only the permissions required by the workflow.

id user
ls -ld /srv/sftp /srv/sftp/upload
namei -l /srv/sftp/upload

Why might ChrootDirectory be non-writable?

OpenSSH applies strict ownership and writability rules to a chroot jail root. A common safe layout uses a root-owned chroot directory with a separate upload directory beneath it that the SFTP user can write to.

Making the jail root writable by the user can cause login to fail entirely. Create a writable child directory instead of weakening the chroot root and grant access only to the intended account.

Server-side checklist