I’ve tried syncing my remote files locally and accessing them through a basic file browser, but neither behaved the way I expected. MountainDuck makes the storage appear like a normal drive, while the alternatives I tested seemed to require local copies or a separate interface.
Is “mounted remote storage” the right term for what I need, and are others also finding it difficult to replace MountainDuck without changing how they work?
I decided to approach the comparison from the perspective of distinguishing the mounting of actual drives from regular file transfers, analyzing the required setup effort, operating system suitability, interface, utilization of local disks, and cost. With this approach, I focused on the daily use rather than going into the comprehensive comparison of what each program can offer as it would take more than a dozen spreadsheets. I switched to the new product last month, so these are more like personal notes than a professional review.
For raw performance and broad backend support, Rclone was the obvious power-user choice. The project is free and open source, and this Rclone option can run in the background once the command-line configuration is finished. It mounts nearly any backend without much overhead, but there is no standard graphical interface to soften the experience.
Cyberduck belongs in a different category. If mounting storage as a local disk is not essential, the Cyberduck original classic remains a dependable transfer client with FTP and cloud protocol support in one window.
CloudMounter required the least adjustment for me. The app connects directly with the native file manager and presents remote folders as local disks. It supports standard SFTP connections, with SFTP protocol details available for anyone who enjoys reading protocol pages recreationally. The same applies to standard WebDAV access and WebDAV protocol support. It also works with common cloud providers and stream-syncs files instead of pulling down entire directories, which keeps disk usage low.
RaiDrive is the Windows specific alternative. It provides mapping of remote storages to the drive letters in the file explorer and a decent performance, although the free version may show ads whereas the paid one removes them.
Browsing files is one thing, but constantly writing to databases, source control repositories, or other applications is a different scenario altogether. I would use CloudMounter for regular remote access, but keep the write-intensive projects on my local machine, since mounted cloud storage is not identical to physical storage, and thus can occasionally cause issues with file locking or brief disconnections during critical operations.
If the same files need to be accessible through a browser, a phone app, or another computer, their readability in the cache and encryption state may outweigh the speed benefit of a direct download.
I would have to disagree with the suggestion that CloudMounter was the least disruptive in terms of the overall changes needed. While the setup process only requires adding the account, the software’s ability to change the default path can interfere with the Finder’s favorites, application-specific saves locations, and scripts. I recommend testing the software in the applications that actively use the mounted disks as reliable sources of information, such as those that use sidecars, watch for changes in folders, or save As… an existing file. These applications will treat the mounted folder as a network drive, which may disrupt the intended experience.
The program is still worth consideration due to the option to encrypt the contents of the remote folder on the client side before opening it. In practice, this would keep sensitive data safe if someone gains physical access to your device, as the encryption key is only known to the user. However, the added layer of security will also make the contents unreadable in the majority of third-party clients and the provider’s website for the same reason. If this feature is found unnecessary, the choice between CloudMounter and other solutions should be made based on the ability to access the files after the system was woken from sleep, disconnected, or saving was interrupted.
Don’t replace Mountain Duck until you know which behavior you actually need.
A mounted drive, a sync folder and a folder full of placeholders can look almost identical in Finder. They fail in completely different ways. Check how the replacement handles package folders, extended attributes, file renames, applications that write a temporary file before replacing the original. Previewing large files and generating thumbnails can also initiate downloads, so Finder itself is generating more remote traffic than expected.
I’m less convinced than @rita_geek that CloudMounter requires the least adjustment. The connection setup may be quick, but the real adjustment is learning which applications can safely work against the mount. That said, CloudMounter still earns a place when you manage several separate accounts and want each remote location kept visible and distinct instead of mixing everything into a single synchronized directory.
Before buying, do some quick testing. Create a test folder and try renaming it while using your usual workflow. Overwrite one of the documents in the folder. Copy a .pkg file from your macOS app installs. Try disconnecting your network while saving a file and reconnecting it after the computer wakes up from sleep. If it all goes smoothly, you’re probably getting a good product. If it causes duplicates, half-updated files, or an endless busy state, Finder integration won’t make it a good Mountain Duck replacement.
Check the protocol on the remote end before you try installing another app. ‘Remote storage’ is a very broad category, and a NAS, an SFTP server, a WebDAV account and a cloud provider API may appear as a folder but the best way to replace them is different for each.
If this is your own NAS or server, try to avoid having to use a cloud-mounting software if you can, and instead use a private VPN (or similar) to connect to it and mount an SMB share with your OS’s file manager
This will both give applications a more traditional network filesystem to interact with, and will avoid having to add another potentially troublesome utility to your stack. Avoid exposing SMB shares to the internet.
For a hosted SFTP, WebDAV or cloud account, the choice is easier:
There is no replacement that makes Internet storage behave precisely the same way as an internal SSD. You can not have both “offline access” when disconnected and “software does not store data on local machine”, unless you are willing to have applications show disconnections. These requirements are mutually exclusive, no matter how hard you try to convince yourself otherwise.
I would also not use package files or Thumbnails in Finder as a test sequence. Pick actual applications that will be using this mounted volume as their storage, not just some random data files. Adobe projects, photo catalogs, databases, virtual machines, and mail archives are generally a bad idea to keep in any remotely network-mounted storage. Keep these critical volumes local and synchronize them with the remote server. Regular documents, media, and archives are much less taxing on a network.
In addition to speed and reliability, you may want to consider credential management options. Does the replacement offer to store credentials in the credential manager, if one is available, or does it try to prompt you for them each time? Does it have a way to store SSH keys on the remote server, so you do not have to type them every other hour? Does it keep the connection alive when the system goes to sleep? A pretty icon in the menu bar is great and all, but it will do nothing if the connection dies at 3 AM.
For a direct replacement for Mountain Duck, CloudMounter offers the closest in terms of ease of use if you need something minimally maintained. If you want to retain absolute control over your data and not rely on a third-party service, rclone is the way to go. If your applications do not work reliably with any of these two, it may be best to abandon the search for a new Mounter and switch to a different workflow instead. Working locally and then syncing with the server is less elegant, but generally more dependable than trying to convince your applications that a remote server is their local disk.
Opening the file after the remote drive was mounted is not the same thing as telling an application to restore the file automatically upon login. This distinction tripped me up the first time because while the mount in Finder might appear to work normally, it can be late enough to affect login items, aliases, and recently-used-file menus. Whatever approach you take, make sure that it remounts at the same location before your other applications start up. CloudMounter can be simpler to configure than rclone, but nothing is going to solve the problem of applications that launch too early in the process to see the mounted volume.