I have just spent two days trying to get a file manager that works for me on my Mac Studio, now running Golden Gate. Golden Gate broke drag and drop in ForkLift 3. I had used ForkLift 4, but it kept crashing, and also never fixed the file path breadcrumbs for a year.

So, I was stuck, and tried every solution (I think). I manage multiple Web sites and it is essential to me to get sftp connections to these ISP hosts. If you do not require remote mounts, use Finder.

The Case of the Glacial File Manager: Why Mounting SFTP as a Virtual Disk Brought My Mac to Its Knees

If you are a Mac power user who manages large media libraries across multiple local disks and home Linux servers, you know the holy grail: a single, clean, multi-pane file manager where you can see your local SSDs, external backup drives, and remote server volumes side-by-side, dragging and dropping files with effortless speed.

For years, I had a workflow that just worked in ForkLift: fast, multi-threaded SFTP transfers running simultaneously across local and remote disks without breaking a sweat.

Then, after exploring modern multi-pane managers like QSpace Pro and pairing them with Mountain Duck to make my remote SFTP servers look like local drives, things went from modern bliss to an agonizing crawl.

This is the story of how copying a 2.68 GB lossless music album escalated into 733% CPU utilization, 11 GB of leaked RAM, a frozen UI, and a deep architectural lesson in why virtual network mounts are often the wrong tool for heavy file transfers.

1. The Setup: The Quad-Pane Dream

My music setup involves syncing high-resolution FLAC recordings between multiple destinations:

• Local Source: A fast Samsung T7 portable SSD (fresh audio recordings).
• Local Target: A 30TB desktop DAS array (30TB > Music).
• Remote Targets: A local Linux home server (jarfx) housing two separate storage pools: /lc/Music (Lossless Classical) and /data/Music.

In QSpace Pro, I configured a gorgeous 4-pane 2×2 grid:

1. Top-Left: jarfx - Music (data)
2. Top-Right: jarfx - Music (lc)
3. Bottom-Left: T7 > Audiohijack
4. Bottom-Right: 30TB > Music

To populate those top two panes, I used Mountain Duck, which connects to jarfx over SFTP and mounts the remote directories into macOS as virtual drives. To macOS, they look just like any other local folder.

Everything looked ready. I dragged the new music folder  (17 tracks, 2.68 GB) — into the destination pane.

Then, the freeze began.

2. The Symptom: Glacially Slow (Again)

The transfer progress window popped up:

• Copying "Simpson, Christopher"... 448.4 MB/2.68 GB — About 9 minutes
• Copying "Simpson, Christopher"... 557.5 MB/2.68 GB, 12.6 MB/s — About 3 minutes
• Copying "Simpson, Christopher"... 0 bytes/2.68 GB

Wait. Three simultaneous tasks copying the exact same folder?

The file manager’s UI locked up. Blank skeleton placeholders appeared in the local panes. The transfer speeds choked down to a trickle, and my Mac Studio’s fans began spinning up.

In ForkLift, three concurrent transfers used to fly at line rate without hesitation. Why was this setup grinding my Mac to a halt?

3. The Autopsy: What Was Actually Happening Under the Hood

Opening Terminal to investigate with lsof, top, and system logs revealed a cascade of compounding failures.

Culprit A: The Accidental Mouse Drop

In multi-column views, dropping a folder requires hitting open white space. When I dragged Simpson, Christopher toward the top-right pane (jarfx - Music (lc)), the mouse released over the very first folder in the alphabetical list: an ensemble named ¡Sacabuche!.

Instead of landing in /lc/Music/, the entire 2.68 GB folder was dropped inside ¡Sacabuche!.

Because it didn’t appear where I expected in the directory list, I dragged it again — this time into /lc/Music/. And then into /data/Music/.

Now, three massive transfer operations were running concurrently against the same server.

Culprit B: The Mountain Duck Lock Contention

Because Task 1 and Task 2 were writing to the exact same remote filesystem through Mountain Duck at the exact same moment, Mountain Duck’s internal worker threads (Jukebox-1 through 5) began colliding.

A glance at mountainduck.log revealed thread warfare:

Threads were deadlocking waiting for each other to release file locks on identical FLAC files.

Culprit C: The 733% CPU & 11 GB RAM Spiral

Mountain Duck is a Java-based application. When multiple multi-gigabyte transfers collided under heavy lock contention, its heap exploded.

Running top revealed a horror show:

• Process: Mountain Duck
• Memory: 11 GB resident RAM (plus 3 GB in macOS compressed swap)
• CPU: 733% CPU (7+ full CPU cores pegged!)
• Active Threads: 10 concurrent Shenandoah Garbage Collector threads running non-stop, fruitlessly trying to reclaim memory.

