Chapter 4. Common Running problems

1. ProFTPD doesn't seem to work.
2. "inet_create_connection() failed: Operation not permitted".
3. Unable to bind to port/Address already in use
4. "(Login failed): Invalid shell"
5. "Fatal: Socket operation on non-socket"
6. "Fatal: unable to determine IP address of "hostname:
7. I'm having problems with FTP clients behind firewalls
8. Can I run more that one VirtualHost on a single IP?
9. How do I run ProFTPD from inetd?
10. Can I use tcp-wrappers with ProFTPD?
11. Can I run an FTP server on a non-standard port?
12. Can control upload/download ratios?
13. Slow logins
14. Lots of "FTP session closed" messages
15. How do I see who is connected?
16. Can I force ProFTPD to listen on only one IP?
17. "FTP server shut down ... please try again later."
18. How do I shutdown the server without killing proftpd?
19. Is is possible to shutdown a single VirtualHost?
20. How do I restart/reload the server?
21. 503 No PORT command issued
22. Fatal: unable to determine IP address of
23. 451 append/restart not permitted, try again
24. 501 REST not compatible with server configuration
25. The time being displayed is wrong
26. Corrupted files
27. Can I upgrade ProFTPD without terminating the current sessions?
28. No such group "nogroup"
29. Why do I see "unable to set groups: Invalid argument"?

1. ProFTPD doesn't seem to work.

Starting ProFTPD in standalone mode it doesn't show in "ps" It could be many things, possibly something like not running ProFTPD as root (it needs to be run as root initially, but will switch to a non-privileged user). Regardless, ProFTPD logs all errors via the standard syslog mechanism. You need to check your system logs in order to determine what the problem is.

It doesn't work!

There are many times when there's a completely random problem which appears to be insoluble. The best place to ask for help is definately the mailing list (proftpd-l) but it's not productive to ask for help without giving enough information for intelligent debugging.

Have you?

  • Checked your logs

  • Tried the server in debug mode

  • Read the FAQ?

  • Checked the mailing list archive?

  • Are you running the latest version?

When posting try giving enough information, this might include but not be limited to.

  • OS and server version (proftpd -vv)

  • List of included modules (proftpd -l)

  • Appropriate log extracts

  • Output fom debug mode

  • Configration fragment

2. "inet_create_connection() failed: Operation not permitted".

You aren't starting ProFTPD as root, or you have inetd configured to run ProFTPD as a user other than root. The ProFTPD daemon must be started as root in order to bind to tcp ports lower than 1024, or to open your shadow password file when authenticating users. The daemon switches uid/gids to the user and group specified by the User/Group directives during normal operation, so a "ps" will show it running as the user you specified.

3. Unable to bind to port/Address already in use

0.0.0.0 is INADDR_ANY, which means to bind to any interface. The "address in use" will normally mean that something has already bound to that address.

Under linux it is possible to run:

fuser -n tcp 21
            

to get the PID of the process currently bound to port ProFTPD is configured to run as.

The most common cause is that ProFTPD is configured standalone and inetd is still configured for port 21. Comment out the line starting "ftp" in /etc/inetd.conf and restart (killall -HUP inetd or something similar should do the trick) and try again.

4. "(Login failed): Invalid shell"

The user attempting to login has been given a shell that is not listed in the system's /etc/shells file. By default, proftpd will require that users logging in have valid shells. Use the RequireValidShell directive to turn off this requirement:

RequireValidShell off
	    

5. "Fatal: Socket operation on non-socket"

You have ProFTPD configured to run in inetd mode rather than standalone. In this mode, ProFTPD expects that it will be run from the inetd super-server, which implies that stdin/stdout will be sockets instead of terminals. As a result, socket operations will fail and the above error will be printed. If you wish to run ProFTPD from the shell, in standalone mode, you'll need to modify your proftpd.conf configuration file and add or edit the ServerType directive to read:

ServerType standalone
            

6. "Fatal: unable to determine IP address of "hostname:

The hosting machine has a poorly configured hostname setup to the point where the resolver library cannot determine the IP from the name. Solutions include, fixing the DNS for the domain, fixing the hostname, fixing the /etc/hosts file. Which one works for you will largely depend on your OS and exactly what is wrong.

7. I'm having problems with FTP clients behind firewalls

The FTP Specification defines that two sockets should be used for all communications. The first runs over port 21 and is the control channel over which all commands and response codes are sent. Whenever data is required to be transfered, for example for a file download, a directory listing etc etc. A second channel is created on demand, this socket can take one of two forms.

non-Passive

The server end of the data socket uses port 20. This is nice and easy to work into a firewall configuration.

Passive

The port at either end is dynamically allocated. This is virtually impossible to cater for in a firewall configuration given that the port mapping will be different for every data connection.

