Moving a file to a Linux server from a Mac sounds like a one-command task. In practice, the right workflow depends on what happens around the transfer: whether you need repeatability, visual confirmation, remote editing, or a terminal open beside the files.
There are three sensible approaches. None is universally best.
1. Use the built-in sftp command
macOS already includes the OpenSSH SFTP client. For a quick transfer, the command line has the smallest setup cost:
sftp -i ~/.ssh/id_ed25519 deploy@example.com
Inside the session, put, get, ls, cd, and lcd cover the basics. It also supports jump hosts, alternate SSH config files, recursive transfers, resuming partial transfers, and batch mode.
The CLI is usually the right choice when:
- the transfer belongs in a script or runbook;
- you already know the exact remote path;
- the same command should be repeatable in CI or from another machine;
- you want the full behavior of your OpenSSH configuration.
Its weakness is not capability. It is context. When you are comparing several local and remote files, checking timestamps, or moving a group of items between changing directories, remembering which side of the session each path refers to becomes the work.
2. Mount the server as a drive
A mounted workflow makes the remote directory appear in Finder. This is useful when the remote files should behave like ordinary Mac files and several local apps need to open them.
Finder's built-in Connect to Server documentation lists SMB, NFS, FTP, and WebDAV, but not SFTP. An SFTP mount therefore needs an additional tool or filesystem layer.
A mount is a good fit when:
- the remote directory should stay available for a long working session;
- Finder, an IDE, and other apps all need access to the same files;
- browsing is more important than seeing individual transfer jobs;
- the connection is stable enough to behave like a filesystem.
The trade-off is that network failure now appears as filesystem behavior. Sleep, reconnects, caching, and partial writes deserve more attention than they do in an explicit upload/download workflow. For production configuration files, it is worth confirming how the mount handles interrupted saves and conflicts before relying on it.
3. Use a dual-pane SFTP client
A dual-pane client keeps the local and remote directories visible at the same time. Transfers remain explicit jobs instead of being hidden behind filesystem operations.
This model works well when:
- you regularly move groups of files between a project folder and a server;
- you want visible progress, cancellation, and conflict handling;
- remote editing needs to upload the saved file back to the correct path;
- you switch between terminal commands and file operations on the same host.
The main cost is another interface to learn. It is also less suitable than the CLI for automation, and less transparent than a mount when many unrelated Mac apps need continuous access to the remote tree.
A practical way to choose
| Situation | Best starting point |
|---|---|
| One file, known path | Built-in sftp
|
| Scripted or repeatable transfer |
sftp batch mode, scp, or rsync
|
| Remote files should behave like a Mac drive | SFTP mount |
| Frequent visual upload/download work | Dual-pane SFTP client |
| Terminal and remote files are used together | SSH client with integrated SFTP |
I keep the CLI available even when using a GUI. A good desktop client should shorten repetitive work, not make the underlying protocol mysterious.
Where Nexus Shell fits
I develop Nexus Shell, a native macOS SSH client. Its file view uses the third model: local and remote directories side by side, drag-and-drop and multi-select transfers, visible transfer progress, conflict handling, remote editing, and a terminal for the same saved server.
It is deliberately Mac-only and requires Apple Silicon with macOS 14.2 or later. If you need cross-platform clients, a Finder mount, or a workflow that can be fully scripted, one of the other approaches above is likely a better fit. The Free tier covers basic personal SSH use; creating an account includes a seven-day Pro trial for testing the complete file workflow.
Sources: Apple Terminal User Guide, Apple's supported Finder server types, and the macOS sftp(1) manual.
Top comments (0)