The FTP connector talks to any standards-compliant FTP server with user/password authentication and passive mode (the default for most clients). It preserves the full folder hierarchy and works as both source and destination.
Step 1 — Collect server details
You need four pieces of information from whoever runs the FTP server:
| Setting | Example | Notes |
|---|---|---|
| Host | ftp.example.com or 203.0.113.10 | Hostname or IP. No ftp:// prefix. |
| Port | 21 | Default. Some servers use 990 (FTPS) or non-standard ports. |
| Username | assets-migrator | The FTP account name. |
| Password | … | The account password. |
For anonymous FTP (public FTP servers), the convention is:
- Username:
anonymous - Password: any string (commonly an email address)
Step 2 — Paste credentials into Univaultport
In the connector wizard:
Host
The hostname or IP, no protocol prefix.Port
Leave blank for 21. Override only if you know the server uses something different.Username + Password
The credentials from your FTP server admin.Root Path (optional)
A starting directory. Defaults to the user's home directory. Example:/pub/assetsscopes the connector to that folder.
Click Save & test. Univaultport runs:
- A TCP connect to host:port
USER+PASS(login)CWDto rootPath if setPWDto confirm we landed in the right place
A green check means all four steps passed.
Active vs. passive mode
FTP uses two TCP channels — a control channel (commands) and a data channel (file bytes). The data channel can be opened in two ways:
- Active mode — server connects back to the client on a random port. Breaks behind NAT/firewalls. Mostly historical.
- Passive mode — client connects to a server-provided port. Works through firewalls. Default for Univaultport.
If the server doesn't support passive mode (rare, ancient servers), Save & test will time out on the directory listing. Ask the server admin to enable passive mode — it's usually a one-line config flip.
Performance characteristics
FTP is a single-channel protocol: one command at a time per connection. Univaultport's worker concurrency setting (default 5) does not parallelize calls to the FTP server — operations on a single connection are serialized internally to avoid "command in progress" errors.
Practical implications:
- Network latency dominates throughput
- 1000 small files: roughly 50-200 seconds at typical latencies
- 10 GB single file: as fast as your bandwidth allows (transfer doesn't multiplex)
For dramatically faster bulk migrations between cloud destinations, don't pick FTP as the source unless the data only lives there. Mirror it to S3/GCS first and migrate from there.
Common errors
| Error | Cause | Fix |
|---|---|---|
Authentication failed (530) | Wrong username/password | Verify with ftp CLI or FileZilla first |
Path or file not found (550) | rootPath doesn't exist for this user | ls from the user's home dir to find the right path |
Write permission denied (553) | User lacks write permission on dest dir | Have the server admin grant w on the target folder |
| Connection refused | Server not running or port wrong | Confirm with nc -zv host port |
| Timeout on listing | Active mode required by server / firewall blocks data channel | Enable passive mode on the server |
Security notes
- Univaultport encrypts FTP credentials AES-256 at rest. They're never returned in API responses.
- The connection itself is unencrypted — anything on the network path can read both credentials and file bytes.
- Univaultport does not support explicit FTPS (FTP-over-TLS) in this release. If you need encrypted transfer, use SFTP.
Next steps
With FTP connected, common patterns are:
- FTP → S3 / GCS / Azure for moving legacy hosting media to a cloud bucket
- Cloudinary / Drive → FTP for delivering processed assets to a legacy CMS that only ingests via FTP
- FTP → FTP for migrating between two legacy systems during a host change
Folder hierarchy is preserved on writes since both sides of an FTP migration support real folders.
