I am using the File Server appliance as a SFTP server. I set up the root directory for SFTP with ChrootDirectory to /srv/ftp/ From there I have the home directories (/srv/ftp/UserX). The problem is that when UserX logs in, he is directed to root directory (aka /srv/ftp) rather than its own home. Therefore every user has to do a "cd /UserX" after logs in, so they can up/down files. Setting ChrootDirectory to "/srv/ftp/%u" or "/%h" gives errors on the client side. Is there any way I can set it up so every user hits his own home directory at login? Please help. Thank you.
Jeremy Davis's picture

In my experience users should automatically log in to their home directory. It sounds as though you have setup a chroot for all your users rather than one for each. Perhaps that's got something to do with it? Perhaps better to put all your users in their own and create a shared one for anything you want them all to have access to.

There is some handy info re SFTP and FTPing with TKL in the forums. This post is probably a good start.

Jeremy, thank you for answering. My goal is to keep users completely isolated from each other.

I found a workaround, not really a fix. Here's what happens:

"/srv/ftp" folder had root:root as owners and "/srv/ftp/UserX" subfolders had their respective users as owners. You cannot use ChrootDirectory for UserX folder unless UserX is owned by root. 

WORKAROUND: I created a "data" subfolder in each UserX folder and I changed owners like this: 

/srv/ftp/UserX -> owner=root

/srv/ftp/UserX/data -> owner=UserX

Also I changed the ChrootDirectory to /srv/ftp/%u and now users see only their home folder as root folder. However, they can only read/write files in "/srv/ftp/UserX/data" subfolder and not in their /srv/ftp/UserX home folder.

It seems like there is no real fix for that because of how ChrootDirectory directive works. If you have better solution, please let me know.

Thanks again.

Jeremy Davis's picture

Now that you mention I recall others speaking of the issue with users home directory needing to be owned by root for the chroot gaol (jail) to work and I don't recall any way around that.

But just a thought (not sure if it'd work). What if root owned the home directory but the group ownership was that same as the user (ie make each user their own group). Then if you allow the group to have full read/write access... Perhaps worth a try...

Thanks Jeremy,

That might actually work and I am going to try it for the sake of it... But in the long run I don't think I want that administration overhead. We're talking tens of users...

Thanks again

Jeremy Davis's picture

I'd be interested to hear if it does work. If it does, you could write yourself a little script to do all the tedious bits so setup wouldn't be that hard I wouldn't think.

I tested it and it's NOT working: as soon as you give write rights to a group (any group) it gives an error. (ie changing rights from 755 to 775 on home directory).

It is weird - could be a bug - but that's the behaviour.

So I'm still looking for solutions or fixes.


Jeremy Davis's picture

Oh well. That's a pity. One more thought (while I'm throwing them around). What about changing the users home directory down a level once it's setup eg you said that you can make a folder within the original home writable by the user, how bout reset their home to this directory? Again I'm, not sure it'd work, in fact quite possibly it won't but worth a try.

One other thing, for the record. If you are only using this as a SFTP file server and aren't using the other functionality (eg Samba, eXtplorer, etc) then you don't need the fileserver appliance. Even just Core would do what you want, and have a smaller resource footprint. Core (and all other appliances) has SFTP enabled by default. You could then install vsftpd and use FTPS (FTP over SSL - instead of SFTP) and hopefully get the behaviour you are looking for without so much mucking around. Fileserver appliance has vsftp bound to localhost to provide the backend for the FTP component of eXtplorer.

I tried that before and it works. Yet, the only benefit is that users are thrown in that subfolder at ssh login. They will still be able to navigate one level up where they don't have write rights.

I'd like to keep Samba for "internal" users so they don't have to SFTP when they work "inside the network". I'll keep in mind your advice though.

Thanks again.

Jeremy Davis's picture

Thanks for posting...

I hadn't considered this issue for a long time, but your point makes perfect sense! Of course he needs to have access to / to go to his user dir /tom. and if you are chrooting, then /srv/ftp is the chroot (/ to Tom)!

Great work and thanks tons for sharing! :)

Add new comment