FTP FAQ

The Top 10 Reasons Clients Can't Connect

1. Your Firewall Is Blocking Connections

   Make sure your firewall is set to allow incoming connections on port 21, 3000 through 3008 (by default) and port 80, 8000 or whatever port you have defined for the Web File Manager. If you can establish a connection from within your network, but outside Internet users can't connect, there is a good chance your firewall is blocking them. For details on the ports required based on your specific Rumpus settings, see the "Router" tab of the "Network Settings" window in Rumpus.

2. Your Rumpus Server Is On a Private LAN, And Your Router Isn't Forwarding Requests

   The most common TCP/IP network setup is a private LAN (where local IP addresses begin "192.168.", "172.16." through "172.31." or "10.") bridged to the public Internet. If you have a network of this type, be sure to review the "Get Connected" information on the Maxum Web site.

3. Your Mac's Built-In Firewall Is Blocking Connections

   As a test, try disabling the OS X firewall on the server. Open the OS X "System Preferences" window, select the "Security" panel, flip to the "Firewall" tab and click the "Stop" button. (Mac OS X 10.4 users, the Firewall tab is on the "Sharing" System Preferences window.)

   Now attempt to connect to the Rumpus server. If connections are now possible, the firewall will need to be configured to allow Rumpus to accept connections. For details, see the "Firewall Setup" article in the Rumpus package.

4. Your Client Is Behind A Firewall

   Some client networks don't allow FTP access at all. More commonly, the client network will allow only passive mode connections. Have the client that is having trouble ask their network manager for assistance.

5. You Are Using "Connect To Server" To Connect

   The Mac OS X Finder includes the ability to mount remote file servers on the desktop, including FTP servers. Unfortunately, the FTP client that provides this functionality is somewhat incomplete. For example, volumes mounted via FTP are always read-only; You can't upload to an FTP server through the Finder at all.

   Instead of FTP, connect to the Rumpus server via WebDAV from the Finder. For details, see the "WebDAV" article in the Rumpus package.

6. You Have Changed The "Reported FTP Server Name" In Rumpus

   Some FTP clients use the reported server name to determine how to work with the server to which they are connecting. "MacOS Peter's Server" is a standard response sent by Mac FTP servers, and shouldn't be changed. For details, see the "Why 'MacOS Peter's Server?" FAQ on the "FTP Questions" FAQ page on the Maxum Web site.

7. Your Router Requires Special Setup In Rumpus

   Some reouters perform special FTP processing, while others treat FTP sessions just like any other connection. Be sure the "External Network IP Address" field on the "Basics" tab of the Network Settings window is set correctly, and then flip to the "Router" tab and have outside users attempt connections with the "Allow Router To Perform Data Connection Address Mappings" both on and off.

8. The Wrong Server Is Running

   Make sure that the Mac OS X built-in FTP server, and any other FTP server you may have been working with, is off. If another server is started before Rumpus using the same local port number, then Rumpus will not be able to listen for incoming connections. To check for other services running on your server, run a diagnostic test using the "Self-Diagnostics" window which is accessible from the "Help" menu in Rumpus.

9. The User Is Not Allowed To Connect

   Rumpus includes automated security features which will block access from suspected hackers. Check the user account to confirm that the "Permit Login" privilege is enabled for the user in question, and check the "Blocked Clients" list to make sure the client IP address isn't blocked from accessing the server.

10. You Have Set The "Address To Serve On" Incorrectly

    In most cases, the "Address To Serve On" field (on the "Network Settings" window) should be left at "All", so that Rumpus will automatically bind services to all IP addresses configured on the server. If you are having connection problems, reset the pop-up menu to "All", then save the change and stop and restart the Rumpus server.

If none of the common problems described above seems to apply, then let us help you resolve your unique problem. Send e-mail to "support@maxum.com" with details about your problem. Please always include your server's name or address and a test username and password, so we can log in and look for trouble, as well as the FTP client or Web browser you have been attempting to use, whether or not you can connect to the server from other machines or using other user accounts, and any other details that seem relevant.

Why is the "Reported Server Name" set to "Mac OS Peter's Server"?

If you have ever used a graphical FTP client and looked at the FTP session transcript, you have probably noticed that most clients use the "SYST" command to determine the "system type", and that Rumpus responds by reporting that it is "MacOS Peter's Server". This response is required by a number of clients for historical reasons, and should not be changed without very good reason.

"Peter", who is not associated with Maxum, refers to Peter Lewis, the author of the first widely used FTP server for Macintosh. The server he developed responded to the SYST request with this name, and several FTP clients used this response to determine certain behaviors. For example, Mac-savvy FTP clients that identify a Mac-savvy server (by checking for "MacOS Peter's Server") will enable the MacBinary transfer mode when appropriate. MacBinary is essential to FTP transfers so that Mac files retain their resource forks and Finder information.

