你在 Mac 上复制一个文件，切换到 Windows 会话，却发现“粘贴”是灰色不可用。或者你在 Ubuntu 上选中一个文件，按下 Ctrl+C，文本能够传到远程机器，但文件始终未到达。这两种现象都不意味着你把设置弄错了。远程桌面在一个通道上传输剪贴板数据，在另一个通道上重定向驱动器；对剪贴板中文件的支持因客户端和版本而异，而且有些远程操作系统根本不提供文件通道。请查看下面的途径，排列顺序按其解决问题的频率高低。
当阻断发生在你不负责管理的机器上，或远端运行的操作系统不提供 RDP 主机时，HelpWire 是一种绕过它的方法。它是一款用于 IT 支持工作的远程访问软件，其文件传输在其自身的会话中进行，而不是通过 RDP，因此此处描述的任何重定向层都不适用于它。操作端和客户端应用均可在 Windows、macOS 和 Linux 上运行，这使其适用于本文中的每一种操作系统组合。
快速回答：哪种路径适用于你的操作系统组合
跨平台文件传输有一个决定性变量，而这个变量并不是你面前的机器。远程机器会在你尚未更改任何设置之前就决定是否存在文件通道，所以请在表格中找到与你对应的配对，并前往表中所指示的章节。
| 您使用的是 | 远程为 Windows | 远程为 macOS | 远程为 Linux |
|---|---|---|---|
| Windows | 在 mstsc.exe 中进行驱动器重定向，或使用 \\tsclient。详见我们的 远程到本地 和 本地到远程文件传输 指南。 |
macOS 上没有 RDP 主机。使用 scp 通过远程登录，或使用 SMB。 |
在 xrdp 中进行驱动器重定向，或 scp 在安装 OpenSSH 客户端后使用。 |
| macOS | 在 Windows 应用的 文件夹 选项卡中进行文件夹重定向。 | 在 Apple 的 屏幕共享 应用中拖放，仅限 Mac 之间。 | 将文件夹重定向到 xrdp，或 scp 和 rsync 在终端中。 |
| Linux | /drive: 在 xfreerdp3 中使用，或在 Remmina 中使用共享文件夹。从 FreeRDP 3 开始支持通过剪贴板复制文件，但 Remmina 不支持。 |
macOS 上没有 RDP 主机。使用 scp 通过远程登录，或使用 SMB。 |
scp 或 rsync。若已打开 RDP 会话，可进行驱动器重定向。 |
为什么跨平台文件传输在远程桌面上会失效
在 RDP 会话中，有两个彼此独立的通道用于传输数据，而剪贴板中负责移动文件的那一部分在不同客户端上的支持参差不齐，并且依赖于版本。第二个原因更简单，但更难以绕过。某些远程操作系统没有可连接的 RDP 主机，因此没有可用于驱动器重定向的目标。
剪贴板与驱动器通道之间的区别
剪贴板流量通过 CLIPRDR 通道，涵盖文本、图像和文件对象。驱动器重定向使用另一个通道 RDPDR，它在远程计算机上通过 \\tsclient 暴露本地卷。重要的区别不在于文本与文件，而在于客户端完整实现了哪个通道。 mstsc.exe 在 Windows 上同时实现了两者。macOS 上的 Windows App 也同时实现了两者，但当前存在一个缺陷，后文会提到。基于 FreeRDP 的客户端，包括 Remmina、xfreerdp、GNOME Boxes 以及大多数 Linux 前端，对剪贴板文本的处理较为可靠，而对剪贴板文件的处理则表现不一。
一份 Remmina 报告 用一句话概括了 2 版的行为：文本复制粘贴可双向工作，即使启用双向剪贴板，复制的文件也无法到达另一端的剪贴板，推荐的变通方案是使用共享目录。一则 Linux Mint 帖子 讨论了 FreeRDP 的文件复制问题，并将共享驱动器作为替代方案。该说法在 Remmina 上仍然成立，其 针对 RDP 插件的文件传输功能请求 仍处于打开状态。
FreeRDP 已有所进展。其 3.0.0-beta1 变更日志 记录了改进的剪贴板，支持从服务器到客户端的文件传输，当时仅在 xfreerdp 中提供，此后该功能一直得到维护。 版本 3.27.0 于 2026 年 6 月 修复了在 xfreerdp 会话之间复制同一类型多个项目的问题。本文发布时该版本为当前版本，此后该系列又发布了更多版本。因此，Linux 客户端无法通过剪贴板复制文件”的笼统说法已过时，请检查你的发行版所提供的版本。
工作原理
| 通道 | 它承载的内容 | 由什么决定是否可用 |
|---|---|---|
CLIPRDR 剪贴板 |
受支持的客户端上的文本、图像和文件对象 | 先取决于客户端能力，再取决于主机上的策略 |
RDPDR 驱动器重定向 |
一个本地卷或文件夹，可通过 \\tsclient\<name> |
在连接建立前设置的客户端选项，然后是主机上的策略 |
| 均无 | 什么也没有 | 远程操作系统没有 RDP 主机，因此不会协商任何通道 |
驱动器通道没有剪贴板大小上限，也不依赖于客户端对文件剪贴板的支持。这就是为什么重定向的文件夹几乎在任何地方都能工作，而剪贴板则是在没有错误消息的情况下会失败的方式。
文件通道是否存在由远程操作系统决定
macOS 不提供 RDP 主机。其 屏幕共享 服务是 VNC。RFB 核心协议未定义文件传输，尽管一些 VNC 产品为此添加了专有扩展，Apple 的服务器并未向第三方查看器提供任何此类功能。因此，连接到 Mac 的 Windows 或 Linux 计算机无论你勾选什么，都没有原生的传输途径。Windows 家庭版也没有 RDP 主机。
Linux 需要第三方主机，且两种常见方案在一个决定结果的方面存在差异。 xrdp 项目 列出了针对文本、位图和文件的双向剪贴板传输，以及将本地客户端驱动器挂载到远程机器上的驱动器重定向。GNOME 远程桌面（即 Ubuntu 24.04 及更高版本在 远程登录）没有驱动器重定向。 用户在从 xrdp 迁移后会立刻遇到这一点；在那里，他们的本地 Windows 驱动器无需任何设置就会出现。因此，同一台 Linux 桌面是否成功仅取决于一个变量，即其上安装的 RDP 主机。
每个客户端和主机可以做什么
| 客户端或主机 | 剪贴板文本 | 剪贴板文件 | 驱动器或文件夹重定向 | 设置所在位置 |
|---|---|---|---|---|
mstsc.exe 在 Windows 上 |
是 | 是 | 是，整个卷 | 本地资源 > 更多 > 驱动器 |
| Windows 上的 Windows 应用 | 是 | 是 | 是，但无法选择具体的驱动器或文件夹 | 界面中无相关控制项 |
| macOS 上的 Windows 应用 | 是 | 是，但在 macOS 26 上单向失效 | 是，仅限文件夹级别 | 编辑 > 文件夹 选项卡 |
| Remmina | 是 | 否，相关请求仍开放 | 是，一个文件夹 | 共享文件夹（在连接配置文件中） |
xfreerdp3 |
是 | 是，自 FreeRDP 3 起，且在构建时启用 WITH_FUSE |
是，一个或多个文件夹 | /drive:name,/path |
xrdp 作为 Linux 主机 |
是 | 是 | 是，挂载于 ~/thinclient_drives |
/etc/xrdp/sesman.ini |
| 作为 Linux 主机的 GNOME 远程桌面 | 是 | 是 | 否 | grdctl 或 设置 > 系统 > 远程桌面 |
如何将文件从 Mac 传输到 Windows 远程桌面
从 Mac 向 Windows 远程桌面会话传输文件的途径是使用重定向的文件夹：在连接之前于客户端中设置，然后在会话内将其作为复制的目标位置使用。macOS 客户端是在文件夹级别而非卷级别工作，这是与 mstsc.exe 的最大差异，也正是多数 Mac 用户在 Windows 指南中读到却始终找不到的 Drives 复选框的原因。
在 macOS 上的 Windows App 中重定向文件夹
-
关闭已打开的会话。在会话中途添加的重定向在重新建立连接之前不起任何作用。
-
打开 Windows 应用。
-
右键单击连接条目并选择编辑。
-
如果该条目来自已订阅的订阅源，请勾选使用自定义设置。
-
打开文件夹选项卡，并勾选重定向文件夹。
-
点击加号图标，选择要访问的文件夹，然后点击打开。对每个其他文件夹重复此操作。
-
如果不希望远程计算机写回，请勾选只读复选框，然后点击保存。
-
连接。
-
在会话中，打开文件资源管理器，在此电脑下查找文件夹名称，或按下
Win+R并输入\\tsclient。
要改为将同一个文件夹应用到每个连接，请打开Windows App > Settings > General，并在重定向选项下设置该文件夹，正如Microsoft 针对 macOS 客户端的文档所述。对于通过提要交付的受管理资源，Microsoft 表示重定向的文件夹始终是你的主目录，因此按连接的方式能为你提供更多控制权。
修复在 macOS 26 上从 Windows 复制到 Mac 的空文件
通过重定向的文件夹而不是剪贴板来移动文件。在 macOS 26 Tahoe 上，从远程 Windows 会话复制的文件到达 Mac 时名称和大小都正确，但没有内容，被零填充，且整个过程中未出现任何错误。该报告日期为 2025 年 11 月。那位 向 Microsoft 提交了该问题 的人测试了几乎所有 Windows App 版本，直到 11.2.9 (2810)，结果相同；同时，文本可双向传输，从 Mac 到 Windows 的文件复制也能正常工作。Sonoma 和 Sequoia 不受影响。另有一份 来自 Double Commander 的单独报告 也独立复现了该问题，粘贴得到的文件充满了空字节。在断定是剪贴板的过错之前，请先在你自己的构建上检查该行为。
-
确认症状，而不是方向。先从会话中复制一小段文本到 Mac，因为即使文件无法传输，文本通常也能完整到达，所以即使文本粘贴可用，也不能排除剪贴板的嫌疑。
-
检查粘贴的文件的内容，而不是它的名称。对它运行
ls -l，其大小看起来是正确的，这也是为什么该失败能在 Finder 中通过检查。 -
按照上述步骤设置一个重定向文件夹。这正是微软的回复者在同一帖子中推荐的变通方法。
-
在本次会话的其余时间内，通过重定向的文件夹进行双向复制，并将剪贴板用于文本。
-
如果策略阻止了文件夹重定向，请在 Windows 计算机上共享一个文件夹，并改为在 Mac 的 Finder 中使用
smb://将其挂载。
当文件夹列表一直为空，或者驱动器始终不出现时
四个独立的原因会导致列表为空或驱动器始终不出现，并且每种情况都需要采取不同的应对措施。
-
检查该连接位于哪个选项卡。位于Workspaces下的条目在 Mac 客户端中完全不提供任何重定向控件，这与位于 PCs下的条目不同。Microsoft Q&A 发帖者遇到了这个问题，并通过提要上的刷新按钮恢复了文件复制功能。
-
为客户端授予对您的磁盘的访问权限。打开 系统设置 > 隐私与安全性 > 文件与文件夹 并允许该应用，然后重新打开它。macOS 升级后出现的空文件夹列表 通常可追溯到此原因。
-
在应用中添加该文件夹，而不是在已保存的
.rdp文件中。一位向 Microsoft 报告此问题的用户尝试了drivestoredirect属性的三种语法形式，但都未能实现重定向，并且只有通过界面添加后该文件夹才会出现。Microsoft 在协议层面对该属性进行了文档说明，但未说明哪些客户端会在文件中支持它，因此在 macOS 上请将应用视为可靠途径。 -
在会话中，按下
Win+R并输入\\tsclient。一个可见的tsclient条目且其下没有任何内容，意味着客户端未请求任何文件夹，这正是当重定向从未生效时 Mac 用户所看到的情况。这是客户端侧需要修复的问题，而不是主机策略问题。
当剪贴板起初正常工作，但在会话中途停止工作
在 Windows 主机上关闭剪贴板历史记录。某位 Mac 用户在从客户端到主机的剪贴板传输会随机失效时 将其归因于主机端的该功能 而不是 Mac 上的任何问题。同一帖子指出，一旦你从主机复制一些内容回到客户端，该方向就会自行恢复。
-
在会话中，打开 设置 > 系统 > 剪贴板。
-
将剪贴板历史记录关闭。
-
从远程计算机复制一小段文本到 Mac 以重置方向，然后重试该文件。
在当前的 macOS 上，还有另外两个原因会产生类似的现象，而且都不在 Windows 主机上。Windows App 可以 使你要粘贴到的应用程序发生死锁，截至 2025 年 10 月那份报告时的当前版本尚无修复，pbcopy < /dev/null 可作为现场的变通办法。Mac 用户还报告 Cmd+C 在 Windows App 运行期间会在整个系统中失效，一旦退出该应用就会立即恢复。在更改 Windows 端的任何设置之前，先测试会话之外的复制是否可用。
当 Mac 是远程主机时的 Mac 远程桌面文件传输
Mac 远程桌面文件传输在此方向上没有重定向驱动器，因为 macOS 不提供用于创建它的 RDP 主机。Apple 的 Screen Sharing 服务采用 VNC 协议，而核心 RFB 协议未定义文件通道。Screen Sharing 应用确实支持在两台 Mac 之间拖放文件，这是 Apple 的扩展而非 VNC 的一部分，这也正是为什么在 Windows 或 Linux 上的 VNC 查看器中进行相同的拖拽不会有任何作用。
启用远程登录并通过 SSH 复制
-
在 Mac 上，打开 系统设置 > 通用 > 共享。
-
打开 远程登录。
-
点击Info按钮，并将Allow access for设置为需要访问的账户。请记下该设置下方显示的地址。
-
在 Windows PowerShell 中，上传一个文件：
scp C:\reports\q3.xlsx alice@192.168.1.40:/Users/alice/Documents/ -
在 Linux 终端中，使用相同的命令，但不包含盘符：
scp ~/reports/q3.xlsx alice@192.168.1.40:/Users/alice/Documents/ -
要拉取而不是推送，请将参数顺序反过来：
scp alice@192.168.1.40:/Users/alice/Documents/q3.xlsx.
从 Windows 或 Linux 访问 Mac 的共享文件夹
-
在 Mac 上，打开 系统设置 > 通用 > 共享，并打开 文件共享。
-
点击信息按钮，在 共享文件夹下添加该文件夹，并设置可访问该文件夹的用户。
-
在 Windows 中，按下
Win+R并输入\\192.168.1.40，然后使用 Mac 账户名及其密码进行身份验证。 -
在 Linux 上，挂载它：
sudo mount -t cifs //192.168.1.40/Share /mnt/mac -o username=alice
通过互联网时，将此路由置于 VPN 内。公共接口上的 SMB 不应对外暴露，而且在广域网链路上的文件传输速度无论如何都使 scp 或 rsync 成为更好的选择。
如何将文件从 Windows 传输到 Linux
有两种从 Windows 向 Linux 传输文件的方式，选择取决于是否已经打开 RDP 会话。如果你在命令提示符下，一旦安装了 OpenSSH 客户端，scp 就可以直接访问 Linux 机器。如果你已经在一个 xrdp 会话中，通过驱动器重定向无需借助第二个工具即可将文件传输过去。
从命令行进行 Windows 到 Linux 的文件传输
Windows 到 Linux 的文件传输 可在命令提示符下通过 scp 运行，这需要 Windows 端安装 OpenSSH 客户端。Windows 自版本 1809 起提供，但 Microsoft 将其在 Windows 10 1809 及更高版本中的默认状态标注为未安装，作为可选功能提供。只有 Windows Server 2025 随系统预装它。请先检查，若未安装则进行安装，并注意此方式会忽略所有 RDP 重定向策略。
-
确认客户端存在。在 PowerShell 中，运行
Get-Command scp，它会返回类似C:\Windows\System32\OpenSSH\scp.exe的路径。 -
如果该命令无法识别，请安装它。在以管理员身份运行的 PowerShell 提示符中：
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 -
在 Linux 机器上，确认服务器正在运行：
sudo systemctl status ssh -
复制单个文件：
scp C:\builds\app.tar.gz alice@192.168.1.60:/home/alice/ -
复制一个文件夹及其内容：
scp -r C:\builds alice@192.168.1.60:/home/alice/ -
在非标准端口上，请注意大写的 P：
scp -P 2222 C:\builds\app.tar.gz alice@192.168.1.60:/home/alice/
在较新的系统上，有一个协议细节容易让人出错。从 OpenSSH 9.0 开始，scp 在底层通过 SFTP 协议运行，而命令语法保持不变。对于仅支持传统 SCP 协议的旧服务器，请添加 -O 以强制采用原有行为。
通过驱动器重定向将文件推送到 xrdp 会话中
-
打开
mstsc.exe，然后单击 显示选项。 -
在本地资源选项卡上，单击更多。
-
展开 驱动器，勾选包含您的文件的驱动器，然后单击 确定。
-
单击连接并登录到 Linux 桌面。
-
在会话中打开一个终端并列出挂载：
ls ~/thinclient_drives -
将文件复制到此位置:
cp ~/thinclient_drives/DESKTOP-01/builds/app.tar.gz ~/
从 Linux 桌面到 Windows 的 Linux 远程文件传输
在 Linux 上向 Windows 主机进行远程文件传输要通过附加的文件夹，这是在不同 FreeRDP 版本和软件包构建之间都适用的唯一方法。将该文件夹附加到连接，然后在会话内通过 \\tsclient 进行复制。剪贴板在 FreeRDP 3 上可以传输文件，因此它更适合作为备选而不是首选。
使用 xfreerdp3 或 Remmina 共享文件夹
-
创建一个专用文件夹，这样你的整个主目录就不会被访问到：
mkdir -p ~/rdp-transfer -
连接时附加文件夹：
xfreerdp3 /v:192.168.1.20 /u:alice /drive:transfer,/home/alice/rdp-transfer +clipboard -
如果 shell 返回
command not found: xfreerdp，你的发行版以二进制版本化的方式构建了 FreeRDP 3，并重命名了可执行文件。请通过with ls /usr/bin | grep freerdp确认，并使用xfreerdp3，如FreeRDP 维护者的说明所述。 -
在 Remmina 中，打开连接配置文件，将共享文件夹设置为相同的路径，保存并重新连接。
-
在 Windows 会话中，按下
Win+R，然后输入\\tsclient\transfer。 -
将文件复制到远程计算机上的目标文件夹中。
不要添加 +drives 与 /drive:。当两者同时存在时，FreeRDP 会重定向 USB 卷以及 gvfs 挂载，并且 静默忽略指定的文件夹，这会导致会话看起来已启用重定向，但您的文件却无处可寻。
此处剪贴板可包含与不可包含的内容
xfreerdp 则从 FreeRDP 3 开始支持，通过一个必须在构建时编译进去的 FUSE 层实现。即便在可用的情况下，也存在边缘情形：一旦任一侧的剪贴板发生变化，进行中的传输会立刻中止， 于 2026 年 2 月针对 3.22.1 报告 且仍未关闭。共享文件夹没有这些行为，这也是它仍是主要途径的原因。当共享文件夹始终未出现
-
请先检查软件包格式。Snap 和 Flatpak 构建在沙盒中运行，无法读取任意路径。辅助二进制文件如果出现
error while loading shared libraries: libX11.so.6错误，表明您正在使用 Snap 构建。 -
请改为从发行版的软件包重新安装：
sudo apt install remmina remmina-plugin-rdp -
请将共享路径保留在您的主目录中，那里沙盒规则最不严格。
-
如果共享文件夹设置无法清除或保存，请编辑
~/.local/share/remmina/下的配置文件，并直接设置drive的值。较旧的版本无法通过界面禁用该选项。
如何在 Mac 与 Linux 机器之间移动文件
答案需要按方向来区分，因为两种情况中只有一种在远端有 RDP 主机。从 Mac 连接到 Linux 时，你可以使用与 Windows 相同的文件夹重定向。从 Linux 连接到 Mac 时，没有可重定向的目标，因此远程桌面层不起作用。
当 Linux 主机运行 xrdp 时，Mac 连接到 Linux
在 Windows 应用中像对 Windows 主机那样重定向一个文件夹，然后在 Linux 端查找它。xrdp 接受来自 macOS 的 Microsoft 远程桌面客户端，并将客户端重定向的任何内容挂载到 FUSE 路径下，因此，从 Mac 重定向的文件夹会出现在与 Windows 驱动器相同的位置。请进行验证，而不是想当然，因为挂载是可能失败的部分。
-
确认该 Linux 机器运行的是 xrdp，而不是 GNOME 远程桌面:
systemctl status xrdp -
按照上面的 Mac 到 Windows 部分中的步骤，在 Windows 应用中重定向一个文件夹。
-
连接后，在会话中打开终端，并运行：
ls ~/thinclient_drives -
将文件复制过去：
cp ~/thinclient_drives/MacBook/report.pdf ~/Documents/ -
如果路径为空，在对 Mac 进行任何更改之前，请先按照上面的 chansrv 步骤操作。
如果主机改为运行 GNOME 远程桌面，则不存在驱动器通道，且没有任何客户端设置会创建一个。对于那台机器，请在终端中使用 scp。
Linux 到 Mac 当没有可连接的 RDP 主机时
-
在 Mac 上，打开 系统设置 > 通用 > 共享 并开启 远程登录。
-
在 Linux 机器上，推送一个文件:
scp ~/report.pdf alice@192.168.1.40:/Users/alice/Documents/ -
对于你经常更新的文件夹，仅发送更改，并在连接中断时保留未完成的文件：
rsync -avP ~/project/
alice@192.168.1.40:/Users/alice/project/ -
要浏览而非复制，请在 Mac 上启用文件共享并挂载该共享：
sudo mount -t cifs //192.168.1.40/Share /mnt/mac -o username=alice
何时共享文件夹是正确的选择
一旦你要移动的文件不止寥寥几个，共享文件夹就胜过所有基于会话的方式；而在当前的 Windows 上，它失效的主因只有一个。Windows 11 版本 24H2 在 Pro、Enterprise 和 Education 版本上要求对出站和入站连接启用 SMB 签名，并且在 Pro 上禁用了来宾回退。Home 则在任一方向都不要求签名。在那些确实需要签名的版本上，多年来一直可用的共享现在会返回 0x80070035，并显示 The network path was not found，或者出现关于安全策略阻止未经身份验证的来宾访问的消息。Samba 服务器、Linux 共享以及较旧的 NAS 固件通常都是受害者。
-
先修复远端。在 Samba 或 NAS 共享上，强制启用 SMB 签名，将最低协议版本设置为 SMB2 或 SMB3，并创建一个正式账户，而不要使用来宾访问。
-
在 Windows 上读取当前客户端状态：
Get-SmbClientConfiguration | fl EnableSecuritySignature,RequireSecuritySignature -
只有在无法更改对端时，才放宽客户端要求：
Set-SmbClientConfiguration -RequireSecuritySignature $false -
重新连接并测试共享。
第3步会削弱连接，应作为最后的选择。Windows OS Hub 指出，强制签名会在双方消耗 CPU 和内存，并降低文件传输速度，而微软在其SMB 签名参考页面上列出了各版本的要求，这属于另一个方向上的权衡。尽管许多人首先会启用它，但支持 SMB 1.0 和 CIFS 并不是这里的解决之道。
限制
| 方式 | 大小上限 | 在主机策略阻止下仍可用 | 远程为 macOS 时可用 | 远程为 Windows 家庭版时可用 |
|---|---|---|---|---|
| 剪贴板文件 | RDP 剪贴板重定向时为 2 GB | 否 | 否 | 否 |
| 重定向的文件夹或驱动器 | 无文档说明 | 否 | 否 | 否 |
| SMB 共享 | 无文档说明 | 是 | 是 | 是 |
scp 或 rsync |
无文档说明 | 是 | 是 | 是 |
| HelpWire 会话 | 无文档说明 | 是 | 是 | 是 |
并非每一次传输都能保留元数据。从 Linux 复制到 NTFS 卷会丢失 POSIX 所有权和可执行位，而从 macOS 复制到 SMB 会写入目标用不上的伴随文件。与其事后才发现问题，不如在文件到达时就计划重置权限。
大多数人首先尝试的做法，以及它为什么会失败
重启 rdpclip.exe 几乎在每个帖子中都是第一步，但在这里这是错误的。该进程会在 Windows 主机上重置剪贴板通道。它无法为从未具备该功能的 Linux 客户端添加文件剪贴板支持，对于从未配置文件夹重定向的 Mac 也无济于事。我们的 复制粘贴修复指南 涵盖了它确实有用的情况。
将文件拖入会话窗口是接下来的尝试，而且耗时最少。没有任何桌面版 RDP 客户端会接受这种操作 – mstsc.exe、Windows 应用、Remmina，以及 xfreerdp 都一样 – 因为该协议并不包含拖放通道。基于浏览器的 Windows 应用客户端是个例外，它使用的是自己的上传机制而非 RDP。一旦重定向了某个文件夹，你可以在会话内部在该文件夹与远程目录之间拖拽，因为对文件管理器来说它们看起来都像普通位置，但从桌面拖入窗口从来就不能用。
Mac 用户会编辑已保存的 .rdp 文件并添加 drivestoredirect 属性，因为 Windows 文档就是这么写的。在 macOS 上的反馈结果是完全没有重定向。Linux 用户会在 +drives 紧挨着 /drive: 以求稳，结果在此过程中反而丢失了所命名的文件夹。Windows 用户会遇到 0x80070035，然后开启 SMB 1.0 支持，但这既不能满足签名要求，也无法解决导致问题的来宾回退更改。
最后一个问题特指以 Mac 为目标的情况。Apple 的 VNC 服务器仅凭密码就会接受来自 Windows VNC 查看器的连接，这让人以为其余功能也同样具备。屏幕控制可以工作。Apple 的服务器未实现任何文件传输扩展，因此对端没有任何东西可以响应文件请求。
如果那不起作用
您在已打补丁的 Windows 客户端上从已保存的 .rdp 文件启动
在每次启动时勾选重定向复选框。2026 年 4 月的累积更新更改了 Windows 处理已保存 .rdp 文件的方式，现在在连接开始之前出现的安全对话框中，所有请求的资源都会以未勾选状态出现。此更改仅适用于从文件启动，因此在 mstsc.exe 中输入计算机名的行为与以往相同。
-
双击
.rdp文件，并在首次使用时确认一次性通知。 -
将对话框中显示的远程地址与您期望的主机进行核对。
-
勾选 驱动器 和 剪贴板，然后点击 连接。
-
如果在多显示器设置下对话框呈现时出现按钮错位或无法触及，请安装
KB5083631预览更新，它已修复该显示问题。
远程计算机为 Windows 家庭版，或该主机不由您管理
到此为止，换条路线。Windows 家庭版没有 RDP 主机服务，因此在 设置 > 系统 中按设计没有 远程桌面 开关，也不存在可供修正的重定向设置。在企业主机、Azure 虚拟桌面 池或 Cloud PC 上，为阻止文件在任一方向的传输，重定向会被有意关闭。对于不属于你的计算机，请申请经批准的传输路径，并在你无权更改策略的环境中使用带有自有传输层的工具。
HelpWire 跨 Windows、Mac 和 Linux 的文件传输
HelpWire 文件传输 在其自身会话内传输文件，因此对于任何操作系统组合都无需 RDP 重定向层。它是一款为远程支持工作构建的远程访问软件，供 IT 支持团队、独立技术人员以及小型公司内部 IT 使用。它适用于本文反复提到的两种情况：远程计算机没有 RDP 主机，以及主机的配置由他人掌控。
会话从你通过任何你已在使用的渠道发送的链接开始。对端的人打开它，运行下载的便携式应用，并点击 授予访问权限。他们无需创建账户。操作端应用可运行于 Windows 7 及更高版本、macOS Big Sur 11 及更高版本，以及 Linux（Ubuntu 18.04 至 24.04、Debian 11 和 12、CentOS 9、RHEL 9 和 Fedora 39 或更新版本）参见平台列表，因此操作者和客户端可以位于不同平台上而无需改变操作方式。
双向复制和粘贴
-
开始会话，并等待客户点击授予访问权限。
-
在您自己的计算机上，右键单击该文件并选择复制。
-
在会话中，在客户端的计算机上右键单击目标文件夹，并选择粘贴。
-
查看进度，该进度会显示在客户的计算机上。按相同步骤反向操作以将文件取回。
拖放到 Operator 窗口上
此项仅在您的机器与客户的机器之间运行，并且操作端必须是 Windows 或 macOS。
-
当会话处于活动状态时，在您自己的计算机上选择一个或多个文件，或整个文件夹。
-
将所选内容拖到已打开的 HelpWire Operator 窗口上并松开。这些项目将被放入客户端的剪贴板。
-
在客户端计算机上右键单击目标文件夹，然后选择粘贴以完成传输。
键盘快捷键
-
在本地计算机上选择该文件，然后在 Windows 上按
Ctrl+C，或在 macOS 上按Cmd+C。HelpWire 仅为这两个平台记录了快捷键。 -
在客户端计算机上单击进入目标文件夹。
-
在 Windows 上按
Ctrl+V，或在 macOS 上按Cmd+V。
从 HelpWire 的 文件传输文档中了解更多关于这些方法和所需权限的信息。
常见问题
先将其压缩成一个归档，或者使用 rsync。逐个文件的开销在本文提到的每种方式中都占主导。重定向的文件夹会通过驱动器通道分别协商每个文件，而剪贴板在传输任何一个字节之前会先构建完整的描述符列表，因此，一万个小文件所需的时间，可能比一个比它们合计大小大许多倍的归档还要更久。在源端创建一个 tar 或 zip 归档，传输这一个文件，到达后再解压。对于重复进行的同一传输，rsync 只会发送发生变化的部分，而 -P 会保留未完成的部分文件，使中断的运行能从停止处继续。没有该标志时，rsync 会删除未完成部分并从头重新传输该文件，这常常让人措手不及。两种 RDP 路径都完全不支持断点续传。我们的 从远程桌面到本地计算机的传输 指南单独讨论了剪贴板大小上限。
NTFS 会拒绝 ext4 和 APFS 接受的字符。冒号、问号、星号、竖线、双引号，以及小于号和大于号在 Linux 上都是合法的，但在 Windows 文件名中都是非法的，因此复制在遇到第一个违规字符时就会停止。大小写敏感性是第二个陷阱：在同一个 Linux 目录中，名称仅大小写不同的两个文件在 NTFS 上会冲突为同一个名称，导致其中一个丢失，或者复制会中止。与其在部分传输之后再处理，不如在进行批量传输之前先在源端重命名。
运行 defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true 在终端中，然后注销并重新登录。这仅适用于网络卷，对本地磁盘不起作用。它也不会影响单独的 ._ 伴随文件，它们携带 macOS 元数据，并且通常是 Error code -36 在通过 Finder 复制到 SMB 共享时的常见原因， 这是用户多年前就已指出的原因。清除已写入的那些，使用 dot_clean ~/path/to/folder，一种 仍然建议用于该错误的变通方法。
在 Windows 上没有原生支持，因为 Windows 不自带 rsync 二进制文件。有三种办法可以实现。在 WSL 中运行，它的 Linux 版本可以正常处理挂载在 /mnt/c/ 的 Windows 路径。安装 Cygwin 或 MSYS2 版本。或者从 Linux 端驱动；在 Windows 上启用 OpenSSH 服务器后，可以通过 SSH 从 Windows 拉取。对于一次性的拷贝，scp 更简单，只有在需要重复相同的传输时，rsync 的配置才值得。
在两个 Windows 会话之间，可以，前提是两者都启用了驱动器重定向。在 Linux 桌面上的两个会话之间，这取决于你的 FreeRDP 版本，并且在过渡到 3 版本时出现了倒退：迁移到 Fedora 40 的用户，若使用 FreeRDP 3.4.0 失去了在一个会话中复制并粘贴到另一个会话的能力，而此前在 2 版上多年一直沿用该工作流程。FreeRDP 在 3.27.0 于 2026 年 6 月通过修复在 xfreerdp 会话之间复制多个项目的问题来解决了该情况，因此当前构建的表现比 Fedora 40 的报告所述更好。无论版本如何变化，始终可行的方式是使用两个会话都能访问的文件夹。
不需要，而且用户名也不必一致。只有某些途径才需要在远端有账户。重定向的文件夹依附于你已打开的 RDP 会话，因此远程机器会以你登录时的身份来读取它，并不存在第二组凭据。SMB 共享则需要在托管该共享的那台机器上有一个真实账户。scp 和 rsync 需要目标上的账户，而使用基于密钥的认证时，一旦你用 ssh-copy-id 将公钥复制过去，就不会再出现密码提示。最常让人跌跤的一种情况是：在某台机器上，会话实际上以与预期不同的账户运行，导致重定向的文件夹在写入时出现权限错误，而不是文件夹缺失。
