1. Introduction
As data transfer protocols, the use of File Transfer Protocol (FTP), SSH File Transfer Protocol (SFTP), and File Transfer Protocol Secure (FTPS) can be a daily occurrence. Thus, automating access to such a remote share can be a time saver and a way to optimize and streamline the work process.
In this tutorial, we’ll look at ways to mount file transfer protocol server paths as local filesystem drives. First, we explore how to acquire and install an old but still working implementation for our needs. After that, we go through the steps of its usage in practice. Finally, we look at an alternative to FTP and FTPS and how to use that to mount a remote filesystem locally.
We tested the code on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.
2. curlftpfs
Due to the age of FTP and FTPS, few improvements and applications are being developed to optimize the use of these protocols. In fact, the main recommendation when it comes to using FTP and FTPS as a local filesystem is still CurlFtpFS, a project from 2008.
Since then, even that project has been dropped as a package for most major Linux distributions. However, it still fulfills its original purpose.
The CurlFtpFS source is now mainly available from its homepage and some archive sources:
$ wget https://src.fedoraproject.org/repo/pkgs/curlftpfs/curlftpfs-0.9.2.tar.gz/b452123f755114cd4461d56c648d9f12/curlftpfs-0.9.2.tar.gz
There are several dependencies for curlftpfs:
$ apt-get install glib-2.0 libfuse-dev libcurl4-openssl-dev
In particular, we install three packages:
- GLib version 2
- FUSE library development headers
- libcurl as provided by libcurl4-openssl-dev
After acquiring curlftpfs-0.9.2.tar.gz and setting up the dependencies, let’s install curlftpfs:
$ tar xf curlftpfs-0.9.2.tar.gz
$ cd curlftpfs-0.9.2
$ ./configure
[...]
$ make && make install
At this point, curlftpfs should be available:
$ curlftpfs --version
curlftpfs 0.9.2 libcurl/7.88.1 fuse/2.9
Now, let’s use it to mount FTP and FTPS drives.
3. Mount FTP or FTPS Filesystem Drive
The original FTP protocol doesn’t provide encryption of information in transit. Thus, its only means of security is a username and password combination sent over the network in clear text. To remedy this, FTPS was developed with support for TLS and SSL certificates when working with FTP.
Although FTP and FTPS are no longer recommended, we might still find these simpler data transfer protocols in fully trusted and protected local networks.
3.1. Mount FTP as Local Filesystem
By leveraging curlftpfs, we can mount a remote FTP server path:
$ curlftpfs -o allow_other <USER>:<PASSWORD>@<FTP_SERVER>:<PATH> <MOUNT_POINT>
Of course, we populate the relevant fields on a per-case basis:
- FTP_SERVER: hostname or IP address
- PATH: optional path within FTP server root
- MOUNT_POINT: local path of the final mount
- USER: FTP username
- PASSWORD: FTP password
Let’s see a specific example:
$ curlftpfs -o allow_other user:[email protected]:/path/to/directory /mnt/ftp
Notably, the allow_other option comes from the FUSE feature set and overrides the mount owner so that any user can access the files.
3.2. Mount FTPS as Local Filesystem
Similar to the pure FTP scenario, FTPS directly employs curlftpfs for the mount:
$ curlftpfs -o allow_other,ssl <USER>:<PASSWORD>@<FTP_SERVER> <MOUNT_POINT>
The main difference is the ssl option to force the use of SSL for both the control and data connections. This option requires a valid certificate and proper setup.
For example, let’s set up the ubiquitous vsftpd for use with SSL:
$ openssl req -nodes -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.key -out /etc/ssl/certs/vsftpd.crt
[...]
Common Name (e.g. server FQDN or YOUR name) []:xost
[...]
$ cat /etc/vsftpd.conf
[...]
rsa_cert_file=/etc/ssl/certs/vsftpd.crt
rsa_private_key_file=/etc/ssl/private/vsftpd.key
ssl_enable=YES
$ systemctl restart vsftpd.service
In this case, we first generate a 10-year certificate and key for the xost Common Name via openssl. After that, we set up both in the appropriate fields of the /etc/vsftpd.conf configuration file and enable SSL. Lastly, we restart the vsftpd service with systemctl.
In case we use a self-signed certificate, we might want to also add two more options:
$ curlftpfs -o allow_other,ssl,no_verify_hostname,no_verify_peer <USER>:<PASSWORD>@<FTP_SERVER>:<PATH> <MOUNT_POINT>
This way, we skip some of the SSL verifications:
- no_verify_hostname: skip hostname verification within the certificate
- no_verify_peer: skip peer verification of certificate
If using vsftpd or another more restrictive FTP server, we might need to ensure we have write permissions over the resulting mount by turning on (YES) and changing the write_enable or similar option in the configuration.
In all cases, we can automate this process at boot via the /etc/fstab file:
$ cat /etc/fstab
curlftpfs#example.com /mnt/ftp fuse rw,uid=500,user,noauto 0 0
Although the tool works, even with the unofficial minor updates to curlftpfs, its lack of maintenance and use of the old FTP and FTPS protocols make it a less-than-optimal approach.
4. Mount SFTP Drive
As usual, it’s best to use SSH for data transfer for better security, stability, and maintainability. In particular, an SSH-based SFTP server can employ SSHFS as long as we have it installed:
$ sshfs -o allow_other,default_permissions <USER>@<FTP_SERVER>:<PATH> <MOUNT_POINT>
Naturally, this option requires an SSH server setup and SSHFS. Yet, this is fairly trivial to set up on most Linux systems:
$ apt-get --assume-yes install openssh sshfs && systemctl start sshd.service
Here, we install the OpenSSH and SSHFS packages via apt and start the relevant service.
In case of issues with the above method, we can more easily perform some troubleshooting.
5. Summary
In this article, we talked about mounting an FTP server path as a local filesystem.
In conclusion, although old, there is an option to mount an FTP or FTPS server as a local filesystem, but it’s usually best to opt for the use of SSH SFTP instead.