I’m trying to upload files in Cyberduck, but it keeps saying “connection failed” before I can get in. I’ve reentered my login details and checked the saved connection settings, and I’m sure the credentials are correct. What should I check next to figure out why it won’t connect?
Remote storage can appear as a regular drive. That is the detail that makes storage CloudMounter useful to me when I mainly want access to cloud files. I sometimes use it when connection problems persist, because the drive-based approach feels more straightforward for everyday file access.
I try to keep these issues separate. A preferable method of contacting files is one thing, but that does not explain what could possibly be wrong with the other application. These are two different issues, even if I have to address them both while trying to accomplish what I need.
What I want from file access
I need the ability to access files without thinking about it. CloudMounter offers that, and that is the crucial part of the alternative I am considering. I care more about the ability to reach the files than I do about the change of application.
FTP/SFTP compatibility and the ability to access files easily are both factors, but I would not say that a preference for mounted storage proves that it is universally better. There is a more limited point to be made here. If I am concerned primarily with the ability to reach cloud files without much thought, then this is an option worth considering.
That does not address the issue I am concerned about. I do not want the alternative to serve as a convenient replacement for an explanation.
What I check before changing applications
I have encountered connection trouble with client Cyberduck too. The possible causes include an incorrect server address or port, firewall issues, timeouts, and problems with the connection on the server side. The failure alone does not give me enough information to choose among those causes.
The documentation points to connection settings and logs as the starting place. I use the connection Cyberduck guidance to keep the settings check separate from my preference about how files should appear.
I also keep the troubleshooting Cyberduck guidance available when reviewing logs. Settings and logs are the suggested first checks, not a promise that either will settle the issue.
Where I draw the line
In the event of a recurrence, I would adopt the mounted-drive approach for daily use. I would characterize that as a choice of a workflow, rather than one of addressing the causes of the initial malfunction.
My recommendation is to review Cyberduck’s settings and logs before further action. I would select the CloudMounter when I need remote storage to appear as a standard drive, not as a substitute for a comprehension of a connection failure.
7 Likes
A login rejection and a connection timeout call for different checks, even with the same credentials. Cyberduck’s timeout error can mean the server isn’t answering at the selected address and port, rather than a password problem. I’d push back on choosing CloudMounter for the drive-style interface here. It earns a place as a second-client test instead: try the same protocol, server, and account without changing networks. I’d use the result to narrow the investigation, not declare either app broken. Can you paste the exact error beneath “connection failed,” with identifying details removed?
Are those credentials for a file-transfer account or your hosting dashboard? Before trying another client, I’d ask the host to confirm that file-transfer access is enabled for your account and whether it requires a separate login. That’s a check I’d put ahead of @mr_lynx’s second-client test. I’d still reach for CloudMounter as an alternative, though having another saved connection to keep updated is a small nuisance. First, establish exactly which account the server expects you to use.
Repeated login attempts can leave you dealing with an IP ban on top of the original problem. Some servers block an address after failed authentication attempts. Entering the correct password afterward does not remove that block. That is a possibility, not a diagnosis from “connection failed.”
I’d put @mr_lynx’s second-client test on hold briefly and ask the host a narrower question: “Is my current public IP blocked from the file-transfer service?” Not whether the account exists. Not whether the password is correct. Whether connections from your address are being blocked.
For that support request, I’d include:
- The time of one deliberate connection attempt, including your time zone.
- The server, protocol, and port you selected.
- The complete error text beneath “connection failed.”
- Your public IP, sent privately to support rather than posted here.
Ask them to check that attempt against their connection and security logs. I would specifically ask whether they see an authentication rejection, a blocked connection, or no matching attempt. “Your account looks active” would not answer the question I’m asking.
Until they respond, I’d stop reentering the password and leave the saved settings alone. You have checked those already. I would not reset a password you believe is correct merely to produce another variation of the same test.
If support confirms a block, ask what triggered it before having it removed. If they find none, return to the client comparison with that possibility checked. I would not buy a replacement application at this stage. First get something more useful than the error dialog’s two-word verdict.
Correct credentials won’t get you in if the connection type doesn’t match what the server expects. The naming is confusing to me here: SFTP and FTPS sound like two ways of saying “secure FTP,” but they’re different protocols. I’d want to compare the host’s exact wording with the option selected in Cyberduck, rather than treating the secure-sounding options as interchangeable.
I agree with @d33p_router about stopping repeated password attempts, but I wouldn’t completely leave the saved settings alone. You can inspect them without reconnecting. Instead of checking whether you typed everything correctly, check whether the instructions you started with actually specify that connection type. A perfectly copied username and password would still leave that mismatch unresolved. I wouldn’t cycle through the options guessing, either.
The question I’d send the host is: “For this file-transfer account, should I select SFTP, FTP with TLS, or plain FTP, and which port goes with that choice?” That feels more useful than asking them to confirm the password again. If their answer matches your bookmark exactly, this possibility is ruled out without installing anything or making more failed login attempts. Don’t switch to plain FTP just to see whether dropping the security makes it work.
Nobody’s asked how fast the failure happens. That timing tells you more than the two words in the dialog. If Cyberduck throws ‘connection failed’ almost instantly, the server is actively refusing you or nothing is listening on that port, which points at a wrong port or protocol pick. If it sits there for fifteen or twenty seconds and then dies, that’s a timeout, and now you’re looking at a firewall, a VPN, or the server just not answering from your network. Watch the clock next time you hit connect.
@swifthivenet is right that SFTP and FTPS are not the same thing, and that’s the mismatch I’d chase first because it’s the most common one. But there’s an even dumber version of it worth ruling out: some hosts hand you an SFTP endpoint that runs on a nonstandard port, and if your bookmark still says 21 or the default, you’ll fail every time with a perfect password. Check the port next to the protocol, not just the protocol.
The IP-ban angle from @d33p_router is real, but I’d hold it as a maybe rather than lead with it. Repeated failures on a wrong-protocol setup usually don’t trigger a ban because you never actually authenticate. Bans tend to come from repeated password rejections, which is a different failure. So the timing question circles back again. If you were never getting far enough to be rejected, a block is less likely.
One quick thing before you email support or touch anything: try reaching the server another way to see if it’s you or them. A different client, a phone on cellular instead of your home wifi, or mounting it as a drive through something like CloudMounter all work for that. You’re not switching tools, you’re just checking whether the address answers from somewhere other than your current setup. If it works on cellular and fails on wifi, your router or ISP is the story, not the credentials.
If none of that moves it, then yeah, get the host to tell you the exact protocol, port, and whether file transfer is even enabled on that account. That’s the answer that ends the guessing.
A successful connection from your phone wouldn’t prove your router or ISP is responsible, @fusioncloud. That changes both the device and the network, so I’d be cautious about drawing that conclusion. For a cleaner comparison, try Cyberduck on the same computer through your phone’s hotspot, keeping the saved connection unchanged.
A password the server turns down and a password the server never asked for can both collapse into the same two-word error. The first means you’re reaching the service and it’s telling you no. The second shows up when the account is set for key authentication and password login is switched off completely, so a perfectly correct password lands you nowhere. That second case gets missed a lot because it doesn’t feel like a ‘wrong protocol’ problem and it isn’t a ban either.
Worth asking the host directly whether password auth is even turned on for your file-transfer account, or whether they expect you to upload a public key. A fair number of managed SFTP setups default to keys now and treat passwords as disabled. If that’s the situation, no amount of retyping or client-swapping fixes it, and you’d chase the protocol dropdown for an hour with nothing to show.
@swifthivenet is right that SFTP and FTPS get treated as the same thing when they aren’t, and I’d chase that too. But the key-auth angle can hide behind a correct protocol pick, so ruling out the SFTP-vs-FTPS mismatch doesn’t automatically clear it. @nanocoder563’s hotspot idea is the cleaner comparison here, same machine, same bookmark, just a different network, because it changes one variable instead of two.
One thing nobody’s poked at yet: make sure the hostname actually resolves to where you think. A stale DNS entry or a hosts-file line pointing at an old server IP gives you an instant failure that looks identical to a wrong port. Try connecting by the raw IP once, and if that works while the name fails, your resolution is the story. Once the handshake finally goes through and you just want the files sitting there day to day, that’s when I’d mount it with CloudMounter and stop thinking about it.