faq

功能强大的ftp服务器源代码

directory is the anonymous area.



* A basic setup.

-> I'm trying to set up a ftp server just for me and my family so we can get
and upload files when on the road. How can I make two users, say Jane and
Joe, who share the directory /home/ftp and /home/ftp/incoming. In /home/ftp
they only have read privs. and in /home/ftp/incoming they have read and
write privs.

Add a group for all FTP users (not mandatory, but more secure):

groupadd ftpgroup

Add an uid for all FTP users (idem, not mandatory, but better):

useradd -g ftpgroup -d /dev/null -s /etc ftpuser

Now, let's create /home/ftp and /home/ftp/incoming:

mkdir -p /home/ftp/incoming
chown -R root:ftpgroup /home/ftp/incoming
chmod -R 755 /home/ftp
chmod -R 1775 /home/ftp/incoming

Let's add Jane:

pure-pw useradd jane -m -u ftpuser -d /home/ftp

Let's add Joe:

pure-pw useradd joe -m -u ftpuser -d /home/ftp

Let's start the FTP server:

/usr/local/sbin/pure-ftpd -lpuredb:/etc/pureftpd.pdb -H -B

Everything should be ok now.

For more info about how to create new users, change passwords, etc.:
http://www.pureftpd.org/README.Virtual-Users




* Slow pure-ftpwho or slow login.

-> Sometimes, pure-ftpwho is slow to show the result. And sometimes, when an
user logs in, the session stucks a bit before he can get a directory listing.

This is probably caused by a slow DNS resolver. In order to display full
host names, pure-ftpd has indeed to make DNS queries that can be slow if you
link is slow, or if the client link is slow.

You can speed up pure-ftpwho and pure-ftpd with the -H switch. Names won't
be resolved, you will see IP addresses instead.



* Chrooted users can follow symlinks outside the chroot jail?

-> People can create symbolic links to '/' and escape their home directory!

There are two chroot implementations in pure-ftpd:

  - The traditional one, based upon your kernel chroot() system call. This
is the default. With that one, symbolic links can only point inside the
chroot jail, or they won't be followed.

  - The 'virtual chroot' implementation. With that feature, users *can*
follow all symbolic links, even when they don't point inside the jail. This
is very handy to set up directories shared by multiple users. Binary
packages are compiled with virtual chroot by default.

To enable the virtual chroot feature when you are compiling the server, use
the --with-virtualchroot with ./configure . If you want a restricted chroot,
don't include --with-virtualchroot.

Please note that the FTP server will never let people create new symbolic
links. Symbolic links have to be already there to be followed. Or if your
users can create symbolic links through Perl or PHP scripts, your hosting
platform is really badly configured. People can install any web file
browser, they don't need FTP to look at your system files. Recompile PHP
without POSIX functions and run all Perl scripts chrooted.



* How to start Pure-FTPd in background.

-> I start 'pure-ftpd' from an X terminal and the server properly
answers. However, as soon as I close the terminal, the server stops.

This is a shell dependent issue. Your shell is configured to close all
background jobs when leaving. You can change your shell options
(probably with a 'set' directive) or detach background jobs with the
'disown' keyword. Alternatively, you can just start pure-ftpd with the
-B switch in order to have it detach at startup time:

/usr/local/sbin/pure-ftpd -B



* Windows command-line FTP client and 'ls'.

-> With the command-line Windows FTP client, 'ls -la' doesn't return
any file.

The 'ls' command of an FTP client has nothing to do with the 'ls' command
started from an Unix shell.

With the command-line Windows client, typing 'ls' really sends the FTP
command 'NLST'. So when you type 'ls -la', it doesn't mean 'verbosely
list all files'. According to RFCs, it means 'list the file called -la' .
So you get what you asked for. If no file is called '-la', you get nothing.

If you want to play with regular expressions and switches, you should
type 'dir' (which is translated to 'LIST') instead. 'dir -la' is ok.

This is a bit illogical and that brain damage is specific to
Microsoft's command-line FTP client.

If you really want 'ls' to parse options, you can start pure-ftpd with
the -b (broken) switch.



* Global bandwidth limitation.

-> How do I limit the *total* bandwidth for FTP?

Pure-FTPd can limit bandwidth usage of every session. But limiting the total
bandwidth is intentionally not implemented, because most operating systems
already have very efficient algorithms to handle bandwidth throttling.

Here's an example with Linux.

1) Have a look at /proc/sys/net/ipv4/ip_local_port_range. You will see two
numbers: this is the interval of local ports your Linux kernel will use for
regular outgoing connections. The FTP ports you have to reserve for passive
FTP must *not* be in this range. So if:
"cat /proc/sys/net/ipv4/ip_local_port_range" returns "32768-61000", you can
reserve ports 10000 to 20000 for your FTP server, but not 30000 to 40000.
(alternatively, you can change the local port range) .

2) Change the first lines and save the following script:

  ---------------------------- Cut here ----------------------------
  
#! /bin/sh
# Simple bandwidth limiter - <[e-mail]>

# Change this to your link bandwidth
# (for cable modem, DSL links, etc. put the maximal bandwidth you can
# get, not the speed of a local Ethernet link)
REAL_BW='10Mbit'

# Change this to the bandwidth you want to allocate to FTP.
# We're talking about megabits, not megabytes, so 80Kbit is
# 10 Kilobytes/s
FTP_BW='80Kbit'

# Change this to your physical network device (or 'ppp0')
NIC='eth0'

