I’m bouncing between remote files and local copies for my team’s work, and keeping track of which copy I edited is getting old. I need to decide whether to keep using Cyberduck or change how we access the server, but our editing software expects files on a drive rather than inside a transfer window.
Can Cyberduck mount a server as a drive that other applications can open directly, or does that require a separate kind of tool?
The thing people get wrong is assuming that making cloud storage look like a local drive means syncing everything onto their computer. It doesn’t. I’d separate those requirements before comparing apps, because access and local storage consumption aren’t the same thing. For my setup, I want files available through the normal file browser without keeping a full local copy of everything.
That’s why I ended up switching to CloudMounter. It’s been easier for what I need: SFTP, FTP, S3, WebDAV, Google Drive, Dropbox, and OneDrive connections can appear as drives in Finder or Explorer. I can open and edit files through those mounts without manually downloading copies first, and it doesn’t sync the whole account onto my disk. Keeping the accounts together also means fewer separate tools to juggle. There’s built-in encryption for sensitive cloud files, though the storage behavior is what matters most to my comparison of CloudMounter.
The other distinction is between transferring files and mounting storage. A transfer client can give you its own window for browsing remote files and dragging them back and forth, but that doesn’t make the connection an OS drive. That’s the limitation with Cyberduck.
If you’ve already got bookmarks set up there, I wouldn’t ignore the cost of redoing that work. The same developers offer a mounting app that can reuse those bookmarks, so starting over isn’t necessary with Mountain Duck bookmarks.
My CloudMounter setup took maybe five minutes: add a connection, enter credentials, mount it. There’s a free version to test, too. I’d judge the options by the workflow rather than just whether they connect successfully.
Are you mainly trying to avoid local copies, keep your existing bookmarks, or edit remote files through your usual folders?
Check the way your teammates would like to authenticate before switching everyone on mounted drives. For the team of Macs, I suggest using the CloudMounter’s Keychain integration to store server passwords so that they do not have to retype them every time they establish a connection, which is an extra detail worth noting apart from the Finder’s utility. (help.electronic.us)
A mounted drive can leave you waiting on an upload after you think you’re done editing. CloudMounter, for example, distinguishes files queued for upload from files actively uploading or transfers that failed. That matters when “I saved it” is your signal for a teammate to take over.
@looppro’s distinction between mounting and syncing is useful, but I’d make the decision around that handoff rather than disk space. Your complaint is about knowing which copy has the work. I’d lean toward mounted access for everyday editing, with an explicit rule that the server version is the shared working copy. I wouldn’t keep a parallel folder of manually downloaded working files unless there’s a specific reason for it.
CloudMounter gets my recommendation for its Finder upload-status icons. Showing queued, uploading, and failed states beside the files is a genuinely useful detail for this workflow. It gives you something concrete to check before telling someone the file is ready.
Before changing the whole team’s setup, I’d run a small handoff exercise with a disposable document. Edit it through the mount, save and close it, check that the transfer finishes, then have a teammate open it from their machine. Repeat with a brief connection interruption. The result I’d care about is whether everyone can recognize an unfinished transfer without needing the person who configured the app.
I’d keep Cyberduck for deliberate download-edit-upload jobs and use mounted access for the routine back-and-forth. No need to turn this into an all-or-nothing migration. But I’d retire “saved” as the handoff message. “Uploaded and closed” is the rule I’d put in the team’s instructions.
Do not move everyone onto a mounted drive and call it a day. First decide who has permission to edit a file (or else you’re just shifting around people’s open copies of conflicting versions).
@rocketlogic’s “uploaded and closed” rule covers the end of an edit. It leaves the beginning unresolved. Suppose you and a teammate both open the same document before either of you changes it. You finish, upload, and close. Your teammate still has the document they opened earlier. What happens when they save? That’s the behavior I’d want established before calling the server copy the shared working copy. An upload indicator answers whether a transfer finished, not whether somebody’s changes survived.
Ask the maintainer of the server whether your particular set of server / connection / editing app does any of the following: prevents conflicting edits, warns of a conflict, or allows overwriting. Don’t take ‘it works like a drive’ as an answer. Have two people open a disposable file, make different edits, and save them in some order. Check the result. This tests for a different class of failure than an interrupted upload, and is directly applicable to a team that has trouble tracking editing.
If there isn’t reliable protection, consider using a simple ownership rule: claim the file (by editing) before opening it for editing, and release it (by stopping the edit) after whatever upload finishes. A simple notice in the team chat can suffice for ad-hoc work. If people need to be editing the same document constantly, that coordination becomes a task of its own. At that point I would begin questioning whether either the manual transfer or mounted approach is appropriate for the sort of work. I would want a reliable way to recover an overwritten version, rather than someone having a saved local copy.
For files with separate owners, mounted access seems like a good answer for your copy-juggling problem. For files that everyone touches, I wouldn’t switch the team yet. Keep their Cyberduck workflow while you find out what happens to conflicting saves. Fewer download steps are always nice, but I don’t think they’re worth making it easier to overwrite each other’s changes.
Mounted drives still stash local copies, they just hide them in a cache folder, so the ‘no local copy’ framing is a bit optimistic. For what it’s worth, CloudMounter reconnecting on its own after the machine wakes from sleep is the part that saved me the most hassle. Everything @cache1871 said about conflicts still stands regardless of which tool you pick.
If your server has a number of folders that could possibly contain the current version of the draft, mounting the server will not help you to distinguish between them; you will simply be able to reach the wrong one with less effort.
I would categorize “too much transferring” as a separate issue from “nobody knows where the work belongs”. In order to solve the latter, I would suggest designating a particular place for each project that is intuitive enough so that it can serve as a working space for collaboration. Store deliverables there along with drafts that have been superseded with comments on what changes have been made. Make sure to put the working folder location field in the task description, rather than attaching a file or sending a link to a separate location. It may seem like nitpicking, but this way you can actually ensure that the person attempting to open the file has reached the correct document in the first place, not just another similar one they have permission to edit
That’s my reservation about @rocketlogic’s server-copy rule. “On the server” needs to mean a particular location, not whichever server folder someone last used. I’d favor mounted access if the team knows exactly where work belongs and the download/upload routine is the remaining nuisance. I wouldn’t replace Cyberduck solely to sort out ambiguous copies.
A useful check before spending anything: ask teammates separately where they would open a project’s current draft. If their answers differ, there’s your first job. No new client required.
Don’t assume a mounted drive will stop people from saving new copies somewhere else. @silentbadger_63’s working-folder rule needs to cover Save As and exports, too. Before switching, I’d have someone run an ordinary task in the actual editing app, including creating a revision and exporting the deliverable, then show where each file ended up. If that still involves hunting through local folders, the mount hasn’t solved your complaint. I’m not against switching, but I’d judge it by the whole editing routine rather than how convenient opening the original becomes.
Expect to have mounted access to trade some transfer chores for connection troubleshooting, not eliminate the housekeeping. I would make the switch optional until there is someone who owns the ‘my drive disappeared’ support position, as putting the server in Finder does not appoint a help desk. The handoff rules sound appealing, but your team needs a human to contact when they can not reach the working folder at all.