In addition, many FTP clients on several platforms use the "SYST" to determine how directory listings should be parsed. If you change the "Reported FTP Server Name" in Rumpus, these clients may not be able to correctly interpret and display directory listings at all.

So, while Maxum would prefer to report "MacOS Rumpus" as the server name, and you might prefer to specify your company name, the name "MacOS Peter's Server" is simply required in most cases for FTP client compatibility.

Why can't Windows clients connect? (Or... Why can't Mac clients connect?)

Sometimes, you may find that some clients can't connect to (or otherwise work with) your server, while others can, especially when you are just getting started. When this happens, it often seems that the problem lies with a particular operating system: Either Windows users have no trouble but Mac users do or vice-versa.

The reality is that this is almost never the case. When some clients can establish connections and transfer files, but others can't, the problem is usually due to networking differences. Check to see if the problematic clients are behind firewalls that prevent FTP access. Also, confirm that your own network permits both passive mode and active mode connections. If you aren't sure, ask the clients which connection mode their FTP clients are set to use.

There are also differences between FTP client applications, and these differences are much more significant than the computer platform the client is run on. Make sure the "Reported FTP Server Name" is set correctly on the "Advanced" tab of the Rumpus "FTP Settings" window (see the "Why MacOS Peter's Server" FAQ for details). If possible, download the FTP client in question and give it a try yourself to determine if the problem is with the client or the network.

As always, if problems persist, contact Maxum Technical Support. In cases where a particular client or platform seems to be the trouble, it is especially important to include the server name or address, a test username and password (so that we can attempt to log in to your server and look for problems) and the name of the FTP client that is giving you trouble.

Directory listings don't display correctly...

Directory listings represent a special problem for modern FTP clients. The FTP specification, which was originally written decades ago, does not define a format for directory listings, and in fact states that they should be presented in human readable format only and are not to be read by automated programs. Unfortunately, for graphical FTP clients, directory listings must be read and parsed for display; There is just no other way to do it.

Rumpus, therefore, emulates a traditional Unix listing as much as possible, but a complete copy of the Unix format isn't possible. Unix listings don't include data and resource fork sizes, for example, since resource forks are unique to the Mac platform. This information, however, is important to Mac-savvy FTP clients. Maxum has spent a great deal of time developing a listing that is broadly compatible with various popular FTP clients and still retains the directory's "Mac-ness".

The most common problem is that the "Reported FTP Server Name" has been changed from the Rumpus default, confusing the client and causing it to incorrectly interpret the directory listing format. For details on this problem, see the "Why 'MacOS Peter's Server'?" FAQ.

Another common source of problems are spaces or other confusing characters in filenames, especially at the beginning of a filename. For example, files with a space (or other "whitespace" characters) at the beginning or end of a filename will almost always be incorrectly processed by FTP clients. This is because spaces separate fields (such as the time and date from the name of the file) in the directory listing. If a filename begins with a space, the FTP client will consider the space part of the separation, and will think that the filename begins with the first non-space character. Attempts to download the file will then fail, since the client will have the wrong name. Similar display and download problems will sometimes occur with other extended characters, depending on the FTP client being used.

The best debugging strategy is to use a popular FTP client that will display a session transcript, and review the raw directory listing being sent by Rumpus. Most FTP clients will display the raw listing in the transcript, and you can use this to determine if Rumpus is sending incorrect information or if the client is misinterpreting it. For additional help diagnosing this problem, contact Maxum Technical Support.

How can I tell what port is being used for a data connection?

Once you understand the difference between passive mode and active mode FTP connections (as described in the "FTP Overview" article in the Rumpus package), it is sometimes helpful for network debugging to be able to determine exactly what port is being used for a particular passive mode data connection. Here is how you can do it:

Start by logging in to Rumpus with any popular, dedicated FTP client, and open the session transcript. In Fetch, for example, you can open the transcript by selecting "Fetch Transcript" from the "Window" menu. Perform a directory listing or transfer a file, and notice that the FTP commands issued by the client are displayed in the transcript. As the directory listing or file transfer starts, you will see a command and response in the transcript that looks something like this:

PASV
227 Entering Passive Mode (192,168,1,100,11,187)

If your client is set to active mode transfers, you will see the "PORT" command instead. In this case, log out, set the client to use passive mode transfers, log in again and try again.