The solution is to force the users to configure their clients to use the non-passive mode (ie port 20)

8. Can I run more that one VirtualHost on a single IP?

No, or at least not in the HTTP/1.1 manner of virtual hosting. This is an inbuilt limitation of the current FTP RFC., unlike the HTTP/1.1 spec there is no mechanism comparable to the "Host: foo.bar.com" HTTP header for specifying which host the connection is for. Therefore the only method for determining which VirtualHost the connection is destined for is by the destination IP.

The one exception to this is if you host multiple servers on the same IP but using different ports, however this requires that the connecting client uses a non-standard port and therefore is probably not a good solution for mass hosting.

Is there anything in the pipeline to fix this?

There is a draft standard http://search.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-12.txt with the IETF which extends and improves on the FTP specification including support for a HOST command. However given that the IP crunch is coming from websites and not virtual ftp servers this is unlikely to be pushed through any time soon.

9. How do I run ProFTPD from inetd?

Find the line in /etc/inetd.conf that looks something like this:

ftp stream tcp nowait root in.ftpd in.ftpd

Replace it with:

ftp stream tcp nowait root in.proftpd in.proftpd

Then, find your inetd process in the process listing and send it the SIGHUP signal so that it will rehash and reconfigure itself. You may also need to add in.ProFTPD to hosts.allow on your system.

10. Can I use tcp-wrappers with ProFTPD?

Yup. Although ProFTPD has built-in IP access control (see the Deny and Allow directives), many admins choose to consolidate IP access control in one place via in.tcpd. Just configure ProFTPD to run from inetd as any other tcp-wrapper wrapped daemon and add the appropriate lines to hosts.allow/deny files.

If running ProFTPD in standalone mode, mod_wrap can be used to direct the server to use the normal hosts.allow/deny files.

11. Can I run an FTP server on a non-standard port?

Yes. Use a <VirtualHost> block with your machine's FQDN (Fully Qualified Domain Name) or IP address, and a Port directive inside the <VirtualHost> block. For example, if your host is named "myhost.mydomain.com" and you want to run an additional FTP server on port 2001, you would:

...
<VirtualHost myhost.mydomain.com>
Port 2001
...
</VirtualHost>
            

12. Can control upload/download ratios?

Yes the mod_ratio module provides for doing just this.

The ratio directives take four numbers: file ratio, initial file credit, byte ratio, and initial byte credit. Setting either ratio to 0 disables that check.

The directives are HostRatio (matches FQDN, wildcards allowed), AnonRatio (matches password entered at login), UserRatio (accepts "*" for "any user"), and GroupRatio.

Ratios on                                    # enable module
UserRatio ftp 0 0 0 0
HostRatio master.debian.org 0 0 0 0          # leech access (default)
GroupRatio proftpd 100 10 5 100000           # 100:1 files, 10 file cred 5:1 bytes, 100k byte cred
AnonRatio billg@microsoft.com 1 0 1 0        # 1:1 ratio, no credits
UserRatio * 5 5 5 50000                      # special default case
              

This example is for someone who (1) has downloaded 1 file of 82k, (2) has uploaded nothing, (3) has a ratio of 5:1 files and 5:1 bytes, (4) has 4 files and 17k credit remaining, and (5) is now changing directory to /art/nudes/young/carla. The initial credit, not shown, was 5 files and 100k (UserRatio * 5 5 5 100000).

Version 2.0 and above of this module integrate with mod_sql.

Limitations of mod_ratio

It appears that the ratio limits in mod_ratio are only maintained on a per session basis and there is no ongoing tracking of usage.

13. Slow logins

This is probably caused by a firewall or DNS timeout. By default ProFTPD will try to do both DNS and ident lookups against the incoming connection. If these are blocked or excessively delayed a slower than normal login will result. To turn off DNS and ident use:

UseReverseDNS off
IdentLookups                    off
            

IdentLookups and tcpwrappers ***

14. Lots of "FTP session closed" messages

Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed. Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed. Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed. Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed.

The above log extract is likely to be caused by a local monitoring system or a particularly aggressive DoS attack. Most service monitoring systems try opening the ftp port on the target server to detect whether it is active and running. Most of the time these tests are followed by an immediate "QUIT" or disconnection.

TCPdump/TCPshow on the server in question should show which machine on your network is is generating these connections.

15. How do I see who is connected?

The ftpwho command lists the state of each ftp connection to the server and what it's current activity is. However this does not detail the connection information on a virtual by virtual basis.

16. Can I force ProFTPD to listen on only one IP?

Sort, of it's not quite as clean as the socket binding under Apache but the principle works something like this.

Standalone mode

To listen on the primary IP of a host use the SocketBindTight directive

