VNC with File Transfer: Which Viewer and Server Pairs Actually Move Files

The VNC protocol has no file transfer. Every product that offers it bolts on its own, so files usually move only when your viewer and server come from the same family: TightVNC to TightVNC on Windows, UltraVNC to UltraVNC, RealVNC Viewer to RealVNC Server on a subscription that includes it, and Screen Sharing between two Macs. The main cross-family pair that works is x11vnc started with -ultrafilexfer and UltraVNC Viewer. TigerVNC has no transfer at all, and neither does the Linux TightVNC server. There, you copy files with scp or sftp over the same SSH login you already tunnel VNC through.

Why a mixed pair usually won't transfer

Point a viewer at a server from another VNC family and you get the desktop, the keyboard and the mouse, but usually no transfer. RFB, the protocol they share, only carries the screen, your input, a bell and clipboard text, and a server may only use anything beyond that once the viewer has said it understands it. Each vendor wrote its own transfer on top: UltraVNC's is message type 7, TightVNC's lives in its Tight extension, and those enhancements only work when both sides support them. Pointed at a server that doesn't identify itself as UltraVNC during the handshake, UltraVNC Viewer's File Transfer just answers The connected VNC Server doesn't support UltraVNC File Transfer!

Which pairs transfer files, and how to switch it off

Supporting Windows desktops where you run the server anyway? Use the matching pair's dialog; UltraVNC also moves whole folders and compresses them on the way. Moving files on and off Linux servers? Don't chase a VNC transfer at all. scp works whatever viewer you use, as long as you can SSH in.

To see what a Windows server allows right now, query its setting from an elevated Command Prompt on that machine. Run the line for the server you have:

reg query "HKLMSOFTWARETightVNCServer" /v EnableFileTransfers
findstr /i "FileTransferEnabled FTUserImpersonation" "%ProgramData%UltraVNC\ultravnc.ini"
reg query "HKLMSoftwareRealVNCncserver" /v ShareFiles
reg query "HKLMSoftwareRealVNCncserver" /v ClipboardFT

TightVNC's transfer is off when reg query shows 0x0, and UltraVNC's when findstr shows FileTransferEnabled=0. For RealVNC, each of its two values shows FALSE or 0 when that route is closed: ShareFiles for the File Transfer window, ClipboardFT for Windows copy and paste. A missing value or line means the default, which is on everywhere. Those paths are for TightVNC and RealVNC running as a service and for current UltraVNC releases; an older UltraVNC keeps ultravnc.ini in its install folder. A RealVNC value set by policy under HKLMSoftwarePoliciesRealVNCncserver overrides the one shown here.

Send files with TightVNC on Windows, or lock it down

In TightVNC Viewer, click Transfer files… on the toolbar or press Ctrl+Alt+Shift+E. Local Computer (Viewer) is on the left and Remote Computer (Server) on the right: select a file and click >> to upload it or << to download.

When the dialog won't move anything, it's usually one of these:

• The server runs as a service and the remote desktop is locked or sitting at the sign-in screen. A service-mode server refuses transfers unless it's on the normal desktop, and logs a line starting Access denied to the file transfer: with the reason after it. Sign in at the remote end first.
• You logged in with the view-only password. View-only sessions get no transfer.
• The server's desktop is an RDP session and the release is older than 2.8.81. That release fixed transfers being disabled in RDP sessions.

As a service, the server runs each transfer as the signed-in Windows user, so anyone with the full-control password can read and write that user's files. Run something current, too: before 2.8.75, an attacker could swap in crafted files during a transfer and escalate privileges on the host (CVE-2023-27830).

To switch transfer off on a server running as a service, set the registry value and have the running server reload. In an elevated PowerShell:

reg add "HKLMSOFTWARETightVNCServer" /v EnableFileTransfers /t REG_DWORD /d 0 /f
& "$env:ProgramFilesTightVNC\tvnserver.exe" -controlservice -reload

-reload pulls the settings back in from the registry but prints nothing, so run the TightVNC reg query line from the check above and make sure it shows 0x0. The server looks at the setting on every transfer request, so viewers that are already connected lose the transfer without being dropped. If TightVNC Server runs in application mode instead, its settings live under HKCU and the command takes -controlapp.

Send files with UltraVNC, and keep them off SYSTEM

In UltraVNC Viewer, click Open File Transfer… on the toolbar, or pick File Transfer… from the context menu or press Ctrl+Alt+F7.

On the server it comes down to two lines in the [admin] section of ultravnc.ini. Current releases, 1.8.3.0 included, have the service read it from %ProgramData%UltraVNC. On first run the service copies an older ultravnc.ini there from the install folder, and from then on the copy left in the install folder isn't read, so edit the one in %ProgramData%. Editing it there takes an elevated editor. If a line is missing, it defaults to 1, so transfer is on out of the box:

[admin]
FileTransferEnabled=0
FTUserImpersonation=1

FileTransferEnabled=0 turns transfer off. Keep FTUserImpersonation=1 whatever you do with the first line. At 0, transfers run as SYSTEM, which can't see mapped drives and lets a normal user transfer files as admin. If someone can't reach their Z: drive from the transfer window, look at this line first. In the server's properties, the same switch is the Enable box under File Transfer.

A hand edit to the file only counts after the server restarts. For the service, from an elevated Command Prompt:

net stop uvnc_service
net start uvnc_service

The next viewer that connects gets the new setting.

Send files with RealVNC Viewer and RealVNC Server

RealVNC only transfers between its own viewer and server on desktop platforms, and only if your subscription includes File Transfer. The Android and iOS apps don't have it. Click File Transfer on the viewer toolbar. In v8 you get Local Device and Remote Device side by side. Pick one file or folder and click Transfer to Remote or Transfer to Local, or drag it across, but only into a folder that's already open on the other side. Dropping it on a folder's name does nothing. The Transfer Queue tab shows progress.

The server has two separate switches; set each to FALSE under Options > Expert. ShareFiles closes the File Transfer window and takes effect when you click Apply. ClipboardFT closes the Windows-to-Windows copy-and-paste route, and only takes effect after RealVNC Server restarts. Turn off both to stop file exchange completely.

To take transfer away from one user instead, edit their entry in the existing Permissions list rather than replacing the list, so it reads along the lines of Permissions=%<group>:d,<user>:d!t. The !t explicitly denies file transfer, and a deny can't be overridden. A plain d-t only disallows it, and the group's d would grant it straight back to a member. RealVNC ignores Permissions when Authentication is set to VncAuth.

Drag files between two Macs

In a Screen Sharing session, drag a file or folder from your Mac into the Screen Sharing window to copy it across, or drag one out of the window into a folder on your Mac to copy it back. For text and images, turn on Edit > Use Shared Clipboard.

No transfer in your pair: copy over SSH instead

TigerVNC has no file transfer in its viewer or its server. It's been an open feature request since 2016. Its clipboard moves text both ways, on by default through the viewer's -SendClipboard and -AcceptClipboard, and stops there. The Linux TightVNC server is the same story: in the 1.3.10 code Debian still packages as tightvncserver, the transfer capabilities sit commented out as "future file transfer support".

You don't need them. If you reach the desktop through a tunnel like ssh -N -L 5901:localhost:5901 <user>@<server-host>, the same login copies files. That terminal is busy holding the tunnel, so open a second one on your workstation. Push a file to your home directory on the server, then pull one back:

scp ./<file> <user>@<server-host>:~/
scp <user>@<server-host>:~/<file> .

scp logs in exactly like ssh, with the same keys or password, and shows a progress meter while it copies. Add -r for a directory. If sshd listens on another port, scp wants a capital -P, because lowercase -p preserves file times.

For a batch of files, or when you need to look around before you copy, start an interactive session and use get and put once it's connected:

sftp <user>@<server-host>

x11vnc: UltraVNC transfer from a Linux desktop

If someone on Windows really needs the UltraVNC transfer window against a Linux desktop, x11vnc can offer it. -ultrafilexfer is shorthand for -rfbversion 3.6 -permitfiletransfer, and RFB 3.6 is one of the versions UltraVNC Viewer reads as "this server is UltraVNC, offer File Transfer". Like any x11vnc setup it needs an Xorg login, not Wayland.

On the host, as the desktop user, store a VNC password first. x11vnc asks for it twice, offers to write it to ~/.vnc/passwd, and confirms with Password written to: and the path:

x11vnc -storepasswd

Then start the server from a terminal on that desktop. With no -display, x11vnc takes the display from $DISPLAY, so it shares the session you're in rather than assuming :0, which on a GDM machine is usually the login screen:

x11vnc -localhost -rfbauth ~/.vnc/passwd -ultrafilexfer -forever

Keep -forever. Without it, x11vnc exits as soon as the first viewer disconnects, so the second try finds nothing listening. x11vnc stays in the foreground, so leave that terminal open. From a second terminal on the host, check the greeting:

timeout 2 bash -c 'head -c 12 < /dev/tcp/localhost/5900'

It prints RFB 003.006. Without the flag you'd get RFB 003.008, and UltraVNC Viewer won't offer a transfer.

-localhost keeps port 5900 on loopback, so the Windows side comes in through a tunnel. In PowerShell on the Windows machine, with its OpenSSH client installed, pick a free local port and leave this running:

ssh -N -L <local-port>:localhost:5900 <user>@<server-host>

Then point UltraVNC Viewer at localhost::<local-port>; the double colon means a port, as in UltraVNC's own hostname::5900 example.

Two catches. Started as root without -users, x11vnc lets every viewer read and write files as root. And the transfer code is libvncserver's reimplementation, not UltraVNC's, so try it on a throwaway file before you rely on it. Skip -tightfilexfer: the Ubuntu 24.04 and Debian 13 packages are built without it, so the flag is accepted and nothing transfers.

Treat transfer as access you hand out. On every server where nobody needs it, switch it off with that server's setting, then rerun its check so the value reads what you meant.

FAQs

Can I copy a file through the VNC clipboard?

Not through RFB's clipboard. The Extended Clipboard extension lets a viewer and server swap UTF-8 text, RTF, HTML and bitmaps, but its files format is reserved and still undefined. The exception is RealVNC, where copy and paste moves files when both ends run Windows.

Is a VNC file transfer encrypted?

It travels inside the VNC connection, so it's exactly as protected as the session. TightVNC protects only the password check and sends the rest of the traffic unencrypted, your files included. Tunnel the session through SSH, or on UltraVNC add its DSM encryption plugin.