Rumpus tells the client the IP address and port to connect to in the "227" response, where the six values in parentheses represent the IP address and port number. The first 4 values are the address. To determine the port, take the 5th value multiplied by 256 and add the 6th value. In the above case, the port number is (11 * 256) + 187 = 3003.

Certain actions seem really slow...

A properly configured Rumpus server and network will provide extremely good FTP performance. If Rumpus seems slow, there is probably a problem with either the server setup or (more likely) the network.

Internet Connection Speed

First, it is important to understand that Internet connection speeds are rated in raw bits per second, while virtually all FTP and Web clients will display transfer rates in data bytes per second. The Internet connection speed rating doesn't take into account checksum bytes, packet headers, overhead in the transfer protocol, etc. And of course, there are 8 bits in a byte. So a good rule of thumb is that you can expect actual file transfer rates, measured in bytes per second, to be roughly one-tenth the rated speed of your Internet connection.

Based on this guideline, a typical DSL connection rated for 512 Kbps will support file transfers of around 50 KBps, or perhaps a bit more, and an Internet connection rated at 1 Mbps would provide maximum transfer rates of around 100 KBps. Keep in mind that many Internet connections provide for different transfers rates for data moving "up" to the Internet or "down" from it. In this case, you can expect clients to be able to upload data to your server faster than they can download from it (if their Internet connection speed is fast enough).

So before looking for performance problems, check with your ISP and confirm your Internet connection speed. Consider both the upload and download speeds they offer, and divide the connection speed rating by 10 to compare it to actual file transfer throughput speeds your clients are seeing in actual use.

Bandwidth Allocation

As you compare the speeds users are experiencing with the speed you expect, based on your Internet connection speed, also consider that the available bandwidth is probably being shared with other applications. If other users on your network are surfing the Web, downloading video or other files, streaming audio, or otherwise accessing the Internet, that activity consumes bandwidth available for Rumpus file transfers. Multiple simultaneous Rumpus users will also slow down transfers, of course.

For example, if two Rumpus users are simultaneously uploading a file to your server, and your Internet connection is rated at 1.5 Mbps, you can expect each file to be uploaded at about 75 KBps (the total available bandwidth, 150 KBps, divided by 2 concurrent uploads). If a user on your network begins a file download, and another listens to an audio stream, the file transfer rates would likely fall to about 30 to 40 KBps.

Possible Problems

There are cases where file transfers don't meet the expected data rate, even when your total bandwidth allocation is taken into account. When file transfer speeds don't meet expectations, start by determining what aspects of the file service are slow.

In some cases, establishing a connection may be slow. For example, if the FTP client attempts to load a directory listing, but the listing doesn't start within a few seconds, there is probably a problem establishing connections. The most common reason for this is that the network is not allowing passive mode connections. The reason for the delay is that the client attempts a passive mode connection, waits some period of time for the connection to be established, and then retries using an active mode connection when the first attempt fails. The problem can also occur in reverse (the client attempts an active mode connection, then drops back to passive mode), but this is less common. Watch a session transcript using a popular dedicated FTP client to diagnose this problem for certain, then follow the instructions in the "FTP Overview" and "Port Forwarding" articles to get passive mode connections working on your network.

It may also be that file transfer rates are not as high as you would expect. In this case, data transmission is often occurring over unexpected network links. For example, you may be connecting to your Rumpus server from a computer on the same Ethernet network, but the connection is actually being routed out across your WAN Internet connection and back in to your server. Here, your file transfer throughput rate will be restricted to the speed of your Internet connection, rather than the high speed Ethernet. This problem requires that your router be updated so that connections established to local computers be made directly on the LAN.

Of course, the problem may be simpler than inefficient routing. First, make sure that the user account in Rumpus doesn't have speed limits assigned (by checking the "Maximum Upload Rate" and "Maximum Download Rate" settings on the "Restrictions" tab of the "Define Users" window). Also, make sure that neither the client or the server are running other applications that could restrict networking or CPU performance. System backup software, for example, can place heavy loads on both networking and CPU, so that FTP performance may appear poor during backup periods.

If these suggestions don't lead to a resolution, contact Maxum Technical Support. Be sure to include exactly what "slow" means in your problem description: Are connections slow, or sustained transfers? Exactly how long does a connection take? What is the throughput of the file transfer, as reported by the FTP client? What is the speed of your local network and Internet connection? And of course, please include the server name or address and a test username and password, so that we can log in and look for known problems.

Does Rumpus support multi-homing?

The issue of "multi-homing" is very different when discussing FTP vs. HTTP (Web). The point of multi-homing is to ensure that each client be given access to the correct content (usually a folder) based on the host (Web site) they are accessing. For Web servers, this means figuring out which of multiple Web sites is being requested and serving the page from the correct folder.

