I just got a new Mac and need a solid FTP client to manage my web server and clear out some old backup files. I keep seeing Cyberduck recommended for macOS. Is it still a good choice, or are there better options out there?
Cyberduck is still a very reliable option, especially if you want a clean interface that fits right into macOS. It supports standard FTP, SFTP, WebDAV, and even connects to cloud services like Amazon S3 or Google Drive without needing a separate app for each. Plus, it is open source and completely free if you download it straight from their site.
I actually prefer CloudMounter for daily file management. Traditional clients like Cyberduck make you open an app window to transfer files back and forth. CloudMounter simply mounts your FTP servers directly inside native Mac Finder as if they were external hard drives. It is a better option for everyday use because you can open, edit, and save server files straight from your favorite Mac apps without doing manual uploads and downloads every time.
If you just need a straightforward, free transfer tool occasionally, Cyberduck works great. But if you want remote files to feel like local folders, CloudMounter makes life much easier.
9 Likes
I’d stick with Cyberduck here. Your headache is figuring out what finished, so I wouldn’t treat Finder integration as the deciding factor. CloudMounter earns a place for its client-side encryption when storing private files, but that’s a different reason to choose it.
For an occasional folder upload, I’d stick with Cyberduck, but for the same upload job every week, I’d favor a script that saves a per-file transfer log. I’d use CloudMounter for other file work, but switching interfaces wouldn’t be my next move here. Before retrying, I’d compare remote filenames and sizes against the originals, not just count what’s there. The useful upgrade is having a record of what finished so the next interruption doesn’t turn into another round of detective work.
Don’t retry the whole folder over an existing set of images until you’re sure you’re comfortable replacing what’s there. If the destination is just an empty folder you created for this upload, there’s less to worry about. If it holds an older batch you still need, I’d pause before accepting any overwrite prompt.
I’d lean toward keeping Cyberduck for your routine uploads rather than changing tools after this interruption. My concern would be where you’re uploading, especially if those images feed a live website or a shared folder. In that situation, I’d upload into a separate temporary folder and leave the working set alone while sorting out the failed transfer. That gives you somewhere to retry without making the existing files part of the experiment.
That’s where I’m a little more cautious about @alpharaven’s suggestion to script a recurring job. A weekly schedule wouldn’t be enough to convince me on its own. Before trusting a script, I’d want to know what it does with an existing file, where it stops after an error, and whether running it again could replace something unintentionally. A transfer log would help explain the result, but I’d still want those decisions settled beforehand.
The temporary-folder approach does leave you with a separate step to put the finished batch where it belongs. Depending on how the images are used, that step may need some care too. I’d accept that extra work when replacing published files. For a disposable destination, though, I wouldn’t build a whole process around it. I’d keep Cyberduck and reserve the scripting effort for a job whose retry behavior I could define clearly.
Don’t switch to Terminal just to get a log.
I’d push back a little on @alpharaven’s logging suggestion: my requirement would be an exception report, not a transcript. After an interrupted upload, I want something that tells me which files still need attention. If I have to read through connection messages and successful transfers to assemble that list myself, I haven’t solved your complaint. I’ve moved it into a text file.
For your routine, I’d give Cyberduck another chance, but judge it on recovery rather than how easy it is to start an upload. A useful trial would be a disposable folder with a few images: interrupt the transfer deliberately, then see whether you can work out what remains and restart it without guessing. That’s a test I’d want any replacement to pass too. A nicer interface wouldn’t get an exemption.
My checklist would be pretty short:
- Can I distinguish a completed batch from a stopped batch immediately?
- Can I identify the files needing another attempt without reconstructing the session?
- Is it clear what the next retry will do?
Those would be acceptance criteria, not features I’d assume either approach provides.
I’m less concerned about whether the job runs daily or weekly than about how much attention it demands when it breaks. I’d choose a command-line setup if whoever maintains it can make those answers explicit and keep them understandable. I wouldn’t choose it merely because typing a command looks more repeatable than dragging a folder.
So yes, Cyberduck would still be my first choice here. But if that small interruption test leaves you doing the same detective work, I’d consider that a legitimate reason to replace it. Recovering from a stopped transfer is part of the job, not an optional convenience.
A stopped image upload can leave you with a file that exists in the listing but is only half written, and that is the trap nobody’s named yet. Cyberduck shows the filename fine, so counting to 37 tells you nothing about whether image number 19 is a complete JPEG or a truncated one that opens to gray. That’s why @alpharaven’s instinct to check sizes against the originals is the actually useful move here, not just tallying names. A partial file reads smaller, so a size diff will flag it where a headcount won’t.
Where I’d temper @xdarkstackx a bit: the exception-report idea is the right thing to want, but Cyberduck isn’t going to hand it to you on its own. Its transfer window marks failures during the session, and if you don’t clear the queue you can right-click the failed items and resume just those. Close the app or clear the list and that record is gone. So the honest expectation is that Cyberduck passes the recovery test only if you treat that queue as fragile and don’t wipe it before you’ve read it.
For anything I touch more than once, I stop fighting the queue entirely and mount the server with CloudMounter, then let a normal folder-compare tool diff local against remote by size. That sidesteps the whole done-or-not-done guessing, because you’re looking at two folders instead of interpreting a log. For a one-off dump into an empty folder, though, that’s overkill, and @swiftserver8529 is right that a throwaway target folder saves you from the overwrite-prompt anxiety in the first place. Sort out the retry there, verify sizes, then move the finished batch across.
Finder integration would be a downside for me when deleting server backups: I’d want a clear distinction between remote storage and an ordinary folder on my Mac. That’s where I disagree with @falconking’s preference. Making remote files feel local sounds convenient for editing, but less appealing when the purpose is removing things.
I’d choose Cyberduck for your use case and treat its separate window as a benefit rather than extra friction. CloudMounter’s approach makes more sense if you want server access woven into your everyday file work. For occasional uploads and cleanup, I’d rather open a dedicated client, check the server and directory, do the job, and disconnect. I’d settle which backups to keep before selecting anything for deletion, whichever interface you choose.