Culprit D: The Kernel NFS close() Trap

Why did the file manager UI freeze completely?

Mountain Duck presents remote SFTP servers to macOS as local virtual NFS mounts. Under macOS, writing to an NFS mount enforces close-to-open cache consistency.

When a file manager writes a file to an NFS drive, the moment it finishes and calls the POSIX close() system call, the macOS kernel completely halts that calling thread until the remote server acknowledges that every single byte has been physically committed over the network.

Because QSpace Pro dispatches file tasks over a serial queue, every 200 MB FLAC file caused the entire app's task manager to freeze solid while waiting for the network acknowledgement.

Culprit E: NAT Hairpinning over Wi-Fi

To top it off, the Mountain Duck bookmark pointed to a dynamic DNS address (jarfx.dyndns.org). Even though the server sat in the same room on my local network (10.0.0.2), my Mac was routing outbound over Wi-Fi to my cable modem's external public WAN IP, and the router was looping the packets back in via NAT reflection.

This capped transfers to residential cable upload speeds (~12 MB/s) instead of local Gigabit/10G LAN speeds (~115 MB/s).

4. The Path Finder Detour: "sftp was invalid"

Frustrated, I decided to test Path Finder 26.

I pressed Cmd + K (Connect to Server) and tried entering sftp://jar@10.0.0.2.

macOS immediately pushed back:

"URLs with the type 'sftp:' are not supported." (or "sftp was invalid")

When I tried browsing discovered network servers, a dialog popped up asking:

"Select the volumes you want to mount on localhost_prl.local.:" Listing: Iron24, MacHD2, MacHD3, MacHD4, MacWD16...

None of these were on jarfx! What was going on?

1. localhost_prl.local was Parallels Desktop: prl is Parallels Desktop looping back to 127.0.0.1. It was advertising my own Mac's hard drives to a Windows VM over SMB.
2. jarfx doesn't run SMB: My Linux box only runs SSH/SFTP on port 22; it doesn't run Samba.
3. Apple's NetFS limitation: Path Finder delegates Cmd + K directly to macOS's native NetAuthAgent. Apple has never supported SFTP in Finder's native "Connect to Server" dialog (it only supports SMB, NFS, and AFP).
4. Path Finder's PFSftp module: While Path Finder has libssh2 compiled into its helper frameworks, it is only an internal one-way backup/sync utility (alongside S3 and Dropbox plugins), not an interactive dual-pane SFTP browser.

5. Why ForkLift Got It Right All Along

This entire ordeal brought me back to the realization of why ForkLift never suffered from this:

ForkLift doesn't pretend remote servers are local hard drives. It treats SFTP as a network protocol, opening direct parallel streams into an Activity Manager that never touches OS-level filesystem locks.

Fixing the Lost ForkLift Connection

Why had I stepped away from ForkLift in the first place? Four days earlier, ForkLift 3 had refused to connect to jarfx.

The cause turned out to be comical: in ~/.ssh/known_hosts, line 79 had accidentally received a pasted SHA256 fingerprint hash (SHA256:2BD...) instead of an encoded public key. Strict SSH clients like ForkLift's parser choked with:

parse error in hostkeys file

One simple command to delete the bad line:

...and ForkLift 3 authenticated instantly.

6. Key Takeaways for Mac Power Users

1. Virtual Drives
   $\mathrm{\ne }$
   $=$ Bulk Transfer Tools: Tools like Mountain Duck and CloudMounter are wonderful for browsing remote directories, opening a script, or editing a document. But when syncing multi-gigabyte media batches, virtual NFS/FUSE file system layers add immense CPU/RAM overhead and kernel-level thread blocking.
2. Use Dedicated SFTP Clients for Big Data: For multi-GB audio or video transfers, dedicated transfer engines (ForkLift, Cyberduck, or good old rsync -avP) stream directly across raw network sockets, keeping memory tiny and throughput maxed out.
3. Beware the "First Folder" Mouse Drop: In column or list views, always be cautious when dropping large directories across panes. It is shockingly easy to nest an entire collection inside the top folder (¡Sacabuche!) by accident. When using dual-pane managers, the classic keyboard shortcut (F5 or Cmd + C
   $\to$
   Cmd + V) is vastly safer than mouse dragging.
4. Always Connect via Local IP: Never use an external DDNS hostname (dyndns.org) when your server is sitting on the same switch or Wi-Fi network. Routing via local IP (10.0.0.x) bypasses your router's NAT reflection and jumps your speeds from 12 MB/s to 115 MB/s.

Sometimes the old, dedicated tools really are the best tools. ForkLift 4 (hopefully fixed) is back in its rightful place on my dock.