But when connecting via FTP, users typically log in using a user account name and password. This means that the FTP server can use the user account information (in Rumpus, the user's home folder) to determine what folder the user should be given access to, rather than relying on the IP address or host the user originally requested.

In other words, Rumpus supports listening for incoming connections on multiple IP addresses assigned to the same server, and will correctly serve user content from home folders defined for each user account. So, for practical purposes, Rumpus does support multi-homing, with a couple of restrictions.

The first restriction is that user account names must be unique across the entire server. For example, you can not define a user account "bob" for one "virtual host" and the same account name for another. The second restriction is that "anonymous" users will all be granted access to the same folder on the server: Rumpus does not support multiple anonymous folders that are differentiated by the host that was originally requested.

Of course, these restrictions certainly don't interfere with using Rumpus to provide FTP access to many Web developers, each with their own virtual Web server. In this case, as long as each Web developer is given their own unique user account (which you would certainly want to do in any event), then each can be restricted to their own Web server content folder using the Rumpus "home folder" feature.

Can Rumpus be made to work with the Finder's "Connect To Server" function?

Yes. The OS X Finder can mount remote servers as volumes on the desktop via AFP (Apple Filing Protocol), FTP and WebDAV. Since Rumpus acts as both an FTP and WebDAV server, either protocol can be used to login to a Rumpus account from the Finder. However, the Finder's FTP support is fairly limited, and in particular mounts FTP services as "read-only" volumes. WebDAV is therefore the recommended method for mounting a Rumpus server via the Finder.

With WebDAV enabled (using the option on the "Options" tab of the "Web Settings" window), you can simply use the "Connect To Server..." function on the client Mac. When specifying the connection address, be sure to begin the address with "http://" to let the Finder know you want to connect via WebDAV rather than AFP. You will also need to include the port number, if the Rumpus Web server is running on any port other than 80. In short, the connection address is exactly the same as it is when connecting to the WFM via Web browser.

For complete details, see the "WebDAV" article in the Rumpus package, and contact "support@maxum.com" if you have any trouble.

Sometimes, file transfers fail. How can I improve reliability?

There are several reasons why file transfers may fail, and unfortunately, it's usually impossible for Rumpus to determine why.

Think about making a call from one cell phone to another (or using land-lines 30 years ago). Disconnections happen, but from your point of view, you can't really tell where the problem occurred. It could have been a loss of service on your phone, on the other person's phone, or somewhere in between. The other person may just have hung up, or their phone may have run out of power. All you know is that the connection was lost.

Similarly, when a client connection is lost, Rumpus has no good way to tell why. It could have been a bad connection. The client may have inadvertently closed the browser window (terminating the connection), or a firewall may have decided to close the connection. (Some firewalls, for example, will only allow HTTP POSTs to be a certain length.)

The first thing you should do is make sure your users understand that they can't close their browser, shut off their computer, click "reload" or take any other action that would cause the browser to load a different page or FTP client to move on to another task until the transfer is complete. Most FTP clients do a pretty good job of displaying transfer in progress status, and the Rumpus WFM progress indicator is also a good way to discourage people from inadvertently terminating a connection.

Another way to improve reliability on slow network connections is to increase the Rumpus timeout values. These can be found on the "Basics" tab of the "FTP Settings" window. The default timeout values are fairly generous, but you can try increasing them to avoid Rumpus terminating connections that are very slow, but not completely broken. However, there is usually not much point to exceeding 20 minutes (1200 seconds) for the User Inactivity timeout or 8 minutes (480 seconds) for the other, connection oriented, timeout values.

Another major cause of transfer failures is bad networking hardware. While it seems that routers, hubs, Ethernet adapters and even cables should either work or not work, this isn't actually the case. It is not uncommon for networking hardware to degrade gradually before actually failing. This can lead to data corruption and failed connections. If network failures are suspected, try changing out your Ethernet cabling and switch the router, if at all possible.

Networking can also be overworked, causing delays and even failed connections. Downloading video files, streaming music, VoIP phone service, etc. all put a huge drain on your Internet bandwidth. Especially during peak usage times, overworked networking can easily result in not only slowed file transfer rates, but failures as well.

If problems persist, and a particular user tends to have trouble, try to find out if the transfer always gets interrupted at a certain point, or after a certain amount of time. Also, ask them what type of 'net connection they have, and whether or not their network has a firewall that might be interrupting transfers.

In most cases, when you look at specific cases (and not just a log history that shows general failures over time) it becomes pretty clear why transfers are failing. Even when different users are experiencing problems at different times, the only way to diagnose problems is to look at the individual cases and try to determine what specifically is causing the failures.

How can I move my Rumpus settings and user accounts to another Mac (or the same Mac after a clean system install)?

This is a really common question, so there is a new, more complete post describing the process here, in my blog.

What are each of the files in my Rumpus config folder?

Several of the files in the Rumpus configuration folder hold Rumpus administrator-set configuration options. These files may be restored or moved to a new server as needed when re-installing or moving a Rumpus server.

Rumpus.conf

This is the primary configuration file, which holds most single option settings in Rumpus. Globally defined options found on the FTP Settings and Web Settings windows, in particular, are saved in this file. Note that because most Rumpus servers use default values for most basic configuration settings, and the fact that some of these settings are specific to a particular server, it is generally recommended that this file not be moved to another server.

Rumpus.users

All user account information is saved in this file. The ".users" file is usually the most important Rumpus configuration file to back up and restore, since defining users is typically the most time consuming administration task in maintaining a Rumpus server.

Rumpus.fsets

All Folder Set information is stored in this file.

Rumpus.ucd

Upload Center definitions are stored here.

Rumpus.types

Rumpus File Type definitions are stored in this file.

Rumpus.rips

The Blocked Clients list is stored here. (".rips" stands for "Reject IPS".)

Rumpus.aips

This list of permanently allowed clients is saved in this file. (".aips" stands for "Allowed IPS".)

Rumpus.vdomains

Virtual domain configuration options are stored in this file.

Remote.config

Remote administration settings used by the remote control daemon are stored in this file.

Other files store activity tracking and management databases. The information in these files is dynamic, and will generally not need to be backed up or moved, as Rumpus will recreate these files as needed.

Rumpus.pid

The current Rumpus server daemon process id file is saved in this file. This file should not be restored, copied, or moved to another server.

Rumpus.userstats

User account access statistics are stored here, for display on the History tab of the Define Users window. The file is used for statistics tracking only and is not necessary for server operation.

Rumpus.uploads

Recently uploaded files are tracked in this file, for reporting, as well as for use by the expired file expiration function.

Rumpus.rfiles

A record of recent file transfers is maintained in this file, primarily for reporting purposes.

Rumpus.drops

The drop shipped files database is stored in this file.

Finally, these files are installed by Rumpus and are generally not intended to be modified. These files do not need to be backed up or moved, since they will be installed by performing a fresh Rumpus installation.

rumpusd

The Rumpus server daemon program.

rumpusremoted

The Rumpus remote control daemon program.

Rumpus.strings

A variety of text strings, used internally by Rumpus, are stored here.

Mac2Web.txt

A character conversion table used to translate MacRoman characters to ISO-Latin-1.

Web2Mac.txt

A character conversion table used to translate ISO-Latin-1 characters to MacRoman.

Should I be concerned about failed access attempts reported in my Rumpus logs?

In most cases, no, you don't need to be too worried about failed accesses, though there are a few simple precautions you should take to avoid having your server compromised.

When you run a public Internet server, whether it provides Web, FTP, mail, or other services, external clients can and will attempt to connect. For example, some viruses will generate network activity, scanning for servers and probing for vulnerabilities. In this case, the virus will have infected another computer on your LAN, at your ISP, or elsewhere, and might use various techniques to scan for and attempt to access services. Automated robots, scanning for servers and probing for security holes, guessing at passwords, and performing various other activities, are very common on the Internet. This traffic goes unnoticed by most Internet users, but anyone that monitors the activity of an Internet server has almost certainly seen it.

This is why Rumpus includes security features designed to cut off apparent scanners and probes. In particular, when this type of activity is recognized by Rumpus, the client's IP address is added to the "Blocked Clients" list. This reduces the amount of server time needed to respond to troublesome clients (because they are simply terminated as soon as they attempt to connect), and also limits their ability to probe your server.

To further minimize the possibility of a security breach, be sure to pick non-trivial, difficult to guess passwords for all user accounts, and restrict anonymous user privileges as much as possible, if you need to enable anonymous access at all. For details, and for additional suggestions on maintaining server security, see the "Server Security" article in the Helpful Info folder of the Rumpus package.

In short, robots, scanners, probes and network analyzers are common on the Internet, and if you run a publicly accessible server, you should expect to see connections from them, and even login attempts. As long as your Rumpus logs report "access denied" or "bad username and/or password", the attempt was rejected, and no real access was ever granted. Be sure to apply common sense security precautions, as described in the "Server Security" article, and contact Maxum technical support at "support@maxum.com" if you have any specific concerns, or if you ever have reason to believe that your server has been compromised.