每次有人跑来问我在VMware里怎么给虚拟机传文件，我基本都会先反问一句：你现在是怎么传的？得到的答案要么是拖拽，要么是做个ISO镜像挂载，要么干脆走网盘中转。这些方法不是不能用，而是遇到大文件、高频同步、开发调试这类场景就会露馅。今天这篇就是老话题重讲，聊聊在主机和本地VMware虚拟机之间用共享文件夹传输文件这件事，把设置步骤、挂载点、权限处理这些坑一次性说透。写它的原因是这套操作在Windows和Linux客户机里我都反复折腾过，适合正在用VMware Workstation/Pro跑虚拟机的人，尤其是做开发、测系统镜像的新手。

先说结论：共享文件夹是VMware里被低估得最严重的功能之一。它在主机和虚拟机之间建立一条“直通目录”通道，两边看到的几乎是同一份数据，不用复制、不用同步、不用走网络，比U盘、光盘镜像、FTP这些土办法靠谱太多。接下来我从方案选型开始讲，把原理、步骤、坑全捋一遍。

1. 为什么选共享文件夹：几种文件传输方式的对比

1.1 拖拽与复制粘贴：小文件还行，大文件就崩

VMware Workstation从很早的版本开始就支持在主机和客户机之间直接拖拽文件，同时也支持复制粘贴文本和文件。这个功能刚出来的时候确实惊艳，很多人（包括我）一开始都是用这个方式传文件的。

但用久了就会发现，拖拽这个方案有三个明显的短板。第一，它本质上依赖VMware Tools提供的一个扩展剪贴板通道，走的不是专门的文件传输通道，而是把文件内容通过内存中转。小文件比如几个文本、截图、PDF，完全没问题，但一旦文件上了1GB甚至更大，拖拽就会变得非常不稳定，进度条经常卡住，甚至会直接失败，客户端里显示复制了个寂寞。第二，从虚拟机往主机拖文件有时候根本没反应，尤其是Linux客户机里，需要在文件管理器里再走一遍复制粘贴，操作很别扭。第三，拖拽是“一次性”的，如果你改了文件，又得重新拖一遍，根本没有“同步”的概念。

所以我的判断是，拖拽适合传小东西，偶尔用用还挺方便，但拿它当主力传输方案，早晚会翻车。

1.2 共享文件夹的核心优势：不是网盘，是直通目录

VMware的共享文件夹走的是另一套机制，官方叫法叫HGFS（Host-Guest File System）。你可以把它理解成VMware在客户机里虚拟出了一个文件系统服务，主机的某个目录直接被“映射”到虚拟机里，客户机访问这个目录就像访问本地磁盘一样。

关键区别在于，它是“直通”的，不是“复制”的。你在主机共享目录里新建一个文件，虚拟机里立刻能看到；反过来，你在虚拟机里修改了共享目录里的文件，主机这边也是实时变更。这种双向实时同步的特性，让共享文件夹特别适合跑开发、放安装包、存临时数据这类场景。我平时写代码就经常把workspace放到共享目录里，主机上用IDE写，虚拟机里直接跑编译，两边不会出现版本不一致的问题。

另外一个容易被忽略的点是，共享文件夹传输文件不依赖网络。你不需要配置IP地址、不用管NAT还是桥接、不用想着开SMB服务。这就意味着即使你的虚拟机网络配置出问题，共享文件夹照样能用，排查问题的维度少了一大截。

1.3 什么时候不该用共享文件夹

再说句公道话，共享文件夹也不是万能的，有些场景我建议还是别用它。

第一，超大文件传输。如果你要在主机和虚拟机之间搬十几个GB的文件，共享文件夹能用，但速度不一定会让你满意。受限于HGFS驱动的IO效率，有时候还不如直接把文件拷进虚拟磁盘里快。遇到这种场景，我更推荐关机后直接用VMware的虚拟磁盘映射功能，或者把磁盘文件挂载出来拷贝，速度更稳。

第二，对IO性能要求极高的场景。比如虚拟机里跑数据库、跑大数据测试，千万别把数据文件放在共享目录里。共享目录的读写路径比本地虚拟磁盘多了一层，延迟和吞吐都打了折扣，跑高负载任务的时候你会明显感觉到慢，严重的还可能把主机IO拖垮。

