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

After upgrading vsftpd or vsftpd-ext you may be getting the following message when trying to log in.

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

This is due to the following update:

– Add stronger checks for the configuration error of running with a writeable
root directory inside a chroot(). This may bite people who carelessly turned
on chroot_local_user but such is life.

The problem is that your users root directory is writable, which isn’t allowed when using chroot restrictions in the new update.

To fix this you must either remove write permissions on the users root directory with the following command, replacing the directory with your users root:

chmod a-w /home/user

Or you can work around this security check by adding either of the two below into your configuration file.

For the standard vsFTPd build (vsftpd):


For the extended vsFTPd build (vsftpd-ext):


Removing the write permission on the root isn’t a perfect solution as doing this can cause a few problems with things that need to write to the root directory, such as the bash history file or some graphical environments.

Dmitriy has suggested 3 ways to also overcome this problem, be sure to check them out.

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

  1. This solution will then prevent user from uploading any files since they won’t have write access to the directory. How do you solve if the purpose of the FTP access is to allow uploading of files?

  2. It will only prevent uploading files to the users root directory, not any sub-directories. I didn’t have this issue as I don’t write to the root directory but instead have various sub-directories for each website.

    I’m going to assume that this is the only way of working around this unless you compile from source and remove that part of the update yourself.

  3. Thanks. Seems strange to require that a person CD into a subdirectory in order to upload files. I tried setting local_root to something other than the user’s home directory — but that still creates the same error — because after the FTP connection is established it does a chroot() to that new directory. Seems like vsftpd works hard to require a person to explicitly CD into a subdirectory before uploading files. Is this some new FTP security best practice? Or just a vsftpd oddity? I haven’t tried it, but I’m guessing “virtual users” will have the same issue…

  4. I tested this and sure it works.
    But if your users are also allowed to SSH in or otherwise use tools that write files to the root of the users home directory that will fail.
    Like updating history of bash/vi commands etc, like these files:

  5. The only way to get around it currently is to compile vsftpd yourself, unless somebody can come up with a better option because I can’t think of one at the moment.

  6. you can choose one of 3 ways:
    1. Define option local_root= in configuration file. must by /home or other path to directory with users folders.
    In this way vsftpd chrooting to /home directory.

    2. Define option passwd_chroot_enable=yes in configuration file and change in /etc/passwd file user home directory from «/home/user» to «/home/./user» (w/o quotes).
    In this way vsftpd chrooting to /home directory.

    3. Download sources of vsftpd-ext, compile and overwrite exist vsftpd binaries or take it from repositories and add to configuration file option allow_writeable_root=yes.

    1. Little typo in point 3.
      should be:
      This missing e got me mad…

      1. It’s actually correct, the e is not there in the -ext build, strange I know, but thats the way it is.

  7. Very sad behavior of the new vsftpd version, makes it basically unusable because /home/$user directories without write rights for the user are a joke. Defeats the entire purpose of allowing ftp access to the home directories :-(

  8. yes,

    vsftpd started with inetd:
    ftp stream tcp nowait root /usr/local/libexec/vsftpd vsftpd

    force_dot_files=YES (my ip adress)

  9. Oh. I agree with Gerald, very sad behaviour, I cant configure in proper way my ftp server, it`s terrible.

  10. mikel; can’t you add this directive to your conf instead of using “allow_writeable_root”
    Or one of the other options posted by dmitriy?

  11. The only thing you have to do is treat users home as users home and put everything inside a dedicate directory, like the public_html used to accomplish.

    BTW the FreeBSD works like a charm.


    1. I agree with Massimo, the easiest way to deal with this imho is to move everything into a writable subdir, then chmod a-w the root dir. (can be a bit of a pain in the ass for loads of virtual users, but works)

  12. the option chmod a-w /home/user doesn’t work in an graphical environment, since it will prevent system from loading/writing some crucial files.

  13. One tip for anyone having trouble with this:

    At some point during my fooling around, my system (Ubuntu 12.04) stopped looking at /etc/vsftpd.conf–any changes I made were COMPLETELY ignored.

    If that happens to you, copy your config file over to /etc/vsftpd/vsftpd.conf (you’ll probably need to make the directory).

  14. Dmitriy’s #1` suggestion worked perfectly.
    I added the line local_root=/home/wally/Public to the vsftpd.conf file and I ‘connect to server’ in Nautilus using that address location.
    Once there, I bookmark that location and it is not only always there in Nautilus, but also directly from the Unity launcher (using Ubuntu 12.4). by right clicking the file icon. This connects to the Public folder that is installed by default by Ubuntu, but you could point to any other subfolder just as easily… jut not to the home folder itself. Really quick and easy.

  15. cat /etc/vsftpd.conf


    in /etc/vsftpd.chroot_list add user to chroot,
    add “/usr/sbin/nologin” to /etc/shells & add :/usr/sbin/nologin in /etc/passwd

    1. awesome, your solution is work for me (Ubuntu 12.04) almost a day fixing the error :(

      I add


      and add user to /etc/vsftpd.chroot_list

    1. The official reason is “Disallow login with writable root directory because of possible glibc vulnerabilities”

  16. I have a ton of business critical EDI transactions between my customers, and vendors and customers of my customers, all going to and from a bunch of different 24/7 production application servers, The remote people aren’t even my customers but customers of my customes and vendors of my costomers. These countless oddball custom automated procedures have been accumulating for years, and NOW all of the sudden they all break when I update vsftpd or update a whole server, or just install a new server and try to move customers onto it. It’s completely impractical to find all the people on the remote sides and get them to change their scripts and programs to change the paths to use subdirectories, let alone that we’d have to update countless scripts and programs on our side to match.

    Out here in the real world this wonderful thoughtful caring change basically means I have to TURN OFF CHROOT on a bunch of publicly accessible servers…

    Anyways, thanks for the pointer to the -ext fork. Since my boxes are all opensuse and since I already maintain several other special packages in an opensuse build service project, at least I can relatively easily package up that -ext fork and get it distributed and installed and turn chroot back on.

  17. Good News!

    Stock vsftpd 3.0.0 includes a new config option:


    I was in the process of extracting just that option out of the full -ext patches, and discovered that particular feature is already in stock 3.0.0 with a slightly different name than in -ext.

    dev1:oh7:~/src/vsftpd-3.0.0 # grep allow_writeable_chroot *
    Changelog:- Add new config setting “allow_writeable_chroot” to help people in a bit of
    parseconf.c: { “allow_writeable_chroot”, &tunable_allow_writeable_chroot },
    tunables.c:int tunable_allow_writeable_chroot;
    tunables.c: tunable_allow_writeable_chroot = 0;
    tunables.h:extern int tunable_allow_writeable_chroot; /* Allow misconfiguration */
    twoprocess.c: if (!was_anon && tunable_allow_writeable_chroot)
    dev1:oh7:~/src/vsftpd-3.0.0 #

    One thing: I noticed that the 3.0.0 source has a writeable chroot change in twoprocess.c but not in oneprocess.c, while the 2.3.5-ext source has writable chroot changes in both oneprocess.c and twoprocess.c. I have verified that the new option works in the default two-process mode on stock 3.0.0. I have not verified that it works in one-process mode.


    1. Thanks Brian, I’ve updated my post to reflect this new config option, hopefully it’ll give people a few more options to choose from!

  18. I was also trying for hours to setup my 12.04 server access to allow me to upload pages via ftp on the LAN. After clearing the 530 error, I was stuck on the error this thread is addressing. Solution: follow the suggestion #1 of Dmitriy and Massimo. Finally the answer was simple. Place the ftp home directory in a directory which you have removed write permission for. Point to that directory in vsftpd.confi.

  19. @Brian K. White
    I try running vsftpd version 3.0 with allow_writable_chroot=YES and it won’t start. Same behavior with the previous version 2.3.5

  20. >>This may bite people who carelessly turned on chroot_local_user but such is life.

    The above sentence nicely sums up the sheer arrogance of open-source community who obviously believes that if something they produce is free they don’t have any liability when they introduce a breaking change and that we should not assume that next version will work as it did or at all.

    Whoever thought of that change is a shortsighted moron who didn’t think about all possilbe user scenarios out there.

    People posting before me have already commented that this will break even standard Linux use (desktop/shell) so I won’t comment on that further.

    In my case, I have a NAS box at home running Samba and FTP. I do not use my own user home directory in classical Linux way — it exists solely for Samba and FTP. It is completely normal to be able to write to my own root directory. If I can’t write into it, then I cannot create folders. I don’t want anyone forcing me to change my folder hierarchy and have one redundant level added to please someone’s security concerns.

    If there really is a glibc vulnerability which is a reason for this change, why not fix that instead???

  21. Hi!

    I’m trying to compile vsftpd-ext but i can’t:

    /usr/bin/ld: cannot find -lcap
    /usr/bin/ld: cannot find -lpam
    /usr/bin/ld: cannot find -lwrap

    in Ubuntu server 12.04

    Any ideas?


  22. I installed a new ubuntu 12.04 box for our customers transfering their data per ftp to our service.
    At first vsftpd answered any ftp-login with “530 Login incorrect.” after googling and an annoying “apt-get remove vsftpd ; rm /etc/pam.d/vsftpd ; apt-get install vsftpd” a login was possible but we were locked out by “500 OOPS: vsftpd: refusing to run with writable root inside chroot()”

    For me Dmitriys solution #2 workes perfect.
    I added the option passwd_chroot_enable=YES and changed every users home directory from «/home/user» to «/home/./user» (w/o quotes) in /etc/passwd. “vi +’:1,$ s/home/home\/.’ /etc/passwd”
    In this way vsftpd workes as usual.

    But I do not understand what is wrong in using ftp this way – creating users without a shell in etc/passwd and chrooting them to their own home directory without a subfolder, because ftp is the only thing they can do. Maybe someone can give me a hint what I have done wrong using ftp in that way for more than a decade. So I hopefully can set up my ftp boxes accurate.

  23. the first option presented by Dmitriy works, but can i hide the other users folders, since if i have more than one user and set local_root=/home, any user will be able to see and browse the others users home folder?
    or can i set the local_root (or any other option) using environment variables? so i can restrict users to a folder inside they home dir? for instance i would like to set local_root=$HOME/ftp and have the restricted there…

    hope i made myself clear…

  24. The solutions either don’t work (i.e. allow_writable_chroot=YES) or are unacceptable.

  25. Could not get allow_writeable_chroot or use Dmitry’s suggestion of changing the chroot in the vsftpd.conf .

    What worked was disabling write access to the user’s home directory, and adding a folder within (similar to what Hannes has done).

    sudo adduser test
    ##Restrict Shell Access
    sudo usermod test -s /usr/sbin/nologin
    ##Add to ftp allowed list
    sudo nano /etc/vsftpd.userlist
    ##Remove write access to home directory
    sudo chmod u-w /home/test
    ##Make directory “inside” home directory
    sudo mkdir /home/test/inside
    ##Give test ownership of directory
    sudo chown test /home/test/inside
    ## Change group to test
    sudo chgrp test /home/test/inside

  26. I can only support what Igor Levicki said, the only who is acting “carelessly” here is the author of vsftpd:
    A) Introducing breaking changes into a minor software update 2.3.5 is a very bad idea. My vsftpd server neither understands allow_writeable_root, nor allow_writable_root, nor allow_writeable_chroot, nor allow_writable_chroot and that I have to patch and recompile vsftpd to get it working again is supposed to be a joke.
    B) Until today there has been given no justification for this breaking change, except dubious claims about a supposed vulnerability in libc. Please provide some information about this vulnerability and example code how it can be exploited.

  27. Just a note that this issue causes what appear to be ssl problems when you have ssl enabled in vsftpd. An upgrade from opensuse 12.1 to 12.2 caused this problem for me but was hidden behind an ssl_read: wrong version number error when using lftp. To find out that this was the real issue I had to first set enable_ssl=No. After that I got the error above and google led me here. The allow_writeable_chroot=Yes fixed my issues.

  28. My solution… rolling back to 2.0.5. Maybe I’ll look at upgrading again once the author pulls his head outta his ass, thanks.

  29. For me (FreeBSD 9.0 x64) it works with this vsftpd.conf






    Thank Brian K. White; Dimitiy…and al of you

  30. For those of you running Ubuntu 12.04, I have created a vsftpd 2.3.5 PPA that backports the allow_writeable_chroot config option from vsftpd 3 to the existing Ubuntu package. To use it:

    sudo add-apt-repository ppa:thefrontiergroup/vsftpd
    sudo apt-get update
    sudo apt-get install vsftpd

    1. You are wonderful Mark! Thank you, I’ve been attempting to solve this problem for ages!

    2. Hey Mark,

      I know this thread is old and all, but I wanted to thank you for this solution. You’re the knight in shining armor, and I’ll name my firstborn after you, no matter if it’s a boy or a girl. Actually, I’m gonna name ALL my children after you, and all my pets. My cats better get used to being called Mark from now on. I’ll also get an “I <3 Mark" tattoo or something.

      Alternatively, I'll buy you a beer if I ever get the chance. Long story short: you really helped me out, thanks!

    3. Thanks, Mark!

      I did need to add another package in order for add-apt-repository to work:
      sudo apt-get install python-software-properties

      After that your patch installed and worked beautifully!

    4. Thank You,

      it worked for me after installing add-apt-repository (part of python-software-properties, as Daniel mentioned)

  31. Mark, your solution seems good to me.

    I have vsftpd already installed with all the configuration files set up for virtual users. Can you advise as to whether doing another install would lose all my settings.

  32. I don’t know for sure as I’ve only done fresh installs with it. It’s the same as the regular Ubuntu package though, so it should ask you if you want to replace your config files during the update. If you’re unsure, you can always copy them somewhere before you update.

  33. Mark, that works great. Many thanks.

    The config files were left intact, and when I looked at it properly again there was only 2.

    I am using this on my own little web server, but is is set up the same as the one I did at work before retirement. I have always had the ftp user going to the root of his account, as that is where I point Apache to. I am afraid that I cannot quite see the logic in the change that was made to vsftpd. Perhaps I have been doing it wrong for years.

  34. # /usr/local/etc/rc.d/vsftpd restart
    vsftpd not running?
    Starting vsftpd.
    500 OOPS: unrecognised variable in config file: allow_writable_chroot
    /usr/local/etc/rc.d/vsftpd: WARNING: failed to start vsftpd

    pkg_info | grep ftp

    vsftpd-ext- A FTP daemon that aims to be “very secure”. Extended build

  35. Another solution is disabling SELinux this should work and make vsftpd work as usual, none of the solutions in this page worked for me. I am using a CentOS 6.4.
    If you know what you are doing by disabling SELinux then there are no worries, this is how:

    vim /etc/selinux/config

    SELinux turned off for current session
    setenforce 0

    Hope this helps someone. Regards.

  36. Great. I just did as you’ve said, changed the authority mode, and, and it works. Thank you.

  37. Much to our dismay, we recently had to update our Ubuntu server packages. VSFTP is one that got updated. Right now VSFTPD is version 2.3.5-1ubuntu2

    I believe that in order to get the 3.x versions we would need to upgrade the server again to the dist release. Which I would definitely like to avoid since this is a production server getting used 24/7.

    So my question: Does anyone know if it is even possible to get VSFTPD version 2.3.5-1ubuntu2?

    Our users have to be able to upload files, obviously, so this isn’t just an FTP setup for downloading only.

    Some of the fixes mentioned in this post cause the error message to switch to “ECONNREFUSED – Connection refused by server”. The others do not get around the “500 OOPS: vsftpd: refusing to run with writable root inside chroot()”.

    Are we pretty much just screwed if we are stuck with version 2.3.5-1ubuntu2? This is the fourth day I’ve spent working on it and I need to just move on to another FTPD if VSFTD is not supported on this version of Ubuntu server.

  38. Hi all, I have installed vsftpd on ubuntu server 13.10 program which I downloaded
    already that next to install by default ubuntu has a bug to log in if I’m not mistaken the 530 error, well the problem I have is that the vsftpd does not allow internal users to write to its roots by a problem of possible vulnerabilities in glibc, the matter is I a program that requires power to write to the root of the ftp user have installed are a novice in matters of linux and I have read many post to make it work walking to adding a folder under the root where if I can upload and download files as well delete them, but they sell the software I need rights to read and write in the root.

    I tried the option of Marcos but as I mentioned I am newbie in these things and it does not work, if someone could help giving me a step by step guide I’m going to thank me much.

    vsftpd install the program with the following link



  39. Thank you, Dmitriy (January 13, 2012 at 12:51 pm) and the author of the topic, the 1st method is working!

  40. Repost: How to get vsftpd running

    For those of you running Ubuntu 12.04, I have created a vsftpd 2.3.5 PPA that backports the allow_writeable_chroot config option from vsftpd 3 to the existing Ubuntu package. To use it:

    sudo add-apt-repository ppa:thefrontiergroup/vsftpd
    sudo apt-get update
    sudo apt-get install vsftpd


    Cheers Mark!

  41. Geez as if configuration wasn’t enough of a pain. Any suggestions on best practice for FTP for the www directory? I set up home directory of a user to /var/www to enable web site FTP access thru that user. Of course that’s when I came across this issue. The config file change worked for me. Thanks! I just wonder if there is a better way because this has to be a common issue.

    Wow I see this is pretty old now. Hmmm

  42. To access a website’s files via vsftp, I configure apache2 to point to a directory in a user’s home (eg. /home/someguy/public). This way the user owns the files, they’re stored with his files, and no one’s poking around outside the home directory. You do this by editing the config files in /etc/apache2/sites-available.

    Another way to do it might be to create a symlink inside a user’s home directory that points to the /var/www folder.

  43. this is not a bug
    this is not a problem
    this is just:
    it’s preferable to have access system wide then having users jailed to them folders… i want jaill not chroot…

  44. Add me to the list of people thankful for the Frontiergroup’s branch. I’m really disappointed that VSFTPD is not as easy to use as it could be. I agree that the security issue that needs to be addressed is glibc, but if that issue off limits to the VSFTPD developers, then it makes sense for the security-conscious FTP daemon to play it extra cautious. Pain in the ass, just the same, though. Perhaps the minor version should have only enabled the “breaking” behaviour if the insecure version of glibc was present on the machine.

  45. hi,
    i added the following command :
    it still wrong for anonymous user

    i need the root directory writeable for anonymous user ,how should i do ? thank you

  46. Thanks for this post Ben. You saved me, and probably a whole lot of other folks, a bunch of time. It is ridiculous how much vsftp has to be fiddled with. it’s definitely not worth installing on a development machine because it is so unnecessarily “secure.” It’s so secure it’s unusable out of the box!

  47. Dimitry’s option 2 works fine!

    2. Define option passwd_chroot_enable=yes in configuration file and change in /etc/passwd file user home directory from «/home/user» to «/home/./user» (w/o quotes).
    In this way vsftpd chrooting to /home directory.

    1. I didn’t mean to write it like that, but if you’re currently logged in as that user then your solution is better if it works.

Comments are closed.