I'll elaborate on DJKarl's answer, which is essentially correct.
What you don't see when you connect Access front-end to any other back-end is the protocol that they use. You don't see it because for Windows-to-Windows servers it is totally transparent most of the time, particularly if you are in a domain environment or already have mapped drives. The Windows File Sharing protocol allows you to open files on a remote device and manage pointers that work for the inside of those files. With Windows File Sharing you can request gets and puts of single disk buffers. Exactly what Access needs when working with a remote file server.
When you link to an SQL or ORACLE or SYBASE or (whatever else) server as the back end, you are using an ODBC package specific to that back end server and database combination. An ODBC package approaches the problem differently in that Access sends queries to the back-end and gets back replies. In between the query and the reply, the database package on the back-end server handles the disk accesses required in whatever way is required. The replies get fed to Access using internal pointers for the result-sets (sometimes called database cursors in some systems) to track the progress of processing the reply.
An FTP server does not use either Windows File Sharing or ODBC protocols. FTP's protocol is designed to transmit WHOLE FILES (and an occasional directory listing). An Access database needs something that is capable of looking at PARTS of a file (when in file sharing mode) or it has to handle queries (when in ODBC mode). The protocol involved for an FTP server is not capable of doing either of thise functions.
Before you ask, ... no, you can't augment FTP to implement this ability. FTP is managed by an international standards committee who would laugh you out of the building if you suggested this. The thrust of the committee is to SIMPLIFY, not COMPLICATE all network protocols. Oh, by the way - Secure FTP (FTP via Secure Shell) and other FTP variants will have the same exact problem.
If you could establish Windows File Sharing protocol to this FTP server, you would do pretty well. If you could run something locally on the FTP server and establish ODBC protocols, you would do pretty well. But for "straight" FTP, the protocol isn't designed for dynamic gets and puts of individual disk buffer-loads within a single file.
Now, the next point to consider: Why would you dedicate a server like that? According to "best network security practices" you must segregate functionality so that if your web servers get hacked, you can still run applications that aren't web based. You can still send and receive files. You can still establish database connections. Because by spreading out functionality, you make it close to impossible for a total denial of service to occur. Which is why, if you are at a U.S. Government site or a fairly progressive commercial site, I wouldn't hold my breath about getting an application loaded to an FTP dedicated server.
