Frequently Asked Questions about wu-ftpd, with answers
This article contains the answers to Frequently Asked Questions (FAQ)
concerning the wu-ftpd software. To ask questions about wu-ftpd, subscribe
to the mailinglist and ask there. If you wish to get
the latest version of this file, it is available as
This is the FAQ (frequently asked questions) for newer versions of
WU-FTPD as maintained at ftp.wu-ftpd.org. This document is an addition
to the man-pages of WU-FTPD which are part of the installation and available
online as
<URL:http://www.wu-ftpd.org/man/>.
Answer number one is:
Update to the latest version (at this moment: 2.6.2). A lot
of problems have been fixed, including security problems.
Note: The various addresses used in this document are for contacting
the authors on subjects mentioned in this document. Using these
addresses for sending unsolicited Email is forbidden.
Again: please update to the latest version for security purposes!
This document (and WU-FTPD in general) need a general knowledge of Unix
system management aimed at the Unix version you are trying to install
WU-FTPD on. Subjects like user management, password management,
file-system management, changing access settings and chroot environments
are prerequisite knowledge.
Reviews of books about Unix in general (and other books) on
The Virtual Bookcase at <URL:http://www.virtualbookcase.com/>
Wuarchive-ftpd, more affectionately known as WU-FTPD, is a
replacement ftp daemon for Unix systems developed at Washington
University (*.wustl.edu) by Chris Myers and later by Bryan D. O'Connor
(who are no longer working on it or supporting it!).
WU-FTPD is the
most popular ftp daemon on the Internet, used on many anonymous
ftp sites all around the world.
Users of WU-FTPD are encouraged to switch to the mailing lists hosted
at wu-ftpd.org. The following lists are available :
wuftpd-announce
Announcements concerning WU-FTPD. This is the ONLY announcement list for
WU-FTPD. The list is open subscription, only members of the WU-FTPD
Development Group may post. Traffic on this list is very low. Traffic
should be signed using the development group's PGP signing key.
wuftpd-dev
General discussion list for developers. The list is open subscription,
only subscribed users may post. Traffic on this list is generally low, but
can be high occasionally.
wuftpd-doc
General discussion list for documentation writers. The list is open
subscription, only subscribed members may post. Traffic on this list is
generally low but can be high occasionally.
wuftpd-questions
General support and discussion. This is the list to use if you have
questions concerning compiling, installing or configuring WU-FTPD.
The list is open subscription. Anyone may post. Traffic on this list is
generally high (although there are some medium-traffic days occasionally).
To subscribe, send a mail message to
Majordomo@wu-ftpd.org with a
body of
The lists from wu-ftpd.org are available via Anonymous IMAP. Connect
to mail.wu-ftpd.org using IMAP (TCP port 143) and give 'anonymous' as your
username and your e-mail address as password. If your mail client cannot
see the folder list, give the listname to access that lists archive.
The original WU-FTPD home is wuarchive.wustl.edu, but at this moment wuarchive
no longer supports or maintains WU-FTPD.
The correct location at this moment for WU-FTPD releases is
ftp://ftp.wu-ftpd.org/pub/wu-ftpd/ (please use a real ftp client to access this).
The WU-FTPD development group maintains WU-FTPD and makes the latest version
available at ftp.wu-ftpd.org in
ftp://ftp.wu-ftpd.org/pub/wu-ftpd/ (please use ftp to access this).
This version of WU-FTPD is now actively maintained by the WU-FTPD Development
Group, reachable by email as
(wuftpd-dev@wu-ftpd.org).
The VR-series offered a number of enhancements and bug fixes not available
in the base version. The VR patches have been integrated in WU-FTPD 2.5.0
and the will not be available from ftp.vr.net after the end of August 1999.
BeroFTPD was a derivative of WU-FTPD with extra functionality for
virtual hosts. Patches from the VR versions were included.
The enhancements from BeroFTPD are now incorporated into the main daemon.
Since WU-FTPD 2.6.0, GNU autoconf is introduced, but it is still in experimental
stage. So first try ./configure and if that fails try the old method:
In general, editing src/pathnames.h and typing build arch
should be enough.
This error is fully explained in the INSTALL/INSTALL.orig file in wu-ftpd
package.
A few relevant lines :
If cc complains about strunames, typenames, modenames, ... being undefined
you need to install support/ftp.h as /usr/include/arpa/ftp.h (always make
a backup of the old ftp.h just in case!) and do the build again. The new
ftp.h should be a compatible superset of your existing ftp.h, so you
shouldn't have problems with this replacement.
Upgrade to version 2.6.2 or later. They automatically use shadow passwords
when available. If this gives problems, you might want to upgrade your Linux.
For older versions:
Since older Linux distributions (around libc.5.3 this got fixed)
don't include shadow passwords,
WU-FTPD might assume your Linux does not have shadow passwords. To compile for
shadow passwords with Linux when this happens :
Get the shadow.h from the latest shadow package.
After building the shadow package, you have a libshadow.a.
Copy shadow.h to the src dir.
Copy libshadow.a to the support dir.
Edit src/config.h to say '#define SHADOW_PASSWORD' instead of #undef.
Edit the LIBES line in src/Makefile to read : LIBES = -lsupport -lbsd -lshadow (for some releases, -lcrypt is
also needed)
Either, you compiled with support for setting the process title
(SPT_TYPE) on a machine that doesn't support this, where changing the
process title clobbers the environment and therefore zaps the TZ
variable. Recompile with SPT_TYPE set to SPT_NONE.
Systems which don't support SPT_TYPE : Aix, SGI Irix
Or, you need to copy the zoneinfo files to the ~ftp tree too. These are :
The name of the correct file in /usr/share/lib/zoneinfo depends
on your current timezone. Exact filenames depend on your operating system
too.
See the man-pages for timezone(4) and zic(1M).
See above, but also check if your system needs /etc/default/init (Solaris 2.5
for example) for setting the correct TZ variable. This file has to be in
chrooted environments too.
The makefile is setup for the bsd version of the install program. Some OS'es
(including Solaris) use the svr4 version. In that case set in the makefile :
INSTALL = /usr/ucb/install
Upgrade to version 2.6.2 or later. If you are not using C2 security,
you may need to change the definitions for SHADOW_PASSWORD and
HPUX_10_TRUSTED.
Some kernel configuration may be required to allow more heavy load on
lock files and multiple access to the same file. This can all be done
through SAM. An important thing to keep in mind on a heavily accessed
machine is that the fin_wait state needs to be lowered enough to keep
open file locks at a minimum.
/usr/include/shadow.h: This *system* file had an apparent typo that caused
gcc to fail. I changed the following statement:
extern int lckpwdf(void),
to
extern int lckpwdf(void); <<--- note the ';'
realpath.c: I think there was a external reference (maybe more than 1
reference?) which did not match the internal declaration. I think I
changed the realpath declaration to match the externals. I deleted the
original sources so I don't recall the change exactly.
ftpcmd.c: This file results from ftpcmd.y (via yacc/bison). Unfortunately
the resulting c code will not build. It was necessary to move 2 of the
structures to an earlier section. I think it was the 'cmdtab[]' and
'sitetab[]' structures which were moved. They were being called prior to
their declaration. (`what bison` gives $Revision: 1.2 $)
Makefile.hpx: Modified to not delete the ftpcmd.c file fixed above.
ftpd.c: 1) installed the shadow password patch per the instructions in the
FAQ. The new code worked without any problems (I'll probably port it to
the POP3 server I've been wanting to install). 2) Modified the sprintf
calls near SEPPROCTITLE to include "wuftpd" in the process string (similar
to hp-ux ftpd). this allows "ps -ef | grep ftp" to show all connected ftp
processes. It might need a little doctoring up since the file names on
RETR have ^M^J tacked on.
Extra remark: On a trusted system HP's getpwnam does not supply the encrypted
password. Instead you have to use getprpwnam. Modify ftpd.c to use getprpwnam.
A complete set of installation notes for WU-FTPD on HP-UX 10.20:
This section is written by someone else who wishes to remain unnamed.
I installed wu-ftp2.4 on a clean HPUX 10.20 build. The 10.20 build came
straight from HP, and the only important differences on this build from
a generic build is that the X-libs and X-utils were stripped out
(something I would recommend if you are building an HP 10.20 for ftp
only).
- Get both the wu-ftp2.4 package and the current ansi-c compiler
package (I got mine from HP, you can request the package
ansic.hp-10.20.tar.gz)
- Uncompress and untar the C package first (HP comes with a standard c
compiler, but it is only useful in the kernel compiling and doesn't
function well outside of doing kernel work).
Follow the README/INSTALL docs for installing the c compiler. Make sure
you put this new compiler in your path, or do some editing whenever you
use cc to point to this compiler and not the default.
- Build WU-FTPD normally
- Set up the server
- Special notes about tuning for heavy load:
The ftp servers that I maintain are heavily hit and some kernel
configuration was required to allow more heavy load on lock files and
multiple access to the same file. This was all done through SAM. An
important thing to keep in mind on a heavily accessed machine is that
the fin_wait state needs to be lowered enough to keep open file locks
at a minimum. I set all of my fin_waits to 5 minutes or less.
At this moment, IPv6 support is not available in WU-FTPD from the WU-FTPD
Development Group. But, there is hope, the Kame project makes a patchset
available for IPv6 support under BSD and Linux. More info at the Kame
project homepage:
<URL:http://www.kame.net/>
Edit the Makefile for your OS to add the AFS libs/includes. They only
appear in the Makefile for AIX. After that add the following line to the
#include section of src/ftpd.c :
The general SKEY procedure is something like this:
The last thing in config.h is an #undef SKEY; comment that out. That is
a gotcha that can take some time to find, although that doesn't seem to
be the problem.
Copy skey.h into the src directory.
Copy libskey.a into the support directory.
Edit the appropriate Makefile.* in src/makefiles and add the following:
add "-DSKEY" to the CFLAGS macro;
add "-lskey" to the LIBES macro.
That should do it; if not, holler back.
In general, change the line for the ftp-server in /etc/inetd.conf (the
file that defines the servers started by inetd. For some operating systems,
this is another file).
With the latest versions, using no command-line options will set it to a
default-mode, in which it will not parse the ftpaccess file. Add
the option -a to the command line in inetd.conf.
This can be done from the command line or with a special definition in
/etc/services / /etc/inetd.conf. For command-line, look up -P and
-p in the ftpaccess(5) manpage.
To set up with special definitions, add 2 ports with
consecutive numbers in /etc/services, and then start WU-FTPD on these
ports. Add to /etc/services something like :
ftptest 4021/tcp #command port
ftptest-data 4020/tcp #data port
The key is the name 'ftptest' which associates the port assignment
in the /etc/services file to that in the inetd.conf file. Make
certain the choice of ports in /etc/services (4021 and 4020 above)
are from the local use list and don't conflict with other port
assignments (see RFC1700, ASSIGNED NUMBERS). One important
subtlety. The data port is not really derived from the data port
declaration in the /etc/services file. The FTP specification
(RFC765) states the data port is defined as one less than the
command port. However, including the data port declaration in the
/etc/services file prevents it from being accidentally assigned to
something else.
Unpack the tar into an empty directory which will then have a subdirectory
named WUFtpd262
Do not enter this directory, but type 'pkgadd -d .', you will get
something like:
# pkgadd -d .
The following packages are available:
1 WUFtpd262 wu-ftpd 2.6.2 SPARC/ULTRAsparc 2.5.1 - 2.5
(sun4c,sun4d,sun4e,sun4m,sun4u,sun4u1) 2.6.2
Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:
Redhat 7 and above use xinetd instead of inetd. Use chkconfig wu-ftpd on
or edit /etc/xinetd.d/ftp to enable
the service (it is disabled by default even when WU-FTPD is installed).
Redhat 8 automatically puts every user in their homedir using the guestuser
directive. Comment this out if you want to be able to browse the entire
system.
The original version of WU-FTPD had a year 2000 representation
problem in the handling of the MDTM (modification time of file) command.
No internal workings of WU-FTPD were affected by this problem.
This problem has been fixed in WU-FTPD 2.4.2 beta 14 which was
published August 1997. With this fix, WU-FTPD is believed to be completely
Y2K-compliant.
The fix that was applied :
The following statement appears in ftpcmd.y. It is part of
the action for the syntax: MDTM check_login SP pathname CRLF
When the anonymous user is logged in, bannerfiles are opened relative to
the root of the anonymous user. Keep this in mind. It can be usefull to
have 2 sets of banners or use links.
This is a format consisting of day and time parameters. Possible items :
Sa,Su,Mo, .. Any (for any day) and time parameters. For example :
SaSu|Any1800-0700 means all of Saturday and Sunday or Any
day between 18:00 and 07:00. Check if ftpd inherits the correct time zone.
All counts and maximums depend on which class the user is in, and the
class is unknown before login (since WU-FTPD takes
realuser/anonymous/guestuser as a variable for calculating which class
a user is in).
For different operating systems, different libraries and/or devices are
needed. You can test if things are running correctly by doing a chroot
to the ftp homedir. To test if /bin/ls is working in the ~ftp dir, type :
First, have a look at the manpage for the original in.ftpd(1m).
It has a scipt for setting everything up. If the filesystem with ~ftp is
mounted -nosuid, the special device files will not work.
Solaris needs ~ftp/dev/tcp and ~ftp/dev/zero and the libraries. Check
the man-page for your Solaris version for exact details. Use the
command ldd to find out which libraries a program uses. Also,
the ~ftp/etc/group file is needed for ls to work, without it it will
just dump core. Follow the same rules as for /etc/passwd : not too much
information in that file, like group passwords (if you have those).
Needed libraries can include :
ld.so, ld.so.1, libc.so.1, libdl.so.1, libintl.so.1, libmp.so.1, libnsl.so.1,
libsocket.so.1, libw.so.1, nss_compat.so.1, nss_dns.so.1, nss_files.so.1,
nss_nis.so.1, nss_nisplus.so.1, straddr.so
Use the command ldd to find out which libraries a program uses.
Create ~ftp/dev/null and ~ftp/dev/zero.
You will need the ELF file loader, ld-linux.so in ~ftp/lib.
Copy the static version of ls (/sbin/ls) and not the dynamic one. The static
version is about 400K.
Make passwd and group files in ~ftp/etc. Copy from /etc/sia
dir to ~ftp/etc/sia the files matrixconf and
siainitgood.
To stop seeing what libraries are needed unset the environment variables:
csh# unsetenv _RLD_PATH
csh# unsetenv _RLD_ARGS
Useful information on Irix also in the IRIX Insight Library (Online Books)
in the book/chapter "IRIX Admin: Networking and Mail" in the paragraph
"How to Set Up a Proper Anonymous FTP Account".
This is a very sneaky one. To quote : The problem was that ls_short and
ls_long were being defined incorrectly (since the system was compiled with
a BSDish compiler, the BSD config file was used) using ls -lA and ls -lgA
respectively. It turns out that the ls command was running but it was
erroring out (this is because the system is actually running SVR4), since
a failed ls produces output only to stderr not stdout I saw nothing for
my output.
Something in the upgrade changed in your OS. Most likely : newer shared
libraries. Also : other major/minor numbers in /dev. Redo the shared libs
and devices after an upgrade if things like the above happen.
There are a lot of possible reasons, mostly having to do with the fact that
some versions tar use different command line parameters.
Solaris 2.4 : if you use Solaris tar, and give the commandline as
/bin/tar -cf - %s, the effect will be the same as /bin/tar
-cvf - %s. The -v option will add extraneous data to the
stream. Solution : replace it with /bin/tar cf - %s (no leading -).
Also, check your 'tar' and 'compress' directives in ftpaccess.
With Solaris 2.4 and GNU's tar-1.11.8 (configured and compiled with
--disable-nls flag) use the GNU tar flag
--use-compress-program=path to compression program
Create a shell for this purpose (for example, a program that says the above
or a copy of /bin/true). Put this shell in
/etc/shells. Change the shell of the user to that shell. Next : make sure mail cannot be delivered locally to the account. Using
the fact that the shell is valid for sendmail (it is in /etc/shells)
a user can be able to start commands as that user.
Somebody is trying to misuse your ftp-site for transferring software
(worst case scenario). Check if the directive path-filter in
the ftpaccess file is something like :
In general: you don't want this. But, if you're stubborn...
Read the upload.configuration.HOWTO, pointer at the beginning of this faq.
Make very sure that you have the latest version of WU-FTPD (2.6.2), set your path-filter to the one mentioned above. Make the
incoming directory owned by something else than ftp (root, or nobody)
with another group then ftp (nobody). Something like :
drwx-wx-wt root nobody incoming
This will allow ftp to write in the directory, but not read it.
Set the upload directive in ftpaccess to something like :
One note : files get created as root and changed to the owner mentioned
in the upload line. This will fail on some secure NFS setups. Best solution
is to mount the /incoming separately.
Unlimited subdirectory creation has been prohibited as this has been
the source of problems with WU-FTPD. You will need to explicitely allow
a certain amount of levels of subdirs, like for example:
upload /home/test /home/test/public_html yes test users 0664 dirs 0775
upload /home/test /home/test/public_html/* yes test users 0664 dirs 0775
upload /home/test /home/test/public_html/*/* yes test users 0664 dirs 0775
upload /home/test /home/test/public_html/*/*/* yes test users 0664 dirs 0775
The default umask is inherited from inetd. This can be a wrong one.
There is a command line parameter -u. Edit the line in
inetd.conf to something like ftpd -A -L -l -u077.
I (Koos van den Hout) also wrote a Perl script to process the log, mail daily
statistics and uploaded files, and create a top most downloaded files. It
is available from
<URL:ftp://ftp.cetis.hvu.nl/pub/koos/ftplogcheck>
Apparantly ftpd needs write permission on ~ftp/dev/tcp in order to operate
correctly in passive mode (Solaris). Set it to the same mode as permissions
shown by ls -lL /dev/tcp,
being 666. Also read the Solaris man page for ftpd for Solaris-specific
information. Changed from previous versions
Symbolic links in Unix are relative to your active root. If you want
to access
files/directories/diskspace outside your chrooted environment, you'll have to
import it using directory loopback mounts (available on at least
Solaris) or using NFS mounts (available on most other operating systems
but they have a performance impact).
This is a feature of inetd, not ftpd. Inetd will limit the amount of connections
that can be made to a service per minute. Some versions allow to specify this
amount in inetd.conf, by specifying it in the nowait flag, like :
ftp stream tcp nowait.256 root /usr/sbin/ftpd ftpd -a
which will allow 256 connections per minute. Check the manpage for inetd.
Tuning for a large site is mostly OS tuning since WU-FTPD fully depends on
the OS to do things like file-caching and tcp-tuning. If your traffic is
more than what can flow easily over a 100 Mbit card maybe you should look
into bonding multiple 100 Mbit networks together or go ATM or gigabit
ethernet.
WU-FTPD is now default suited for running on a large site. The patches
mentioned below have been included per default.
DAEMON
If ftpd called with -D then run as a standalone daemon listing on the
ftp port. This can speed up ftpd response as all ftpd then needs to
do is fork off a copy to handle an incoming request. Under inetd
a new copy has to be opened and exec'd.
FILEWHAT
If SETPROCTITLE doesn't work or if you have so many users that ps
takes a long time then FILEWHAT keeps the info in a file so that
ftpcount can just print it.
This is actually a bug in very old ftp-clients which only send the first 8
characters because the password is limited to 8 characters anyway. Upgrade
your client.
At this moment this is only possible with one IP number for each ftp server.
So called 'name based virtual hosting' is inherently impossible with the
current FTP protocol.
WU-FTPD 2.6.0 supports this in a somewhat limited extent, BeroFTPD supports it
somewhat better, but read the catch:
There is a draft for an extension to the ftp protocol named HOST to support virtual hosts like HTTP. But, this is a draft and there are a lot
of old ftp clients out there. So do not count on using this.
Did you look in the system log? The daemon will log the reason for the
failure there. It helps a lot to know why.
Most plausible (at the moment) you're upgrading to the latest version and, if
you'd look, the syslog says 'not in any class'.
That means you're using the old, unsafe wildcards on your class
statements such as the following:
class lcl real,guest,anonymous 127.*.*.*
The latest versions don't support this notation for security reasons.
Use netmask or CIDR instead, as in either of the following:
class lcl real,guest,anonymous 127.0.0.0/8 or
class lcl real,guest,anonymous 127.0.0.0:255.0.0.0.
Most probable reason: in inetd.conf the ftp server gets started using
tcpd (tcp_wrappers) which fails a security check. Look in the logfiles
given from syslog.conf which check fails.
Possible causes:
IDENT (RFC931) lookup is enabled in WU-FTPD. This has a timeout of 10 seconds.
If the protocol (port 113) gets blocked by a firewall or suchlike, it will
wait for timeout. If it is 30 seconds and you are using Redhat >= 7 with xinetd,
disable AUTH in inetd as well. Change the entries in /etc/xinetd.d/ftp that
read:
Some ftp clients improperly use the NLST and LIST commands. NLST was
intended to show files only for retrieval using the mget command. LIST
was intended to show everything in human-readable form. Earlier
versions of WU-FTPD did not correctly interpret the RFC which
defines these commands and many ftp clients were written incorrectly
and do not use the definitions in the RFC.
Starting WU-FTPD 2.6.0, the interpretation of NLST versus LIST ftp
commands has been changed to what is the right interpretation. NLST
lists retrievable files for the ftp mget command, LIST lists all files
for a human reader. Suggested fix: fix the client software, or train
the users to use ls -l (or dir) in a command-line client to get a listing
of the files and directories.
Starting WU-FTPD 2.6.0, the FTP RFC has been implemented in a stricter way,
which breaks some clients. Most visible clients are mirror and squid. More
information on which clients and how to update them at
<URL:http://www.wu-ftpd.org/broken-clients.html>
Inetd counts the number of connection occuring within a minute. If
that number exceeds some threshold, is assumes the ftp service is
broken (or under attack) and keeps getting restarted - and shuts down
the service. In most systems, this can be overcome by adding a
parameter to the inetd.conf file like .... nowait.400 (400
connections per minute). Check the specific syntax for your operating
system.
Solaris uses nscd to cache certain information. With 'nscd -i passwd' the
cache will be refreshed. You can also have a look at the manpage for nscd
on how to change this behaviour.
Since the correct way to resume a download is not standardized, it depends
on the interaction between server and client. The way that it is usually
implemented is supported by WU-FTPD.
You can't. Binary or Ascii transfer is purely a choice of the client in the
ftp protocol. Some clients switch to binary mode automatically at startup,
but that is purely their choice and not governed by the server.
Firewall the device from the Internet and if possible from
network (most embedded devices should not be reachable from the
Internet anyway). After that start bugging the vendor for an update
pointing the vendor towards the website for WU-FTPD at <URL:http://www.wu-ftpd.org/>.
And of course, Chris Myers and Bryan O'Connor at Washington University
who wrote WU-FTPD
in the first place. Warning : Both are no longer working on WU-FTPD, or
even working at Washington University. Please don't mail them with questions.
The development team prefers context-diffs against the lastest version
of the source code. Completely new files may be included separately or
as part of the context-diff.
If your entire patch is small (less than 25,000 bytes) you may send it
via email, with a brief description of your change, to
wuftpd-members@wu-ftpd.org.
If your patch or addition is large (over 25,000 bytes) or invloves
several files, please create a compressed tar (tar.gz or tar.Z) and
upload it to ftp://ftp.wu-ftpd.org/incoming After you have uploaded,
please send a brief description of your patchs, along with the name you
uploaded it as, to wuftpd-members@wu-ftpd.org.