Every Mac user discovers this the same way. You press ⌘K in the Finder, type an ftp:// address, log in, and the server appears in the sidebar like a network disk. Then you drag a file onto it and get an error, or nothing happens at all.
The Finder is not broken and you have not misconfigured anything. macOS mounts FTP volumes read-only, deliberately, and has done for well over a decade.
What Apple actually removed
Mac OS X used to have a writable FTP filesystem. It went away in OS X Lion (10.7, 2011), and what remains is a read-only mount that can browse and copy down but never up. There has been no sign of it returning in the fifteen years since.
The reasoning is not mysterious. Making a filesystem out of FTP means pretending a stateful, two-connection, latency-heavy protocol behaves like a local disk. The Finder expects to stat files instantly, write partial ranges, rename atomically and handle a dozen concurrent operations. FTP supports none of that well. Every attempt to paper over the gap produces data loss in edge cases — half-written files, silently failed saves, corrupted uploads on a dropped connection.
Read-only is the honest compromise: it exposes what FTP does reliably and refuses what it does not.
Apple removed the plain ftp command-line client too, in macOS High Sierra (10.13). Between the two decisions, macOS today ships nothing that can write to an FTP server.
What about sftp:// in Connect to Server?
It does not work either, and this one surprises people more, because SFTP is the better protocol. The Finder’s Connect to Server understands smb://, afp://, nfs://, vnc://, http(s):// and ftp://. There is no sftp:// handler in macOS.
macOS does include a full OpenSSH client, so sftp in the Terminal works perfectly — but that is a command-line tool, not a Finder volume.
The workarounds, and their real costs
macFUSE + sshfs. Mounts a remote directory over SSH as a real writable volume. It genuinely works, and it is the closest thing to the experience people want. The cost: macFUSE installs a kernel extension, which on Apple Silicon requires lowering the security policy in Recovery mode and approving a third-party extension at every major OS update. That is a serious concession for a file transfer.
A WebDAV or SMB bridge. If your host offers WebDAV or SMB, the Finder mounts both properly and writably. Very few web hosts do.
Mount read-only, edit locally, upload some other way. This is what most people end up doing by accident, and it is the slowest possible workflow.
Use a client. Which is the answer this page is building towards, and worth being straightforward about: a dedicated FTP client is the normal solution, not a workaround.
What a client gives you that a mounted volume cannot
This is the part that is easy to miss when what you wanted was “a folder in the Finder”. A mounted disk has a fundamental limitation: it has no concept of a transfer. Copy 800 files to a mounted volume and your Wi-Fi drops at file 500 — you get an error dialog and no idea which files made it.
A real client models transfers explicitly:
- A queue you can pause, reorder, and resume. Upstream retries with exponential backoff and resumes interrupted transfers from the byte offset where they stopped, rather than starting a 4 GB file again.
- Concurrency. Several connections transferring at once, which on a directory full of small files is the difference between two minutes and twenty.
- Both sides at once. A dual-pane layout showing local and remote together, with directory comparison highlighting what differs.
- Protocols the Finder does not speak — FTPS in both explicit and implicit modes, and SFTP with key authentication.
- Credentials in the Keychain rather than in a mount configuration.
Upstream is sandboxed, which is the same security model the Finder itself operates under — no kernel extension, no lowered security policy, no reboot into Recovery.
Step by step
- Stop trying to make the Finder write to FTP — it is a removed feature, not a setting you have missed.
- Check whether your server offers SSH — if it does, you have SFTP, which is better in every respect.
- Use a native client for anything involving uploads — set up a saved site with credentials in the Keychain.
- Keep the Finder mount only for casual browsing, if you use it at all.
- Avoid installing a kernel extension just to get a writable mount, unless a mounted volume is genuinely a hard requirement for some other tool.
Questions people ask
Can macOS write to FTP servers at all?
Not through the Finder. Write support for FTP volumes was removed in OS X Lion in 2011 and the ftp command was removed in High Sierra. A third-party client is required.
Why can I see the files but not change them?
Because the volume is mounted read-only at the filesystem level. It is not a permissions problem on the server — the same account will happily write through a real client.
Does Connect to Server support SFTP?
No. There is no sftp:// scheme in the Finder. The sftp command in Terminal works, but it does not produce a mounted volume.
Is sshfs a good solution?
It works, but on Apple Silicon it needs macFUSE, which means a kernel extension, reduced security policy and re-approval after OS updates. For file transfer specifically, a sandboxed client is a much lighter answer.
Will Apple bring FTP write support back?
There is no indication of it. The trend has been the opposite — removing FTP support from the Finder, the Terminal, and Safari.