第三，多台虚拟机并发读写同一个共享目录。虽然技术上支持，但如果你没有一个完善的并发控制方案，很容易出现文件锁冲突、数据覆盖这类问题。这种情况更适合用真正的网络共享或者版本控制工具。

我整理了一个简单的对比表，方便按场景选方案：

2. 搭建前的准备：VMware Tools是共享文件夹的前提

2.1 VMware Tools到底负责什么

很多人对VMware Tools的认知停留在“装了鼠标就能在虚拟机里进进出出”的层面，其实它不只是鼠标驱动。VMware Tools是一个组件集合，至少包含显示驱动、鼠标驱动、剪贴板共享、时间同步服务，以及HGFS文件系统客户端。共享文件夹功能能够启用，靠的正是HGFS这个组件。

换句话说，如果你的虚拟机还没装VMware Tools，或者Tools装得不完整，那么就算你在主机侧把共享文件夹选项折腾出花来，虚拟机里也看不到共享目录。这个前置条件卡住了很多人——他们明明在设置里添加了共享文件夹，进虚拟机一看就是什么都没有，最后排查下来才发现Tools没装好。

所以在动共享文件夹设置之前，先把Tools确认好，这是整个操作的基础。注意，这里的“装好”不是指安装包运行一次就完事，而是虚拟机里对应的服务已经正常运行，后面会讲怎么看。

2.2 Windows客户机的安装细节

在VMware Workstation里装Windows客户机的Tools是最简单的情况。打开虚拟机，在菜单栏选择“虚拟机” → “安装VMware Tools”，这时候虚拟机里会弹出一个虚拟光驱，里面放着Tools安装包。在Windows客户机里打开光驱，找到setup64.exe（64位系统）或者setup.exe（32位系统），右键以管理员身份运行，一路Next就完事，装完重启虚拟机。

这里有几个细节值得注意。一是如果虚拟机里开着杀毒软件或者系统加固工具，建议先临时关掉，否则安装程序写入驱动文件的时候容易被拦截，装到一半报错。二是如果你用的是Windows 7这类老系统，装新版VMware Tools（比如Workstation 17自带的Tools）大概率会失败，因为新版Tools依赖的运行时组件在老系统里缺失。这种情况下要么先把系统补丁打全，要么去VMware官网下载对应老版本的Tools安装包。三是安装完成后重启虚拟机，然后在Windows的服务管理器里确认一下，能看到VMware Tools服务在运行，且启动类型为自动，才算真正装好。

2.3 Linux客户机：优先用open-vm-tools

Linux客户机的情况略微特殊。早期要在Linux里装VMware Tools，需要从虚拟光驱挂载安装包，然后执行vmware-install.pl脚本，这个脚本会调用本地的gcc和内核头文件来编译内核模块。问题在于，很多Linux发行版默认没装gcc和kernel-devel，导致编译失败，新手经常卡在这一步。

现在有了更好的选择——open-vm-tools。这是VMware官方和Linux社区共同维护的开源版Tools，直接集成在主流发行版的软件源里，装起来一行命令的事，不用编译、不用管理内核模块，省心太多。

Ubuntu/Debian/Kali这类基于Debian的系统，执行：

sudo apt update sudo apt install open-vm-tools open-vm-tools-desktop

Rocky Linux/CentOS/Fedora这类基于RHEL的系统，执行：

sudo dnf install open-vm-tools open-vm-tools-desktop

这里解释一下为什么还要装open-vm-tools-desktop。如果你跑的是带桌面的Linux，这个包会额外提供显示驱动、剪贴板共享等功能；如果只是纯命令行的服务器版，装open-vm-tools就够了，desktop包那部分功能用不上。装完之后不需要马上重启，但建议重启一次让服务完整加载，然后用systemctl status vmtoolsd确认状态是active。

3. 核心实操：Workstation 17里设置共享文件夹

3.1 主机侧设置：找到选项、勾对参数

确认VMware Tools正常之后，接下来就是在主机侧把共享文件夹打开。我以VMware Workstation Pro 17为例，其他版本界面基本一样，只是细节位置略有差别。

先关闭虚拟机。不是挂起，是真正的关机（Shut Down），因为某些设置项在虚拟机运行时改不了。关机后在虚拟机列表里右键虚拟机，选择“设置”，进入“选项”选项卡，找到“共享文件夹”这一项。

