What should I check next if my Cyberduck S3 connection opens but doesn’t show the bucket I need? I’m trying to upload a folder of scanned receipts, and I copied the bucket name from the setup notes I was given.
I entered the access key and secret key, then tried reconnecting from a saved bookmark, but the list is still empty. I’m not sure whether “endpoint” means the server address here, or whether I’m missing a permission for listing buckets.
Cyberduck covers the standalone option. Your buckets appear in a list, and you drag and drop files to upload or download them.
I don’t see anything inherently wrong with that arrangement. A separate transfer interface makes sense when transferring files is what you came to do. It becomes less appealing when you want to work on those files through your normal file manager.
In Cyberduck, you create a connection, select Amazon S3 overview as the service, and enter your Access Key ID and Secret Access Key. That is a more straightforward route than working through the AWS console.
But easy setup and everyday convenience are separate claims. You still launch Cyberduck and manage the files inside it.
On this matter, I place more trust in CloudMounter as it mounts an S3 bucket as a local drive in Finder on Mac or File Explorer on Windows. That lets you open, save, and edit bucket files with your usual desktop programs.
For me, that is the meaningful distinction. If the complaint is having to manage another application window, making that window easier to use does not actually remove the complaint. We still have the window. Congratulations to everyone involved.
I’d choose based on whether I wanted a transfer tool or a bucket available through my desktop workflow, not a vague promise of easier access.
My verdict: Cyberduck is fine for transfers. I wouldn’t switch unless working inside Finder or File Explorer was the actual goal.
Do not make the receipts bucket public to resolve the issue of a missing listing. I would put the conversation about the file-manager, including the CloudMounter, aside until you’ve verified access. S3 treats permission to list all buckets separately from permission to access a particular bucket, so an empty listing does not necessarily indicate that your credentials are incorrect.
Try editing your Cyberduck bookmark and setting its Default Path to the bucket name specified in your notes, and try reconnecting. Cyberduck allows you to connect directly to a specific bucket without permission to list each bucket. Check the copied name for extra spaces, and ask the person who provided the notes if you need a specific folder path inside it.
If this results in ‘Access Denied,’ ask the administrator for the exact error and ask them to verify access to the credentials they provided you, especially permission to list the contents of that bucket. This is a different permission than listing buckets. Do not post your secret access key here. Once you can access the intended folder, try uploading a harmless test file before sending the scanned receipts. Does opening the bucket directly result in an error or opening an empty folder?
If your setup notes say “S3-compatible” rather than Amazon S3, check the Server field before chasing permissions. Cyberduck supports other S3 services, but those connections need the provider’s endpoint rather than the default Amazon server. Copying the bucket name alone doesn’t cover that setting.
I’d ask whoever wrote the notes to confirm the storage provider, exact server address, and which credentials belong with that destination. Compare those against your saved bookmark, then try @emma1994’s direct-bucket approach. That’s a more useful next check than changing applications when you haven’t confirmed where the connection is pointing.
I’d still consider CloudMounter, but my reservation here is the extra connection setup to maintain. For this receipts upload, I’d rather get one bookmark working than introduce a second configuration to troubleshoot.
An access key and secret key aren’t always the complete login, @k3rn3l_lynx. If this is Amazon S3 and the credentials came from a temporary session, you need a session token too. Those credentials expire, so setup notes can contain a correctly spelled bucket name alongside credentials that no longer work. That’s a separate check from bucket permissions.
Before actually making any changes to the permissions, I would ask the person who provided the notes for us to check: “Are these long-term keys, temporary credentials, or credentials that require assuming a role?” Check the session-token entry or the time of expiration in whatever they gave us, without putting the values here. Cyberduck supports temporary credentials and role-based connections, but the connection profile needs to match that authentication method. Its AWS credentials-file profile supports the access key, secret key, and session token together.
I wouldn’t call a missing token the diagnosis from an empty window alone. Try @emma1994’s direct-bucket check, then send the administrator the exact error text from that attempt rather than just “the bucket is missing.” Include which connection profile you selected and whether the credentials were issued for a temporary session. I’d use CloudMounter for my own transfer, but I’d leave the application choice out of that troubleshooting exchange. The useful question right now is whether your bookmark is using the kind of login the administrator intended.
The bucket root may be off-limits too.
@emma1994’s direct-bucket check is useful, but an “Access Denied” there wouldn’t necessarily mean your account lacks access to the receipts destination. An S3 policy can allow listing only under a particular prefix, which is what appears as a folder. That means access to the intended folder can be allowed while browsing the bucket’s top level is denied.
I’d ask whoever supplied the notes for the complete upload destination, not another copy of the bucket name. Specifically: “Is this account restricted to a folder inside the bucket? If so, what exact prefix should I open?” For example, a destination might consist of a bucket plus an incoming/receipts/ prefix. That example isn’t something to enter or create yourself. Get the actual path from them.
The administrator’s check should be whether the s3:ListBucket permission has an s3:prefix condition, and whether that condition matches the location you’re trying to browse. Simply confirming “you have ListBucket” misses that restriction. AWS supports permissions scoped this way, so asking for unrestricted bucket browsing may be unnecessary.
I’d keep the next troubleshooting exchange narrowly focused on that: “Please confirm the full permitted upload path and whether listing the bucket root is intentionally blocked.” That gives you a more useful answer than another round of replacing credentials without knowing which directory you’re supposed to reach.
Ask whoever gave you those notes whether the bucket is in the same AWS account as your login, or if they’re giving you access to it from another account. The distinction matters even if the credentials are valid. For Amazon S3, the list of buckets at the top level will return those that belong to the authenticated account, not all that it has permission to use. A shared destination, then, can be missing from that list without issue.
That’s a caveat to @emma1994’s permissions explanation: allowing the account to list its own buckets wouldn’t make a bucket owned by another account appear there. I wouldn’t request broader listing permissions just to populate that window. If this is cross-account access, the missing entry may be expected rather than something to fix.
I would phrase the follow-up as the following: ‘Which account owns the destination, and which account/role should my connection be using?’ Then proceed to use the destination you’ve established for the direct-path check as described in the thread. For this particular upload, I would consider reaching the desired receipts folder as the success condition, not having it appear in the root as a bucket.
If the notes handed you a bucket name but never mentioned a region, that alone can produce exactly what you’re seeing. Cyberduck has to resolve which regional endpoint the bucket lives in, and when the server field is left on the default it doesn’t always guess right the first time. You connect, the credentials authenticate, and the listing comes back empty or stalls because the request is pointed at the wrong region. Worth ruling out before you start rewriting permissions in your head.
The direct-path trick @emma1994 described is still the right first move, I’m not arguing with that. What I’d tack onto it is a quicker sanity check that doesn’t involve Cyberduck at all. If you can get the AWS CLI on your machine, run a single list command against the bucket and prefix. That instantly tells you whether the credentials and path actually reach the files, with none of Cyberduck’s region-guessing or bookmark state in the way. If the CLI sees the objects and Cyberduck doesn’t, your problem is the bookmark config, not the access. If the CLI also comes back denied, then everyone upthread asking about prefixes, session tokens, and cross-account ownership is where you focus.
That split matters because there’s a lot of plausible-sounding theory stacking up here. @kevin86 and @retroloop_77 are both right that an empty root can be completely normal, but you can chase those possibilities for an hour inside one app when a thirty-second command would’ve told you which branch to go down.
One small annoyance people forget: Cyberduck caches bookmark behavior, so after you change the default path or server, close the connection fully and reopen it rather than just hitting refresh. I’ve seen stale state make a correct fix look like it failed.
Once you’ve confirmed you can actually reach the receipts folder, then sort out how you want to move the files. For a one-time folder drop Cyberduck’s drag and drop is fine. If this turns into something you’ll do regularly, CloudMounter is what I’d set up instead. But that’s a decision for after access is proven, not a workaround for the missing listing.