I keep seeing Cyberduck recommended for Mac managing cloud storage and server files on Mac. Has anyone actually used it for a while? Is it good enough to rely on daily, or are there better options out there?
The downside is that it doesn’t feel very “Mac native.” It opens as its own separate window instead of showing up like a normal drive in Finder, and moving or editing files can feel clunky compared to just dragging things around normally. Large transfers also tend to slow down or hang more than I’d like.
Eventually I switched to CloudMounter and it’s been noticeably smoother. The reason is that it actually mounts your cloud storage as a real disk, so it behaves like any other folder on your Mac. That means faster file access, easier drag and drop, and way less lag with bigger files since you’re working with the system directly instead of through a separate app layer like Cyberduck does.
So basically, Cyberduck is fine if you just need occasional file transfers, but if you want something that feels integrated and handles daily use well, CloudMounter is the better pick on Mac.
18 Likes
If the server limits simultaneous sessions, set Cyberduck to a single transfer connection and enable retries; the “running” pause often comes from connection negotiation. CloudMounter is excellent at keeping several remote accounts available from one menu bar.
The downside of forcing a single connection is that folders containing lots of small files can take much longer. Still, @j.collins is probably right for a server with strict session limits. A transfer marked “running” may be waiting for a server response or applying file metadata rather than sending bytes.
For a stable setup, I’d use a single transfer connection, enable failed-task retries, remove any bandwidth limit, and leave timestamp and permission preservation disabled unless the server actually requires them. Those extra operations can drag out FTP uploads with many files. Raising the connection timeout slightly may help if the server is simply slow to respond.
Try uploading one large file to the same destination. If that starts immediately but a folder appears stuck, the problem is probably the number of files or metadata work, not raw upload speed. I’d use CloudMounter for routine remote access and keep Cyberduck for deliberate transfer jobs where its queue and retry controls are useful.
Automatic retries have a hidden downside: they can make a permanent server error look like a transfer that is merely taking its time. A quota problem, rejected filename, or failed rename may leave the job marked as running while Cyberduck repeats the same operation. I would not raise the timeout until you check the log and see an actual timeout. Otherwise you may only make each failure take longer.
Pay attention to where the pause occurs. If it happens before every file, that points toward FTP command overhead, directory listings, or data-connection setup. If Cyberduck repeatedly stops on the same item, inspect that filename and the destination permissions. Testing a plain text file with a simple name in the exact target directory is more useful than testing somewhere else on the account. Creating a file does not always prove the account can overwrite, delete, or rename it.
Temporary-name uploads are another possible trap. Cyberduck can upload under a temporary filename and rename the result after completion. That protects applications that monitor the destination from seeing an incomplete file, but it depends on the server allowing the final rename. If the account can write but cannot rename in that directory, try disabling that option for a test. Do not leave it disabled for a live watch folder unless partial files are acceptable.
For FTP, I would use passive mode on a normal home or office network and keep concurrency low. A separate transfer connection is preferable to tying up the browser connection, but opening a pile of parallel sessions is asking for trouble on older hosting accounts. If SFTP is available, I would choose it instead of spending much time tuning active and passive FTP behavior. Cyberduck’s FTP transfers require a separate data connection, so a firewall can allow login and directory browsing while still interfering with the upload itself.
Folders full of small files will still appear hesitant because the client has to perform work between files. If you control the server and can unpack archives there, uploading the folder as an archive is a useful diagnostic and often a quicker workaround. If the archive transfers normally, the connection speed is probably not the problem. The delay is more likely per-file negotiation, metadata handling, or a particular filename.
My stable baseline would be low concurrency, passive FTP or SFTP, no bandwidth throttle, a limited number of retries, and the normal timeout until the log proves it needs changing. I would keep timestamp and permission changes out of the equation during testing. Switching to a mounted-drive client may improve daily Finder access, but it will not repair a server account that cannot rename files or open FTP data connections, and it may give you less detail about where the operation is failing.
Changing FTP settings is not the first move if the pause happens before any bytes leave the Mac. Cyberduck can show “running” while it waits for the source file, and that gets overlooked.
Check whether the folder is in iCloud Drive, another synced folder, a sleeping external disk, or a network share. Placeholder files may look local in Finder but still need to be downloaded before Cyberduck can read them. During that wait, the transfer display is not especially informative.
Copy a troublesome file to a genuinely local folder and upload that copy to the same server location. If it starts promptly, leave the timeout and connection settings alone. The delay is on the Mac side. If it still stalls, then @jackson’s low-concurrency setup and log check make sense.
For folders with many items, let Finder finish copying or downloading the whole folder locally before starting Cyberduck. It is less clever than tuning six transfer options, but usually easier to diagnose.
A transfer stuck at zero bytes is a different animal from one crawling along at a few kilobytes. The first is almost always a handshake, a listing, or the source file not being ready. The second is real bandwidth or throttling. People keep tuning connection settings when the bar hasn’t moved off zero, which tells you nothing has even started.
@mr_root nailed the part everyone skips: check where the folder actually lives before touching FTP options. iCloud placeholders will happily sit there pretending to be local. That single check saves more time than half the settings in this thread.
The one thing I’d lean on harder than the others did is the transcript log. Open it and watch. If it repeats the same command over and over, that’s your answer, no guessing needed. Retries with no log open is how a rejected filename ends up looking like a slow server for twenty minutes.
For daily server access I keep it mounted through CloudMounter and only fire up Cyberduck when I want the queue and the log in front of me. Two different jobs, no reason to force one tool to do both.
Duplicate the bookmark before changing anything, then tune that copy for this server only. There is no universally “stable” Cyberduck setup, and changing several global options at once just hides the cause. Use SFTP if offered, keep concurrency low, leave the timeout at default, and disable unnecessary permission or timestamp changes. If it still sits at “running,” read the transcript rather than waiting. Zero progress usually means Cyberduck is waiting on the source, the server, or a command response, not uploading slowly.
Push a single file at the server and it usually starts near instantly. Point Cyberduck at a folder with a deep tree and it can sit on ‘running’ for a bit before anything moves, because the client walks the whole structure and builds the transfer list before it sends a single byte. On a folder with nested subfolders and thousands of items that scan alone takes real time, and the progress bar tells you nothing during it. So the ‘no progress but running’ state you saw might not be the server at all, it might be Cyberduck still counting.
That lines up with what @lena_io said about zero bytes versus a crawl, and I think that split is the most useful thing in the thread. Stuck flat at zero is almost never bandwidth. But I’d add a wrinkle to the list-building idea: it also means creating the remote directory structure. Cyberduck makes the folders as it goes, and on some FTP hosts each mkdir plus the listing check between them is slow. That reads as a stall even though the client is busy.
Where I’d push back a little is the enthusiasm for retries earlier in the thread. @jackson already flagged the masking problem, and I’ll go further. On a folder job I’d turn retries off entirely for the first test run, not just limit them. You want the thing to fail loudly and fast so you can read the transcript, not quietly loop for ten minutes. Add retries back once you know the transfer actually works end to end.
The mounted approach with CloudMounter sidesteps the whole pre-scan issue for casual drops since Finder just copies, though that also means you lose the queue view when something does go wrong, which is the one time you actually want it. My honest take: for a folder that stalls, don’t touch six settings. Zip it locally, upload the one archive, and unpack server-side if you have shell access. If the archive flies up, you’ve proven it was per-file overhead and directory creation, not the connection, and you’ve moved the folder anyway.