这里有几个选项，我逐个解释。

文件夹共享的启用方式，一定要选“总是启用”。有些朋友觉得选“下次开机时启用”和“总是启用”差不多，其实差别大了。选了前者，这次会话共享可能不会生效，往往要等到虚拟机再次重启才挂载，而且很多人选完之后就忘了这回事，还以为设置错了。我建议直接选“总是启用”，一劳永逸。

然后点“添加”，选择一个主机目录。注意，目录路径不要带中文、不要带空格，尽量保持简单的英文路径，比如D:\shared、/home/xxx/shared。这不是玄学，是老版本HGFS驱动对特殊字符处理不友好，踩过这个坑的人不少。

在“名称”这里，可以给这个共享起一个虚拟机内显示用的名字，比如shared、workspace。这个名字在虚拟机的挂载路径里会用到，建议也用英文短名。

然后勾选“启用此共享”。这里还有个“只读”选项，需要重点理解一下：如果只勾只读，虚拟机里只能读主机目录里的文件，不能创建和修改；平时开发调试建议不要勾，直接开读写。只有一种情况我建议勾只读，就是你只想单向分发文件给虚拟机，防止虚拟机误修改主机上的原始文件。

设置完之后，点确定保存。

3.2 Windows客户机访问：\vmware-host\Shared Folders

Windows客户机里访问共享文件夹是最直观的。打开文件资源管理器，在地址栏输入：

\\vmware-host\Shared Folders

回车之后就能看到你在主机侧添加的所有共享目录，进去就是那几个文件夹，直接用就行。

解释一下这个路径的来历，方便你以后排查问题。HGFS服务在客户机里虚拟了一个主机名为vmware-host的入口，服务名固定叫Shared Folders，后面跟上你设置的共享名称，就构成了完整的访问路径。如果以后再问“我的共享文件夹在Windows里到底在哪”，这个路径就是答案。

如果你觉得每次输地址太麻烦，有两种优化方式。第一种，右键“网络”或者“此电脑”，选择“映射网络驱动器”，把\vmware-host\Shared Folders\共享名称映射成一个盘符，比如Z盘，以后在资源管理器里直接点Z盘就能进。第二种，在VMware设置共享文件夹时勾选“在Windows客户机中映射为网络驱动器”，但它默认映射的是所有共享目录的根路径，不如自己手动映射更灵活。

需要留意的是，如果你在虚拟机的资源管理器里看不到共享文件夹，可以先在地址栏手动输入上面的路径试试。很多时候刷新一下或者重新映射一次就好了，不一定是配置问题。

3.3 Linux客户机访问：vmhgfs-fuse挂载

Linux客户机的情况要稍微动手。新版open-vm-tools在部分发行版里会自动挂载共享目录到/mnt/hgfs，但依赖系统对FUSE挂载的处理方式，很多情况下并不会自动挂载，需要你手动来一次。

先把基础命令跑一遍。首先确认主机侧共享是否可见，用vmware-hgfsclient查看：

vmware-hgfsclient

如果这个命令有输出，说明虚拟机已经识别到了主机共享目录；如果没输出，先别往下走，回到3.1去检查共享设置和Tools状态。

然后创建挂载点并执行挂载：

sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other -o uid=1000,gid=1000

逐项解释一下这行命令。.host:/表示主机共享目录的根路径，后面可以接具体的共享名称，比如.host:/shared表示只挂载名为shared的共享目录；如果不写共享名，就是把所有共享目录都挂载到/mnt/hgfs下面，路径里直接用目录名区分。allow_other参数允许非root用户也能访问挂载点，不然只有root能进。uid和gid参数很关键，把挂载后的文件归属映射到当前普通用户，否则你以普通用户进去操作文件，会因为权限不足报Permission denied。uid值可以用id -u查询，gid用id -g，大部分个人Linux桌面环境都是1000。

挂载完之后进入/mnt/hgfs，就能看到共享目录里的文件了。如果需要开机自动挂载，可以追加一行到/etc/fstab：

.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other,uid=1000,gid=1000 0 0