# Change this to the ports you assigned for passive FTP
FTP_PORT_LOW="10000"
FTP_PORT_HIGH="20000"

tc qdisc add dev "$NIC" root handle 1: cbq \
bandwidth "$REAL_BW" avpkt 1000

tc class add dev "$NIC" parent 1: classid 1:1 cbq bandwidth "$REAL_BW" \
rate "$REAL_BW" maxburst 5 avpkt 1000

tc class add dev "$NIC" parent 1:1 classid 1:10 cbq \
bandwidth "$REAL_BW" rate "$FTP_BW" maxburst 5 avpkt 1000 bounded

tc qdisc add dev "$NIC" parent 1:10 sfq quantum 1514b

tc filter add dev "$NIC" parent 1: protocol ip handle 1 fw flowid 1:10

iptables -t mangle -A OUTPUT -p tcp --sport 20:21 -j MARK --set-mark 1

iptables -t mangle -A OUTPUT -p tcp \
--sport "$FTP_PORT_LOW":"$FTP_PORT_HIGH" -j MARK --set-mark 1

  ---------------------------- Cut here ----------------------------
  
3) Make sure that you have the 'tc' command installed. If your Linux distro
doesn't ship 'ip' and 'tc' commands, it really sucks and you must install a
package called 'iproute2' to get them.

4) Start Pure-FTPd with the passive port range you assigned:

/usr/local/sbin/pure-ftpd -p 10000:20000 -HBA

5) Run the script you created in step 2. It it doesn't work, check that QOS
support was compiled in your Linux kernel.

6) Enjoy :)

Also have a look at :
http://www.docum.org
http://www.shorewall.net/traffic_shaping.htm and
http://talk.trekweb.com/~jasonb/articles/linux_tc_minihowto.shtml


* Linux, NTFS and Pure-FTPd.

-> On Linux, I can't transfer files from an NTFS partition.

Keep in mind that the NTFS filesystem is still an experimental beast in
Linux. Some basic operations are not implemented yet. Fortunately, a big
effort is being made and Linux 2.5 has a new NTFS implementation that fully
works with Pure-FTPd (try ./configure --without-sendfile, though) . And it
is more reliable and really faster than the old one. And even more
fortunately, the new NTFS implementation has been backported to recent 2.4.x
kernels. Have a look at http://linux-ntfs.sf.net/ .



* Slowdowns and lags.

-> Some users complains that transfering large files doesn't work. Transfers
are starting as expected, with a decent rate. But then, the speed dramatically
decreases, there are some serious lags and they often must disconnect (or the
client force them to do it, after a timeout) . The server is behind a firewall
that filters incoming ICMP, but let FTP ports in.

Don't, don't, don't filter ICMP. At least not blindly without understanding
what you are filtering. ICMP is part of the TCP/IP specifications. Filtering
it can have nasty side effects with no real win. If you even filter ICMP types
3 and 4, your firewall is definitely broken and this is probably why you have
such troubles with transfers of large files.

Please read these documents about ICMP filtering :
http://www.phildev.net/mss/index.html
http://alive.znep.com/~marcs/mtu/
http://www.freelabs.com/~whitis/isp_mistakes.html



* Firewalls and SSL/TLS.

-> My client is behind a stateful firewall doing applicative filtering (like
IPTables with ip_conntrack_ftp or ip_nat_ftp) . Connections to an SSL/TLS
enabled server does't work. Authentication works, but I'm unable to download
files nor list directories.

First, try to force your client to use the passive mode. In active mode, the
server has to connect to the client (or the NAT gateway) on a dynamic port
that is negociated on the connection socket. But when SSL/TLS is used, that
connection socket is encrypted, therefore no man-in-the middle can see what
ports will be used to transfer data, including the firewall. There are some
proposals to work around this problem, but neither popular clients nor common
firewalls are aware of these tricks. Therefore, use the passive mode or switch
to SSH.



* TLS and error 00000000.

-> My TLS-enabled client doesn't work. It outputs something like :
"SSL connect: error:00000000:lib(0):func(0):reason(0)". What does it mean?

This error is not very explicit. You get it from some Unix clients like LFTP.
It actually means that there is a firewall or a NAT box between a TLS-enabled
server and a TLS-enabled client, but that firewall is unable to handle
encrypted FTP sessions. Unfortunately, there's no simple workaround against
this. Try to switch your client to active mode and use 1:1 NAT, but SSL/TLS,
firewalls and FTP don't mix very well.



* Files getting renamed automatically
(submitted by C. Jon Larsen)

-> Sometimes when files get uploaded they are getting renamed to something
like "pureftpd.3f3300d2.33.0001". What is causing this ?

The ftp client that is being used to upload the files is using the STOU (Store
Unique) FTP command instead of the STOR FTP command. If you check the ftp
logfile you should see something like this in the logs:

(user@a.b.c.d) [DEBUG] Command [stou] [file_name_from_the_client.ext]
/var/ftp/ftpcustomer/pureftpd.3f3300d2.33.0001 uploaded (218168 bytes,
127.79KB/sec)

The STOU command tells the ftp client to begin the transmission of the file to
the remote site; the remote filename picked by the ftp server will be unique
within in the current directory that the ftp client is using. The response
from the server will include the filename.

The ftp client has an option like "create unique files" or "upload file with a
temporary name" enabled. You should have the ftp user uncheck this option.

Trying to disable the STOU command on the server side is not a good idea or
solution as some ftp clients will use STOU to upload a file with the
temporary, unique name, and then rename the file once the upload is complete.
This helps prevent failed uploads from leaving partial files around.