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):
allow_writeable_chroot=YES
For the extended vsFTPd build (vsftpd-ext):
allow_writable_chroot=YES
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.
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?
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.
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…
The official reason was for security: “disallow login with writable root directory because of possible glibc vulnerabilities”.
I was looking on the Arch linux forums and I came across a workaround, I’m not sure if this exists on other distributions though:
https://bbs.archlinux.org/viewtopic.php?pid=1038842#p1038842
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:
.bash_history
.bash_logout
.bash_profile
.bashrc
.viminfo
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.
Hello, put up to config file /etc/vsftpd/vsftpd.conf option:
allow_writable_root=YES
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.
Little typo in point 3.
allow_writable_root=yes
should be:
allow_writeable_root=yes
This missing e got me mad…
It’s actually correct, the e is not there in the -ext build, strange I know, but thats the way it is.
what if we dont want that a user see other directories in the /home directory?
Op.2 is working. great thanks!
Point 2 solve my error.
Thank you Dmitriy.
Thanks Dmitriy, I’ve added a comment in the post about your solutions.
Thanks!
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 :-(
In freebsd from ports 3th metod : vsftpd-ext with allow_writable_root=yes not working !
Are you using the latest vsftpd-ext?
For me it works (vsFTPd version 2.3.5+ (ext.1))).
yes, 2.3.5.1
vsftpd started with inetd:
ftp stream tcp nowait root /usr/local/libexec/vsftpd vsftpd
config:
anonymous_enable=NO
local_enable=YES
write_enable=YES
listen_port=21
local_umask=022
anon_upload_enable=NO
anon_mkdir_write_enable=NO
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
hide_file={/mail}.
secure_chroot_dir=/usr/local/share/vsftpd/empty
max_clients=200
max_per_ip=100
chroot_local_user=YES
text_userdb_names=YES
force_dot_files=YES
listen_address=xxx.xxx.xxx.xxx (my ip adress)
allow_writable_root=YES
You could try emailing Dmitriy(the chap that runs the project I believe) for help as I have no idea what could be wrong there. His Email is at the bottom of this page: http://vsftpd.devnet.ru/
Oh. I agree with Gerald, very sad behaviour, I cant configure in proper way my ftp server, it`s terrible.
mikel; can’t you add this directive to your conf instead of using “allow_writeable_root”
local_root=/home
Or one of the other options posted by dmitriy?
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.
Cheers
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)
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.
Option 1 worked for me, thanks
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).
chmod a-w /usr/local/share/vsftpd/empty
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.
in /etc/vsftpd.chroot_list add user to chroot,
add “/usr/sbin/nologin” to /etc/shells & add :/usr/sbin/nologin in /etc/passwd
awesome, your solution is work for me (Ubuntu 12.04) almost a day fixing the error :(
I add
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
and add user to /etc/vsftpd.chroot_list
And why are such restrictions added?
The official reason is “Disallow login with writable root directory because of possible glibc vulnerabilities”
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.
Guys check out this link…
http://serverfault.com/questions/384439/ubuntu-12-04-howto-downgrade-vsftpd/390887#390887
click on the “pool” hyperlink to download the earlier versions of vsftpd…
This works a treat having spent all day invesitigating this problem with 12.04 and the latest devil version of vsftpd 2.3.5!!! Just mysql to sort out now!!! :D
Good News!
Stock vsftpd 3.0.0 includes a new config option:
allow_writeable_chroot=YES
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.
—
bkw
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!
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.
@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
Try using vsftpd-ext instead.
>>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???
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?
Thanks.
You’re missing some libraries/packages. A quick Google turned up this thread which you may need to translate:
http://forum.ubuntuusers.de/post/4552752/
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.
comment this lines, and working,
#chown_uploads=YES
#chown_username=whoever
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…
The solutions either don’t work (i.e. allow_writable_chroot=YES) or are unacceptable.
allow_writeable_root instead of allow_writable_chroot
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
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.
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.
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.
For me (FreeBSD 9.0 x64) it works with this vsftpd.conf
Thank Brian K. White; Dimitiy…and al of you
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:
@Mark
I wanted to say let me know where I can send you a beer! I mean that. I owe you one.
After spending hours on this b.s. problem I finally found your solution and so far it’s testing perfectly and I am compiling a post about it. I encountered this b.s. in setting up a new Rackspace Cloud LEMP box: http://noconformity.com/blog/2013/01/09/rackspace-cloud-setup-ubuntu-12-04-lemp-server/
I hope you have a great start to the year.
@chrishough
Thanks Mark! This is perfect for 12.04.1 LTS
Mark, you’re the man.
This was the only solution I found to work for Ubuntu 12.04.
Thanks very much
You are wonderful Mark! Thank you, I’ve been attempting to solve this problem for ages!
thankyou Mark!
you saved me!
Cappo
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!
You rock, after all that it works !
Thank you Mark! It works perfectly!
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!
Thank You,
it worked for me after installing add-apt-repository (part of python-software-properties, as Daniel mentioned)
Thanks Mark!
Mark,
Many many thanks. You saved my life.
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.
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.
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.
Mark, You sir, deserve an internet.
Thanks a bunch.
Mark, you saved our lives!
# /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-2.3.5.1_1 A FTP daemon that aims to be “very secure”. Extended build
Have you given allow_writeable_chroot a go?
I could only get round this by upgrading to the latest deb package found here
http://us.archive.ubuntu.com/ubuntu/pool/main/v/vsftpd/
Which supports the allow_writeable_chroot=YES flag
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=disabled
SETLOCALDEFS=0
SELinux turned off for current session
setenforce 0
Hope this helps someone. Regards.
Mark, you saved my morning! Thanks!
This whole article + all comments saved not only my morning, but the whole day!
>subscribed<
Great. I just did as you’ve said, changed the authority mode, and, and it works. Thank you.
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.
Upgrading VSFTPD actually worked fine on the Ubuntu dist. Thanks for the help!
The fix was just to install this version:
http://http.us.debian.org/debian/pool/main/v/vsftpd/vsftpd_3.0.2-3_amd64.deb -O vsftpd.deb
After upgrading, the fixes listed on this page worked fine.
Mark – you are the man!!!!!
Working for me on Debian 7 64-bit
wget http://ftp.debian.org/debian/pool/main/v/vsftpd/vsftpd_3.0.2-3_amd64.deb
dpkg -i vsftpd_3.0.2-3_amd64.deb
Then add allow_writeable_chroot=YES to conf
thanks Mark!
Hi all, I have installed vsftpd on ubuntu server 13.10 program which I downloaded
https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/1160372/+attachment/3661388/+files/vsftpd_3.0.2-1ubuntu1_amd64_patched.deb
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
http://www.mclarenx.com/2012/08/10/configurar-vsftpd-y-evitar-los-errores-500-y-530/
regards
Terry
thank you Mark, using your build of vsftpd is still the best solution for 12.04 LTS
Yes.
After a year, still the solution is to use marks repository and add
use
allow_writeable_chroot=YES
Thank you so much Mark
Thank you, Dmitriy (January 13, 2012 at 12:51 pm) and the author of the topic, the 1st method is working!
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
allow_writeable_chroot=YES
—
Cheers Mark!
try –
setsebool -P allow_ftpd_full_access 0
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
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.
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…
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.
Man, I lov ya!!!! Thanks!!! :)
hi,
i added the following command :
allow_writeable_chroot=YES
it still wrong for anonymous user
i need the root directory writeable for anonymous user ,how should i do ? thank you
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!
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.
Thanks! It has worked out perfectly for me!
Did you mean
chmod a-w /home/$USER
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.