Fixing 500 OOPS: vsftpd: refusing to run with writable root inside chroot() on vsftpd

I was informed last night by one of my clients that he could not log into the server via ftp. I was surprised, and immediately blamed the new update (Ubuntu 12.04 LTS). This new update, updates vsftpd to 2.3.5, which tries now to be more secure by not allowing login with writable root directory. This does not affect my user, but if you remember from when we set up the new user, we added a list of users who would chroot() to their home directories. This directories are writable, so vsftpd is not allowing them to login.

The solution, as simple as it sounds, is to revoke writable permissions to this directories. Depending on how you have your system set up, this might not be the best solution for you. In my case it made no much difference. I have the user’s home directory set as wp-content, a directory inside any wordpress installation. My client only needs to be able to upload plugins, so giving him access to only that part of the server seemed like a good idea. The only thing I had to make sure of, is that he were not able to write to that file, so vsftpd would not complain. I did this:

chmod a-w /path/to/wp-content/
chmod u+w /path/to/wp-content/

First we remove write permissions for everybody, then add them only to the owner of the file, which in this case is not my client, but me. If the user you are trying to fix is the owner of the directory, don’t do the second line.

This fixes the problem, and you don’t even have to restart vsftpd.

Some references:

I am a curious person, and this time I got curious about chroot, if you are curious too, read:


4 thoughts on “Fixing 500 OOPS: vsftpd: refusing to run with writable root inside chroot() on vsftpd

    • I think that is also a good solution, but in my case it would not apply, because the structure of the project had to remain the same, so I had to solve it the way I did. However, your solution is a very good one when you have that flexibility.

Comments are closed.