The need to recreate secure_chroot_dir in /var/run/vsftpd when not using the supplied init scripts is not documented

Bug #552067 reported by NicoBarbarian on 2010-03-30
This bug affects 1 person
Affects Status Importance Assigned to Milestone
vsftpd (Ubuntu)

Bug Description

Binary package hint: vsftpd

Ubuntu version:
Description: Ubuntu 9.10
Release: 9.10

Version of the vsftpd package:

Description of the problem:

By default, in /etc/vsftpd.conf, the secure_chroot_dir option is set to a directory inside /var/run/ (sorry I can't remember what is the actual directory, I've changed the value in my own vsftpd configuration file).

Even if the directory is created by a post install script, it is deleted each time the system is restarted on default ubuntu configuration since /var/run is mounted as a tmpfs filesystem , i.e. is only existing in RAM and thus is recreated at each startup.

A workaround I've found is to create a directory in any place which is not mounted in a tmpfs filesystem
(By default, tmpfs are used for /dev /dev/shm /var/run /var/lock /lib/init/rw)

Thierry Carrez (ttx) wrote :

I'm not sure why this would be a bug. You change the default secure_chroot_dir to a directory that is under a tmpfs filesystem, so yes, it will be removed at every boot. If you stick with the default, the script will make sure it's created. If you change it (why?), you have to make sure you place it in somewhere that doesn't get cleaned up at every boot (or that you recreate it appropriately). I don't think the init script should parse the vsftpd configuration to cover that corner case ?

Changed in vsftpd (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
NicoBarbarian (nicolas-deherly) wrote :

Actually, the default configuration is fine.

I launch vsftpd with xinetd and do not create the /var/run/vfstpd/empty at startup like it is done by init.d script. Sorry, I didn't check the init script before creating this bug (since I do not use it).

However, a comment in vsftpd.conf file telling that the secure_chroot_dir is referenced in /etc/init.d/vsftpd would be nice.

Chuck Short (zulcss) wrote :

Thanks for the bug report.


Changed in vsftpd (Ubuntu):
importance: Low → Wishlist
status: Incomplete → Confirmed
Robie Basak (racb) on 2014-04-29
summary: - secure_chroot_dir in /var/run/vsftpd disappears each time the system is
- restarted
+ The need to recreate secure_chroot_dir in /var/run/vsftpd when not using
+ the supplied init scripts is not documented
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers