Fix Symlinks Not Working on an SFTP Mount — NetDrive

A deploy directory on your SFTP server keeps a current symlink pointing at whichever release folder is live — current → releases/20260821-1. It’s a standard pattern for zero-downtime deploys, and it’s exactly the kind of thing that breaks quietly the first time you point NetDrive at that server. The link shows up as an empty file, a broken shortcut, or doesn’t appear at all, and a script that expects S:\current\config.yaml to just work suddenly doesn’t.

Mount SFTP Servers With Working Symlink Support

NetDrive lets Google Drive, OneDrive, S3, SFTP, WebDAV and more appear as native drives on Windows and macOS — no syncing, no full downloads.

• Symlinks resolve correctly on SFTP mounts, version 3.17.817 and later
• Password or SSH key authentication
• Available on Windows, macOS, and the experimental Linux build

WindowsmacOS

Download NetDrive →

Free trial. Lifetime and subscription plans available.

Check the Version First

NetDrive added symlink support for SFTP connections in version 3.17.817 (2023-01-07). On any build before that, a symlink on the server has no equivalent on the mounted side — it may not appear, or it may show up as a zero-byte file instead of pointing at its target. This is the single most common cause of “my symlinks don’t work” reports, and it’s worth ruling out before you touch anything on the server.

To check your installed version, open NetDrive’s Drive Manager, click the NetDrive icon (system tray on Windows, menu bar on macOS), and open About NetDrive. If the version string reads anything older than 3.17.817, update before continuing — the current release is 3.19.7, available from netdrive.net/download.

Already on 3.17.817 or Later? Check the Link Itself

If the version isn’t the problem, the symlink’s own configuration usually is. Work through these from the server side, over a regular SSH session:

• Absolute vs. relative targets. A relative symlink (current → releases/20260821-1) resolves against its own directory and generally travels well through a mount. An absolute symlink (current → /var/www/app/releases/20260821-1) only resolves correctly if that exact absolute path also exists and is reachable from the SFTP account’s own view of the filesystem — which isn’t guaranteed if the account is chrooted to a subdirectory.

  # Run this on the server to see how the link is defined
  ls -la /var/www/app/current

• A target outside the SFTP account’s root. Some servers restrict SFTP users to a chroot jail rooted at their home directory or a specific path. A symlink pointing anywhere outside that root is invisible to the SFTP session — and therefore to NetDrive — no matter what NetDrive version you’re running. Confirm the target path falls inside the same root the SFTP account is scoped to.

• A dangling target. If the release directory a symlink points to was deleted or renamed (a half-finished deploy, a cleanup script that ran early), the link itself is fine but has nothing to resolve to. ls -la on the server will show the link in a different color or flag it as broken, depending on your shell configuration.

• Permissions on the target, not just the link. The symlink file itself might be readable while its target directory has permissions that block the SFTP account. Check both.

Confirming the Fix Through the Mount

Once you’ve ruled out the version and confirmed the link is relative, in-root, and pointing at something that exists, reconnect the drive in NetDrive (right-click the connection in Drive Manager and choose Reconnect, or disconnect and connect again) and check the mounted path directly:

# Windows PowerShell — replace S: with your assigned drive letter
dir S:\current

# macOS / Linux Terminal
ls -la /Volumes/sftp-mount/current

If the target folder’s contents now list correctly, the symlink is resolving. If it still shows as empty or missing after confirming both the version and the link’s own validity, the remaining variable is usually server-side SFTP subsystem configuration — specifically whether the server’s sftp-server process has symlink traversal disabled, which is a server administrator question rather than a NetDrive setting.

Wrap-up

Symlink handling on an SFTP mount comes down to two independent things: whether your NetDrive build supports it at all (3.17.817+) and whether the link itself is valid from the SFTP account’s point of view. Check the version first — it’s the faster fix — then work through the link’s target before assuming NetDrive is at fault. For broader SFTP connection issues, see Fix SFTP Authentication Failures in NetDrive, and for initial setup, Mount an SFTP Server on Windows.

— Morgan, NetDrive