Been using FileZilla Pro RemoteDrive for about eight months, but it constantly drops connections. The mount disappears from Finder every few weeks, forcing me to force-quit and reconnect. I’ve lost work twice because files were open in an editor when it crashed.
The app’s own changelog lists “patched several crashes,” confirming it’s a known issue. Given the reliability problems and the $10/year auto-renewal fee, I want a robust replacement. I’m on macOS only and need a reliable app that can mount both an SFTP server and an S3 bucket as local drives without dropping.
Your RemoteDrive crashes probably aren't random. It uses Apple's File Provider extension, and its own changelog mentions fixing a “rare crash quitting” along with several other crash fixes. So this does seem to be an ongoing issue with the app, not just bad luck on your machine.
I'd try CloudMounter first. It handles FTP, SFTP, FTPS, WebDAV, S3, and other cloud storage, mounting everything as a regular local drive. That's basically the same setup you have now, but it has a decent reputation for staying connected during long sessions. It's cross-platform too, which could be useful if you ever move to Windows.
Another option is Mountain Duck. It's made by the Cyberduck team and has been around much longer than RemoteDrive. It can mount FTP, SFTP, WebDAV, S3, and quite a few other cloud services as local disks.
If the yearly subscription bothers you as much as the crashes, NetDrive may make more sense. It has a one-time purchase option starting at about $49.95. That's more money upfront, but it could cost less if you plan to keep using it for several years.
CloudMounter's trial is the best place to start since stability seems to be your main problem. If it works but you still don't want another subscription, then I'd look more closely at NetDrive.
31 Likes
Replacing RemoteDrive with another mounted-drive app may not fix the underlying problem. Finder and editors constantly create previews, metadata, and temporary files, which can make remote mounts flaky. CloudMounter is worth testing, but for maximum stability I’d use a normal SFTP client, edit locally, then upload or sync changes instead of opening files directly on the server.
If your main use is editing code, I’d skip mounted drives entirely and use an editor with built-in SFTP deployment or sync. That avoids Finder touching every remote folder and usually handles reconnects more cleanly. CloudMounter still makes sense when several apps need access to the same remote files, but no mount tool can make a slow or unstable server behave like a local disk.
Do not trust any remote-drive replacement with live files until you’ve tested what happens when Wi-Fi drops mid-save. Some apps reconnect cleanly, while others leave a zero-byte file, a conflicted copy, or a change that appears saved locally but never reaches the server. That failure behavior matters more than whether the drive stays mounted for eight hours.
CloudMounter and Mountain Duck are reasonable replacements if Finder integration is mandatory, but I’m skeptical that switching brands alone will cure this. They still sit between Finder, the remote protocol, and whatever application is editing the file. File locking, caching, sleep/wake cycles, and server timeouts can break that chain. I would avoid working directly from any remote mount with Git repositories, databases, large design files, or anything that performs frequent background writes.
A cheaper route that hasn’t been mentioned is rclone mount. It supports many remote storage types and can present them as a mounted filesystem, though setup is much less friendly and macOS may require an extra filesystem component. It’s worth considering if you’re comfortable with the command line and would rather have control over cache settings and reconnect behavior than a polished interface.
Before paying for anything, make a disposable test folder and try your normal workflow: edit a file, rename a folder, put the Mac to sleep, disconnect the network during a save, then reconnect. If the mount passes those tests, it’s a candidate. If it doesn’t, @hacknerd7’s local-edit-and-sync approach is the safer answer, even if it’s less convenient. For plain transfers, a regular SFTP client or rsync over SSH will usually be far less fragile than pretending a remote server is a local disk.
Do not assume a mounted FTP or SFTP drive will preserve permissions, symlinks, case sensitivity, and atomic renames exactly like a local disk. That mismatch can cause subtler damage than a crash, especially with scripts, web deployments, and Git working trees.
If you control the server, the more reliable replacement may be changing the protocol rather than changing apps. An SMB share reached through a VPN gives macOS a real network-filesystem interface instead of making an FTP server pretend to be one. It will still depend on latency, but file operations and reconnect behavior are generally more predictable.
If the server only offers SFTP, Mountain Duck is probably the closest straightforward replacement. I would use the mounted drive for browsing and occasional copies, then use rsync or a regular SFTP client for important uploads. That split is less convenient, but @hacknerd7 is right that direct editing through a mount introduces several failure points.
Whichever route you choose, test executable permissions, symlinks, files that differ only by letter case, and folder renames. A replacement that stays connected but quietly changes those is not really stable.
If the crashes always hit during the same action, like a save or a folder listing, that tells you more than any brand swap will. CloudMounter is a fair thing to trial for the mount side, but I lean toward @hacknerd7 here: for anything you’d hate to lose, edit local and push it up, and keep the mount for browsing.
Do not assume Time Machine or your editor’s recovery files will protect work opened directly from a remote mount. If the connection fails during a save, there may never be a complete local copy for either of them to recover.
That is the biggest difference I’d use when comparing replacements. CloudMounter and Mountain Duck are mainly competing on how convincingly they behave like a Finder drive. A local-mirror setup competes on something more useful: every edit first lands on your Mac, where normal backups, Git, autosave, and recovery tools can see it. The server copy is updated afterward.
For code or documents, I’d keep a local working folder and use an SFTP synchronization tool, an editor deployment feature, or a small rsync script. That is less seamless than opening /Volumes/server/project, but it makes connection loss an upload problem instead of a file-loss problem. Be careful with automatic two-way sync, though. A mistaken remote deletion can be copied locally just as efficiently as a valid change. Start with one-way uploads or require confirmation for deletions.
If you absolutely need several applications to see the same remote filesystem, Mountain Duck is probably the closest direct substitute. When comparing it with CloudMounter, I’d ignore how quickly each one mounts and look at offline caching, conflict handling, and whether pending uploads are clearly visible. A drive that remains in Finder while quietly holding an unsent save is worse than one that disconnects loudly.
@dilit25008’s network-drop test is useful, but I’d extend it by checking recovery too: save a file, cut Wi-Fi before the upload finishes, restart the Mac, and see whether the application can tell you exactly what is still local and what reached the server. That result would decide the replacement for me more than protocol count or interface polish.
Before you buy anything, check whether the drops line up with sleep/wake or your network going idle, because that’s a common cause and no new app fixes it. CloudMounter’s trial is fine for ruling the app in or out, but if the server or your Wi-Fi is the real problem, you’ll just be paying to watch the same disconnects with a different logo.
Don’t run RemoteDrive and its replacement against the same folder during testing. Two clients can cache listings, renew connections, and upload temporary files differently, which makes it impossible to tell which app caused the problem.
I’d handle the switch in this order: copy current work locally, disable RemoteDrive at login, reboot, then trial Mountain Duck or CloudMounter with a disposable server folder. Use the same SFTP account and authentication method you normally use. Check that reconnecting after sleep does not trigger another password or SSH-key prompt, since failed background reauthentication can look like a random dropped mount.
If the trial survives a few normal work sessions, move over gradually rather than pointing it at every project immediately. Keep important files local until you have confirmed that queued uploads are visible and failed transfers produce an obvious warning. Between the two, Mountain Duck is probably the more direct RemoteDrive replacement, but I would choose whichever makes unsent changes easiest to spot. A silent upload queue is a worse problem than a drive that visibly disconnects.
Skip remote-drive mounting entirely. Use VS Code with an SFTP extension and keep the project in a normal local folder. Set the server path once, then upload selected files from the editor after saving. Enable local autosave and Git commits every hour.
This removes Finder mounts, reconnect loops, and temp-file issues. Your work stays on disk even if SFTP drops mid-upload. Start with one test folder. Check the extension’s upload setttings and exclude.git, backups, and secrets. For most editing jobs, this setup takes 10 minutes and needs fewer moving parts.