The ListOptions directive of ProFTPD can be used to control how directory listings are generated. Directory listings are sent s reason, it is recommended that a non-privileged identity be used. Many sites choose to use user nobody. Historically, this role account was used by NFS-related processes; over time, many other applications default to using user nobody. This has the side-effect of adding to the "privileges" held by user nobody, in terms of files owned and/or accessible by that user. Instead, I personally recommend that a new role account be created for use specifically by the daemon, a user ftpd, and perhaps even a group ftpd. Many systems that run Apache have a user www or user apache for use by the httpd daemon; similarly, a separate user should be created for the proftpd daemon.

In the default configuration file that accompanies the proftpd source code, there appears:

  User nobody
  Group nogroup

Logging in
By default, the proftpd daemon reads the host's /etc/passwd file for logging in users. This means that to add FTP users, you simply need to create new system accounts for those users in your /etc/passwd file.

Sometimes, though, sites want "virtual", FTP-only users. In order to support such configurations, the AuthUserFile configuration directive can be used (see here for details).

For the purpose of authenticating users using other means, there are various authentication modules: mod_sql, mod_ldap, mod_radius, etc. Authentication and the login process is discussed here in more detail.

For setting up anonymous logins, there is the <Anonymous> configuration context. If there are no <Anonymous> sections in your proftpd.conf, then no anonymous logins will be allowed - simple. As mentioned in the description, the User directive in an <Anonymous> context determines what username is treated as an anonymous login. The main other thing to know about anonymous logins is that ProFTPD automatically chroots anonymous logins.

For normal, non-anonymous logins, jails/chroots are configured using the DefaultRoot directive. This is the configuration directive used to restrict users to their home directories, to keep them from browsing around the site. There is a page covering chrooting here.

If you use <VirtualHost> sections, and it seems that your server configuration is not being seen by connecting clients, you might need to check that, if using a DNS name instead of an IP address in your <VirtualHost> line, that name resolves to an IP address different from that of the "default" server. Many people new to ProFTPD get the impression that since the configuration syntax looks similar to Apache's, things like name-based virtual hosting will work as well. Unfortunately, this is not possible. It is not a limitation in ProFTPD, but rather in the RFCs that define FTP. See the virtual server page for more information.

As a workaround, some sites configure virtual servers to run on non-standard ports, using the Port configuration directive. As long as the clients are aware of the non-standard port, this scheme works well. One minor little caveat to keep in mind, when using this approach, is the numbers used: the RFCs mandate that the daemon, for the purposes of active data transfers (as opposed to passive) use port L-1 as the source port for the data connection, where L is the port number at which the client contacted the server. This means that servers that use the stand