To listen on a interfaces which are not the primary host interface use the SocketBindTight directive, place your server configuration in a <VirtualHost ftp.mydomain.com> block and use "Port 0" for the main host configuration and and "Port 21" inside the VirtualHost block.

inetd

There are two approaches possible, the first is to use the patch from Daniel Roesen <droesen@entire-systems.com> (check the mailing list archives).

The second method is to run ProFTPD from xinetd (http://synack.net/xinetd/), a more advanced replacement of inetd. An entry for this in xinetd.conf would be something like this:

service ftp
{
        disable = no
        flags			= REUSE
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/proftpd
        log_on_success          += DURATION USERID
        log_on_failure          += USERID
        nice                    = 10
	#bind			= [IP to bind to]
}
            

17. "FTP server shut down ... please try again later."

Check for /etc/shutmsg and delete it.

18. How do I shutdown the server without killing proftpd?

ftpshut, allows the server to disallow connections with a message without actually taking down the service. The shutdown can be scheduled for a point in the future or right now, existing connections can be allowed to finish, or be terminated now. Re-enabling is done by removing the /etc/shutmsg file.

19. Is is possible to shutdown a single VirtualHost?

No, the shutmsg file works at a daemon level not at a virtual host level.

20. How do I restart/reload the server?

This depends on the mode you're running the server in.

inetd

Unless you're making a configuration change to inetd itself nothing needs doing. The server reloads the configuration everytime a new connection is made.

Standalone

Either stop and start the server completely (a little aggressive for most admins tastes) or send a SIGHUP to the master daemon process.

21. 503 No PORT command issued

A bug was introduced in 1.2.0rc2 which prevented the PORT command working properly and therefore breaking the data socket under certain conditions. The bug was documented as bug 240 and has been fixed in CVS. A rc3 release is due before the end of Jan 2001.

22. Fatal: unable to determine IP address of

Proftpd was unable to work out what IP is associated with the hostname in the VirtualHost block. Normally caused by a problem with the DNS resolution of the host, check the resolv.conf file and that your chosen nameservers are functional.

23. 451 append/restart not permitted, try again

AllowStoreRestart is disabled by default because it will allow any writable file to be corrupted by a malicious user. It is recommended that this option is only used with authenticated users and then only in certain directories.

24. 501 REST not compatible with server configuration

As mentioned in the description of the HiddenStores configuration directive, use of that directive is incompatible with the FTP command REST. Either disable use of REST with the AllowRetrieveRestart and AllowStoreRestart directives, or do not use HiddenStores.

25. The time being displayed is wrong

The default behaviour for ProFTPD is to display all times relative to GMT. To use local time set "TimesGMT off" in the server section of the config. There is a known issue with Redhat 7, with regard to time handling. http://www.redhat.com/support/errata/rh7-errata-bugfixes.html

26. Corrupted files

There appear to be some problems with both the use of sendfile() in ProFTPD and with the implementation within certain operating systems.

27. Can I upgrade ProFTPD without terminating the current sessions?

Short answer, no. Longer answer is no, but you can minimise the effects. The cleanest approach on servers which have significant amounts of traffic appears to be to use ftpshut to block new connections and terminate existing ones after a pre-determined time period and then to upgrade and restart. This approach limits the number of downloads which are terminated part way through.

28. No such group "nogroup"

The default ProFTPD configuration file uses the user "nouser" and the group "nogroup", some systems / distributions do not have the group "nogroup" defined. The solution is to either add the group "nogroup" to /etc/groups or to change the "nogroup" entry in the proftpd.conf to a group which does exist.

29. Why do I see "unable to set groups: Invalid argument"?

The setting of the group privileges for a process uses the setgroups(2) system call. This call will fail with the above error message for one of two reasons: there is a negative GID value for one of the groups, or the maximum number of groups for a single user has been exceeded.

Ideally, all IDs, both UID and GID, will be positive. Unfortunately, it is common on many systems to use -1 or -2, especially for such users as 'nobody', or group 'nogroup'. Use of these values uses C's treatment of data types to make the actual numeric value very high; some functions, like setgroups(), do not like this, though. In general, always use positive ID numbers.

The other limitation is the number of supplemental groups for a user (eg non-primary groups, the ones configured in /etc/group). The maximum number of supplemental groups to which a user may belong is defined by the operating system constant NGROUPS_MAX. On some operating systems, such as Solaris, this limitation may be tunable.

Some other applications may not encounter this error if they use the initgroups(3) function, which reads the /etc/group file for a user's supplemental group memberships, and sets those groups. This function, however, silently ignores any supplemental groups for user greater than NGROUPS_MAX, unlike setgroups(2), which complains.

If this is the cause of your error message, any solution will most likely involve reducing the number of groups your users are members of, or tuning the NGROUPS_MAX value, if your operating system allows it.