
Stock vsftpd 3.0.0 includes a new config option: 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. 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…Īnyways, thanks for the pointer to the -ext fork. 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.


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. 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. Author Ben Posted on JanuJCategories Linux Tags 500 oops, chroot, vsftpd 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.ĭmitriy has suggested 3 ways to also overcome this problem, be sure to check them out. Or you can work around this security check by adding either of the two below into your configuration file.įor the extended vsFTPd build (vsftpd-ext): 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: The problem is that your users root directory is writable, which isn’t allowed when using chroot restrictions in the new update. This may bite people who carelessly turned


– Add stronger checks for the configuration error of running with a writeable After upgrading vsftpd or vsftpd-ext you may be getting the following message when trying to log in.ĥ00 OOPS: vsftpd: refusing to run with writable root inside chroot ()