这里注意两点。一是fstab的选项里不再写-o；二是加了这个配置后，开机时如果HGFS服务还没准备好，挂载可能失败，所以提示“Resource busy”或者“not ready”之类的问题时，可以手动再执行一次挂载命令临时解决。

有些老文章会教用mount -t vmhgfs .host:/ /mnt/hgfs，这种传统内核模块挂载方式在新版内核里兼容性越来越差，经常因为内核模块编译失败导致挂载不成功。我的建议是统一用vmhgfs-fuse，也就是FUSE版本，省心得多。

4. 常见问题与排查技巧实录

4.1 VMware Tools安装脚本运行失败的经典报错

很多人在安装或更新VMware Tools时会看到一个经典报错，原文大概是“VMware Tools 继续运行脚本未能在虚拟机中成功运行。如果您在此虚拟机中配置了自定义脚本，请确保...”这类提示。第一次遇到的人容易慌，以为Tools装失败了，其实这行提示真正想说的是：Tools安装程序的主体文件已经装好了，但安装完成后的“自定义脚本”环节没执行成功。

在Windows客户机里，常见原因有三个：一是安装包不完整或者被杀毒软件拦截，导致安装过程中的某个驱动注册失败；二是系统账户权限不够，安装脚本需要管理员权限却没拿到；三是老系统与新版Tools不兼容，比如Windows 7装新版Tools时经常出现这种情况。排查思路很简单：先用管理员身份重新运行安装包，安装前暂时关闭杀毒软件实时防护，如果还不行，检查系统更新。

在Linux客户机里，这个报错更多出现在你手动运行官方vmware-install.pl脚本的场景。脚本后半段会调用perl解释器执行一些辅助配置，如果系统里没装perl，就会报这个错。解决方法是先补上perl再重装：

sudo apt install perl

但说实话，到了现在这个阶段，Linux客户机真没必要再折腾官方Tools了，直接用open-vm-tools，根本不会走到编译脚本那一步，这个问题自然就绕开了。

4.2 共享文件夹设置了却看不到：灰菜单与空目录

“设置里明明添加了共享文件夹，虚拟机里怎么找不到？”这是被问得最多的问题。排查路径基本按照下面这条线走。

第一步，检查共享文件夹设置里的启用状态，是“总是启用”还是“下次开机启用”。如果是后者，别折腾了，改成“总是启用”再关机重启虚拟机。第二步，确认VMware Tools的服务状态。Windows客户机看服务管理器里VMware Tools服务是否在运行；Linux客户机看systemctl status vmtoolsd。服务没起来，后面的都白搭。

第三步，针对Linux客户机，重点看一眼/mnt/hgfs这个目录是否存在。很多发行版默认没有这个目录，你需要自己mkdir创建。再配合vmware-hgfsclient命令确认主机共享是否可见，如果命令有输出但/mnt/hgfs是空的，十有八九是挂载问题，回到3.3手动挂载一次。

还有一个容易翻车的情况：在Workstation 17里，有些时候会发现整个虚拟机的“设置”菜单是灰的，或者里面没有共享文件夹选项。这种情况先看虚拟机是不是处于开机或者挂起状态，必须在关机状态下部分配置项才可修改。另外，如果虚拟机列表里的配置文件和当前Workstation版本不兼容，也可能导致菜单异常，关掉虚拟机再重新打开一次列表，基本能恢复。

4.3 权限问题：只读、Permission denied与SELinux

共享文件夹的权限问题，是踩坑的重灾区。从错误现象来看，无非就两种：一种是虚拟机里进入共享目录后，发现只能读，不能写；另一种是根本进不去，报Permission denied。

先看“只能读不能写”。这个通常有两个原因。第一个是你设置共享文件夹时勾了“只读”，这个好理解，取消勾选就行。第二个是主机侧目录本身的NTFS或者POSIX权限不够，说白了，你在主机上对那个目录没有写权限，虚拟机里自然也没有。比如你在Windows主机上共享了C:\Program Files下的某个目录，普通用户对它本来就只有读权限，虚拟机里当然写不进去。解决办法是换一个有写权限的目录，或者调整主机目录的用户权限。

