I really need a solid replacement that lets me mount remote storage directly in Finder/File Explorer without downloading the entire directory locally. Free or paid is fine, as long as it doesn’t freeze my system. What are you all using these days?
I evaluated several possible replacements based on the sorts of tasks I wanted to use them for: connecting to remote storage, transfer of files, and checking if the interface acted like a mounted drive or a separate transfer client, plus observing system resource usage and amount of command-line based operations needed. The point wasn’t to find the most comprehensive set of features, but something that would be useful after a recent update made my previous toolset less convenient to use.
The simplest option for a mounted drive interface
For a straightforward graphical replacement, I had the best experience with CloudMounter during regular file management. It felt lighter on system resources than Mountain Duck, which mattered because I wanted remote storage available without another application weighing down the system.
It puts remote connections directly into the normal file manager rather than treating them as a separate place to manage files. Support includes SFTP for secure server access, along with WebDAV and most common cloud providers. Since the files are mounted remotely, they don’t have to consume local disk space just to remain accessible.
That was the closest to a drop-in replacement. There wasn’t much change required in the daily workflow and I didn’t have to shift everything to a dedicated transfer window.
Terminal speed versus a desktop application
Anyone comfortable working in a terminal should seriously consider Rclone as the faster and more flexible route. It’s free, open-source, and supports a very broad range of storage services. The mount command provides the drive-style behavior, tho getting everything configured takes a few more steps than installing a typical desktop app.
For another graphical alternative, I also tried ExpanDrive as a fairly direct competitor. It handles mounted cloud accounts well enough, but its memory use wasn’t equally predictable across operating systems. I’d test it on the specific machine rather than assume it’ll be lighter.
The choice between the two comes down to personal preference and is largely a matter of how much setup one is willing to do. Rclone has a steeper learning curve but offers benefits to power users who are comfortable with the command line, whereas ExpanDrive is easier to set up but has limitations in terms of addressing all resource consumption complaints.
When mounting is not required
Not every workflow needs remote storage to appear as a native drive. If the real requirement is simply uploading, downloading, or organizing files on remote servers, Cyberduck handles that through a standard FTP-client interface. It comes from the same developers as Mountain Duck, costs nothing, and works well when direct file transfers are enough.
The tradeoff is lack of native mounted-drive integration, which makes it slightly less seamless for opening remote files from within regular apps, but is totally fine if a user only needs to transfer the file every once in a while.
In my personal opinion, CloudMounter is best for the most basic graphically-mounted type of setup, and Rclone is preferable if a person doesn’t mind the command line.
20 Likes
No mounted-drive application is going to make a sluggish or unstable server act like a local SSD. I would consider using the CloudMounter, but keep active project files on local drives and sync them back when I’m done, particularly for apps that make lock files or that autosave constantly, in order to avoid most of the issues that actually are the result of the unreliable mounting that are really connection drops or application quirks.
The missing piece of information is what causes the failures: sleep/wake, changes in the vpn, or large file saves. I would not refer to it as a true drop-in replacement until it passes those particular cases, but it does deserve a place when other users have to restore a connection, but without having to maintain an Rclone command or background service. Test the reconnect and overwrite/rename before doing anything.
Do not move your live working folders onto a new mount and pretend that the replacement has fixed the problem. Mounted remote storages can fail in subtly different ways compared to regular files, especially when there is an application that does save to file operations by opening a temp file, renaming it, and deleting the old one. Databases, photo libraries, mail archives, and source-control repos are all common examples.
For the same kind of ‘remote-file-like-drive’ experience, CloudMounter is probably the closest equivalent on macOS. On Windows, RaiDrive is another option. Rclone can do something similar on either platform, but I would not choose it unless you’re prepared to babysit config files, mount options, caching, and startup scripts. It stops being convenient as a Mountain Duck replacement when you have to debug why your background mounts aren’t reconnecting after every network switch.
I agree with @smartrunner453 that reconnect behavior matters more than whether the drive appears nicely in Finder or Explorer. My test would be intentionally unfriendly: open a disposable document, put the computer to sleep, change networks, reconnect the VPN, then save and rename the document. After that, try a folder containing many small files and a single large upload. A replacement that quietly leaves stale files or reports success before data reaches the server is worse than one that displays an obvious error.
Pay attention to caching as well. While it will give the impression of speed, it creates a delay period during which the file, even if it shows as being on your computer, might not yet exist on the far end in its final state. Less caching will provide a truer representation of what the server has at any given moment but will cause certain applications to become painfully slow. There is no right answer because something with an archive of media files will have a drastically different experience than something that’s a collection of tiny files.
For documents that need to be able to survive a connectivity loss, I would personally keep the active version local and then sync it at a later point. Use the mounted version for previewing and occasional editing but do all major file operations on the one that exists in your local machine. It sacrifices the convenience of autosaves but prevents a single connectivity hiccup from corrupting your work or making it inaccessible.
My somewhat cautious recommendations would be CloudMounter for the closest graphical experience, RaiDrive if you’re on a Windows machine, and Rclone for the control over the process. No matter what you pick, test it with the applications that you’re going to use it with beyond just a couple of drag and drop operations.
If the thing you’re mounting is an object store like S3 or Backblaze B2 rather than an actual remote filesystem, a lot of the reliability talk in this thread misses the mark. Object stores don’t have real rename or partial-write operations under the hood. So the exact temp-file dance @techspark described, where an app writes a temp file, renames it over the original, then deletes the old one, gets emulated with full copy-and-delete cycles. That’s slow and it’s where you see phantom ‘success’ before the data actually settles. No mounting app fixes that. It’s baked into what the backend can and can’t do.
The other thing that nobody’s actually mentioned yet is authentication expiry. Half of all ‘it dropped after sleep’ complaints are not related to networks at all but due to an OAuth token or session expiring while the machine was asleep, and the mount didn’t manage to renew it cleanly when it woke. It’s something worth checking before assuming the whole application is to blame, as it impacts what even counts as a ‘good’ replacement, if not the semantics of the whole thing. You want a replacement that re-authenticates transparently instead of just reconnecting the socket.
For the actual mounting I’d use CloudMounter and point its encryption at anything sensitive on the remote, since that’s independent of whatever the provider does on their end. Beyond that I mostly land where @fox.node did: treat the mount as a viewing and light-editing surface, and do anything that involves an app holding a file open on a local copy. The reconnect test everyone’s pushing is right, but pair it with a token test. Let the laptop sleep for a couple hours, not thirty seconds, then come back and save. That’s the scenario that actually catches the bad ones.
Do not install a replacement before cleaning up after Mountain Duck’s startup items and filesystem extension, because two mount drivers are causing the freezing you want to fix! Reboot (or maybe just reconnect to a new S3 bucket or whatever) then try CloudMounter with a disposable connection, and check Activity Monitor or Task Manager while it’s doing a big listing of a folder before committing.
You may have had enough of mounting helper apps. If the remote end has SMB or WebDAV, then using Finder’s ‘Connect to Server’ and Explorer’s ‘Map network drive’ will suffice to mount it without having to pull the whole tree down and without requiring any additional filesystem driver to be installed to freeze the machine. It won’t handle SFTP or object storage, but that’s the first thing I’d try out before installing yet another layer on top.