I currently have a WORKING SFTP login, using a private key for login and the user is chroot'ed into their home directory.

Goal: Keep the user chroot but allow WRITE access to the relative chroot directory, without having to specific any path or cd anywhere.

In other words, when the sftp user logs in, I don't want them to have to cd to another path in order to upload a file.

Due to the chroot directory requiring full root ownership (due to chroot design), I'm not certain if this is even possible.

In /etc/passwd:


The users login pubkey is in:


Chroot rules in sshd_confg:

Match User sftpuser
    ChrootDirectory /home/sftpuser
    ForceCommand internal-sftp
    AllowTCPForwarding no
    X11Forwarding no

Home dir permissions:

# ls -l /home/ |grep sftpuser
drwxr-xr-x 5 root      root     4096 May  4 11:24 sftpuser

# ls -l /home/sftpuser/
total 4
drwxrw-r-x 3 sftpuser sftpuser 4096 May  4 11:23 sftp_share

Example current workflow:

Connected to sftp.example.com.
sftp> ls

sftp> put testfile.txt
Uploading testfile.txt to /testfile.txt
remote open("/testfile.txt"): Permission denied

sftp> cd sftp_share

sftp> put testfile.txt
Uploading testfile.txt to /sftp_share/testfile.txt

Desired workflow:

Connected to sftp.example.com.
sftp> put testfile.txt
Uploading testfile.txt to /testfile.txt

Is there any way to allow the upload (put) to the default directory, without having to chdir first?

I do have flexibility to move these directories around. For example, the sftp chroot dir doesn't have to be in the users home directory, I can even change around the users home dir (but the user must still be able to use authorized_keys to login).

Please note: I do understand many SFTP clients, and the command line SFTP client allows for defining a relative path at login. That is out of scope for this question, I'm desiring this config be done server-side and the client simply just needs to login.

2 Answers 2


Hey @emmdee It took me forever to realize there is a simple and nice trick to that. You just have to make root the owner of a parent folder to where you wanna sFTP, then use force command to tell a specific user to load a specific DIR inside the CHROOT directory.

In your case in case you want /home/sftpuser to be the writtable directory, you will have to make root the owner of /home directory then go ahead and Force Command he /sftpuser as a landing directory for that user or a group.

Your /etc/ssh/sshd_conf will look like this:

Match User sftpuser
    ChrootDirectory /home
    ForceCommand internal-sftp -d /sftpuser
    AllowTCPForwarding no
    X11Forwarding no

Once that is done you have to give the right permissions as said earlier, the root should own the parent(chroot) directory /home while the user should own the final(-d) directory /sftpuser. I am goin to assume that you have an sFTP users group called sftpusers, if not; just ommit the group from the next commands or replace it with the users instead (root in the first and sftpusers in the second). As we are using -R in the command line for inheritance, you will have to start with the root ownership before the user ownership as follows:

sudo chown -R root:sftpusers /home

then for the user you can run:

sudo chown -R sftpuser:sftpusers /home/sftpuser

I am not certain that this is needed but you can always restart sshd service to make sure that all settings are reloaded again:

sudo systemctl restart sshd.service

This should work like a charm hopefully, I had a similar problem and the solution was there looking at me in the eyes most of the time.


  • This is cool, but I don't think it exactly solves the question. Maybe it serves his use case, maybe not. I'm looking for this: Goal: Keep the user chroot but allow WRITE access to the relative chroot directory, without having to specific any path or cd anywhere. I've seen this done on a server I'm client on, trying to figure out how to do it.
    – meelash
    Feb 18, 2020 at 22:07
  • May be you did not see it in my answer above, when specifying Force command, add an argument for a landing directory using -d like ForceCommand internal-sftp -d /sftp_share and the SFTP user will not have to cd anywhere, just when they SFTP they land straight in sftp_share folder which is 'writtable' to them. It is by design that SFTP user in Linux cannot write on the chroot. Feb 20, 2020 at 6:56
  • 1
    @AfricanIdiot but if they do cd / won't we be back right to sqaure one? Mar 2, 2020 at 3:16
  • Well, as @Joe suggested later, you will have to use Linux permissions to disable that property. For every sFTP user's home directory make the permissions 600 so that only the chrooted user can read and write that directory, no executing stuff also to avoid nasty behaviors. Mar 13, 2020 at 9:24
  • 1
    You'd still be able to see all the other home directories, even if permissions prevent you from changing into them or listing their contents. If your SFTP server is used for file upload/download with clients, that could be a problem: you might not want your client to know who your other clients are.
    – Frans
    Mar 14, 2022 at 18:16

I know its been a couple of years, but this post got me 98% of the way there. after searching for a long time.

To make it so that I can have users chrooted and automatically get them into their own directory with write permissions I used the method suggested by @African Idiot, and also made the original chroot directory owned by root user and the FTP group.

But the key for me to keep them in that folder and not be able to .. and attempt to browse other users' folders, was to make the folder chmod 710 (rwx--x---) so that the ftp group had execute to do the internal-sftp -d /%u (i.e. cd into the users subdirectory) and now if I attempt to cd .. into the upper directory, because there's no read for anyone but root, it fails.

drwx--x---  6 root        sftpusers   uarch  6 Feb 19 15:34 ./
drwxr-xr-x  5 root        root        uarch  5 Feb  4 09:13 ../
drwxrwx---  3 anotheruser anotheruser uarch  3 Feb 24 15:34 anotheruser/
drwxrwx---  3 ftpuser     ftpuser     uarch 12 Feb 25 10:55 ftpuser/

Hope this helps someone else too.

  • Follow-up question
    – leonheess
    May 6, 2020 at 16:01
  • 1
    You are correct, in my case, because the sFTP user only needs to paste a file or two in my settings, I have given the directories 610 as even the owners are not going to execute anything within the directories. May 21, 2020 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.