再看Linux客户机里的Permission denied。如果你用了vmhgfs-fuse挂载，但没有指定uid/gid参数，那么默认挂载点归属于root，普通用户进去当然被拒。解决方法是重新挂载，加上allow_other和uid=你的uid,gid=你的gid参数。还有一个隐蔽因素，SELinux。在Rocky、CentOS这类默认开启SELinux的系统里，即使你FUSE挂载参数写对了，SELinux策略也可能拦截访问。排查时用sudo ausearch -m avc -ts recent查看有没有AVC拒绝记录，临时验证可以先用sudo setenforce 0把SELinux切到permissive模式，如果能访问了，那就是SELinux策略的问题，需要针对fuse文件系统放行或者调整上下文。

4.4 延伸：CIFS/SMB挂载重启失效是怎么回事

热搜词里有一条“cifs挂载共享文件夹重启后失效怎么办”，虽然这是另一套方案，但和VMware传文件经常被一起提起，值得说几句。有不少人不用HGFS共享文件夹，而是通过主机开SMB共享、虚拟机里mount -t cifs方式来传文件。这个方案同样能达到双向传输的目的，但坑比HGFS多不少。

最常见的问题是，重启后挂载失效。根源基本都指向/etc/fstab的配置顺序。系统开机挂载CIFS的时候，网络很可能还没就绪，挂载操作会失败。解决办法是在fstab的挂载选项里加_netdev参数，告诉系统等网络准备好之后再挂载。示例：

//192.168.1.10/shared /mnt/shared cifs credentials=/root/.smbcredentials,iocharset=utf8,vers=3.0,_netdev 0 0

还有两个默认没人提醒你的细节。一是密码别直接写在fstab里，明文存着很危险，用credentials=/root/.smbcredentials指定一个权限600的配置文件更稳妥，文件内容就是username=xxx和password=xxx两行。二是如果主机是Windows系统，Windows防火墙必须放行SMB所需的445端口，不然虚拟机永远连不上。热搜里提到的“win11共享文件夹找不到网络路径”，十有八九就是防火墙没放行，或者SMB协议版本不匹配。

坦白说，如果你只是想在单机VMware环境里传文件，我不太推荐绕这么大一圈走SMB。HGFS配置一次之后就稳定用，还不依赖网络，何必去折腾防火墙和协议版本。SMB更适合多台物理机之间的网络共享，放到虚拟化场景里有点大材小用了。

4.5 临时兜底：传不进去时的应急方案

最后再分享几个应急方案。万一某天HGFS抽风，或者你临时在别人的机器上，没有共享文件夹配置权限，又急着给虚拟机传文件，可以直接用下面几个土办法顶一下。

如果你只是想从主机把文件放进虚拟机，可以在主机共享目录里开个临时HTTP服务，然后虚拟机里用curl或者浏览器下载。比如主机上在要传的目录下执行：

python3 -m http.server 8000

然后虚拟机里访问http://主机IP:8000就能下载文件。这个方法对NAT和桥接网络都适用，前提是网络是通的，但核心优势是零安装、零配置，系统自带Python就能搞定。

反过来，想从虚拟机把文件传到主机，更好的办法是走SSH。虚拟机里装个openssh-server，主机这边用Windows 10/11自带的OpenSSH客户端直接scp：

scp 用户名@虚拟机IP:/路径/文件名 D:/本地目录

这些都是救急手段，不追求体验，只追求能跑通。日常主力方案还是前面讲的共享文件夹。

再说一个偏门但很稳的技巧：如果虚拟机已经关机，你其实可以把它的虚拟磁盘文件（vmdk/vhdx）通过VMware的“映射虚拟磁盘”功能挂载成主机的盘符，然后直接往里拷文件。这种方式不涉及客户机系统，速度飞快，适合大批量文件一次性灌进去。

最后分享一个我自己的使用习惯。我会把代码、文档、安装包这些“随时要变、两边都要用”的内容都放到主机的共享目录里，虚拟机里只放操作系统和运行环境。这样做的好处是，就算虚拟机系统彻底崩了，直接删掉重建一个，再挂上同一个共享目录，所有资料都还在，重装系统的损失降到最低。另外一个踩坑后的总结是，共享文件夹的名字尽量起英文短名，别带空格，别用中文名，虽然新版Tools对中文支持好了很多，但谁也不知道哪天就踩到老版本挂载的雷。关于VMware里共享文件夹这件事，先聊到这儿，有新的坑我再来补充。