Windows 11 作为宿主机VMware Workstation 里装着 Ubuntu 24.04 虚拟机想让两个系统之间互相传文件最顺手的做法是挂载共享目录。VM 的 Shared Folders 功能本质上是在宿主机和客户机之间开了一条数据通道配置一次之后就像访问本地盘一样自然。这篇文章就把我在 Win11 Ubuntu 24.04 VMware 环境下的完整配置过程讲清楚包含主机侧设置、客户机挂载、开机自动挂载和常见坑的排查方法。不管你是刚接触虚拟机的新手还是被文件传输折腾过几次的老玩家按着步骤来都能复现。1. 先选对方案VMware 共享目录凭什么值得折腾1.1 我的实验环境先说下我这次操作的基准环境方便你对照宿主机Windows 11 ProWindows 版本为 23H2/24H2 都行共享目录功能对系统版本没有硬性依赖虚拟机软件VMware Workstation Pro 17.x我用的是 17.5.2客户机Ubuntu 24.04 LTS Desktop内核 6.8自带 FUSE 支持网络模式NAT因为本文方案和网络模式无关桥接也照样能用很多人问过一个问题Ubuntu 24.04 在 VMware 里要不要装官方 VMware Tools我的答案是不需要。Ubuntu 仓库里自带的 open-vm-tools 才是正解它随系统内核一起维护不容易出现内核版本不匹配导致的功能失效。官方那套 VMware Tools 在 Ubuntu 上反而可能遇到兼容问题尤其是内核更新后需要重新编译模块非常难受。后面我会讲到具体怎么装。1.2 五种共享方式怎么选虚拟机与宿主机之间的文件传输方案我简单梳理一下方便你判断为什么共享目录值得选方案配置复杂度性能感受适用场景VMware Shared Folders低图形界面勾选即可中等偏上走 Tools 通道单机宿主机单虚拟机日常传文件和开发最合适Samba(SMB) 共享中要在 Windows 和 Ubuntu 两侧都配权限受局域网/虚拟网卡性能影响多台物理机互相访问或虚机需要被其他设备访问NFS 共享较高要设置 exports 和权限高Linux 主机间的专业场景普通用户不需要碰SSH/SFTP低但做不到实时双向挂载取决于传输协议小文件还行偶尔传几个配置文件不想装东西时应急U 盘/USB 直通低但自动挂载要折腾取决于 USB 协议一次性拷贝大量数据不追求持续同步我最初用的是 U 盘拷贝后来换了 Samba最后还是回到 VMware 共享目录。原因很直观Samba 在每次重启、改密码、Windows 更新后都可能掉链子还要维护用户名密码而共享目录是虚拟化平台自己提供的只要 Tools 正常、配置开启它就一直存在没有任何额外依赖。当然如果你需要让宿主机之外的设备也访问这个目录Samba 仍然是更好的选择但那就不是本文要处理的问题了。2. 主机侧一步步设置共享目录的开启与配置2.1 添加共享目录的完整操作先说结论在 VMware Workstation 中添加共享目录最好在虚拟机关机状态下操作原因后面会讲。具体步骤关闭 Ubuntu 虚拟机确认状态是已关闭而不是已挂起在 VMware Workstation 的虚拟机列表里右键选择目标虚拟机 - 设置Settings在设置窗口中切换到选项Options选项卡找到共享文件夹Shared Folders选择总是启用Always enabled原本已禁用Disabled是默认状态点击添加Add按钮启动添加向导在主机路径中选择 Windows 侧需要共享的目录比如 D:\share_data给这个共享起个名字我建议用纯英文且不带空格原因在 3.3 节会细说勾选启用此共享确认即可这里有个容易踩坑的点很多人喜欢把整个盘符比如整个 D: 盘共享进去我强烈不建议这么干。共享目录的粒度越细越好单独建一个工作目录专门用来交换文件既能避免误操作也能减少 VMware 索引和同步时的开销。我自己的习惯是在 Windows 侧创建 D:\vm_share下面再按项目分子文件夹比如 D:\vm_share\code、D:\vm_share\data。添加完成后可以看到共享列表里多了一条记录状态为已启用。如果你是在虚拟机开机状态下添加的大概率会遇到客户机一侧无法自动感知的情况需要重启客户机或者重新启动 Tools 服务才生效。所以按照前面说的关机状态下操作最省事。2.2 先绕开两个最常见的坑第一个坑共享目录功能依赖 VMware Tools 通道但和你虚拟机的网络模式完全无关。网上有些帖子里提到必须改成桥接模式我的实测结论是 NAT、桥接、仅主机都能正常使用共享目录因为数据走的是虚拟化平台自身的通信机制不经过虚拟网卡。如果你共享目录不生效不要去折腾网络模式那是白费力气。第二个坑Windows 侧目录本身的 NTFS 权限会影响客户机的读写。比如你把共享目录设在 C:\Users\某个用户\AppData 下而该目录的 ACL 权限限制了当前登录用户那么在 Ubuntu 手动挂载后执行读写可能遇到 Permission denied排查起来非常容易把人带偏。稳妥的做法是把共享目录放到一个权限简单的路径比如 D 盘根目录新建的文件夹并确认你的 Windows 用户对该目录有完全控制权限。右键目录 - 属性 - 安全把 Users 组的权限设为完全控制是最省心的。3. Ubuntu 24.04 挂载实操从手动命名撑到开机自动3.1 确认 VMware Tools 组件就位在 Ubuntu 24.04 里共享目录功能由 open-vm-tools 提供核心组件是vmhgfs-fuse。如果你的系统是比较完整的桌面版Ubuntu Desktop安装 open-vm-tools-desktop 就会同时带上需要的所有功能sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktop如果你是 Ubuntu Server 版无桌面环境安装 open-vm-tools 即可sudo apt install -y open-vm-tools安装完成后重启一次虚拟机或者至少重新登录一次让 fuse 相关服务和用户组配置生效。然后验证一下工具是否存在which vmhgfs-fuse vmware-hgfsclientvmware-hgfsclient的作用是列出当前虚拟机能看到的共享目录名。如果输出为空说明主机侧的共享没有正确添加或者 VMware Tools 服务没有正常工作。这里有一个比较隐蔽的原因VMware Workstation 17 在 Windows 11 上升级后有时之前的共享配置会丢失所以重启虚拟机发现共享不见了第一件事应该是回主机侧检查总是启用是否还勾着。3.2 手动挂载先跑通确认共享可见之后我们先手动挂载一次。这个方法适合临时使用和验证毕竟不是每次开机都想去执行一遍命令。挂载所有共享目录根的方法sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other,uid$(id -u),gid$(id -g)解释一下这行命令的关键点.host:/表示 VMware 共享目录的根路径所有已启用的共享都在这个根下面/mnt/hgfs是客户机侧的挂载点可以自己改-o allow_other允许非 root 用户访问挂载点uid$(id -u),gid$(id -g)让挂载点中文件的属主是当前用户否则你用普通用户登录看到的文件 owner 可能是 root写文件时会很痛苦挂载完成后执行ls -la /mnt/hgfs应该能看到你在主机侧添加的共享目录名比如 share_data。如果只想挂载某一个共享目录而不是全部可以把.host:/换成.host:/share_data挂载点也可以指定为另一个目录sudo mkdir -p /mnt/share_data sudo vmhgfs-fuse .host:/share_data /mnt/share_data -o allow_other,uid$(id -u),gid$(id -g)手动挂载跑通之后就可以考虑让它开机自动执行了。3.3 开机自动挂载的三种写法方式 A/etc/fstab最简单但要注意顺序打开 /etc/fstab 文件sudo nano /etc/fstab在末尾添加一行.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other,uid1000,gid1000 0 0这里有个非常关键的细节uid1000,gid1000是我的桌面用户 uid。每个人的用户 uid 不一定相同不要照抄用id -u和id -g查看你自己的值。如果你写错了 uid挂载能成功但你访问挂载点会非常别扭因为文件 owner 成了一个不存在的用户。添加完成后执行sudo mount -a如果没有报错说明 fstab 配置没问题。但说实话fstab 方式在 VMware 共享目录上偶尔会碰到一个问题系统启动早期vmhgfs-fuse可能还没就绪导致挂载失败。如果重启后发现 /mnt/hgfs 是空的或者目录变成普通目录就是这种情况。方式 Bsystemd 单元更可控推荐我个人更推荐用 systemd 的方式因为可以设置依赖关系确保服务启动顺序正确。创建一个挂载单元文件sudo nano /etc/systemd/system/mnt-hgfs.mount内容如下[Unit] DescriptionMount VMware Shared Folders Afternetwork.target [Mount] What.host:/ Where/mnt/hgfs Typefuse.vmhgfs-fuse Optionsdefaults,allow_other,uid1000,gid1000 [Install] WantedBymulti-user.target文件名 mnt-hgfs.mount 必须与 Where 路径对应比如挂载点是 /mnt/hgfs文件名就是 mnt-hgfs.mount不能乱改。然后启用sudo systemctl enable mnt-hgfs.mount sudo systemctl start mnt-hgfs.mount检查状态systemctl status mnt-hgfs.mount方式 Crc.local不推荐现在 Ubuntu 用的 systemd 默认不执行 rc.local除非你自己去启动和启用 rc-local 服务否则写了也白写。所以这条路直接跳过。3.4 权限问题一次讲透最后关于权限我再额外展开一下这是很多人挂载成功后依然用不好的原因。fstab 或 systemd 里的allow_other之所以要配是因为 FUSE 默认挂载点只有执行挂载的用户能访问。而我们通常是用 root 去执行挂载命令如果不加 allow_other普通用户进去只能看到一串问号或者没有权限非常神秘。但光加 allow_other 还不够还要修改 /etc/fuse.confsudo nano /etc/fuse.conf把文件里#user_allow_other前面的注释符 # 去掉保存。相信我这一步是你排查挂载成功但普通用户打不开问题的关键。我一开始就漏掉了它导致每次都得 sudo 去访问共享目录开发效率极低。还有一类情况是 Windows 侧权限导致的。比如你把共享目录放在 C 盘 Program Files 下或者某些系统保护目录即使客户机挂载参数没问题Windows 侧 ACL 也会拒绝写入。判断方法是在 Ubuntu 里用 root 用户去 touch 一个新文件如果 root 都失败基本就是 Windows 侧权限问题如果 root 能写普通用户不能写就是挂载选项或 fuse.conf 的问题。4. 挂载失败排查实录踩过的坑一次说清4.1 vmware-hgfsclient 为空怎么办这是最典型的症状在 Ubuntu 里执行 vmware-hgfsclient 后没有任何输出或者报找不到共享目录。排查顺序我建议按下面的表格来排查点操作方法说明主机侧共享开关检查虚拟机设置中是否选择了总是启用这是最高频原因尤其 Workstation 升级后可能被重置open-vm-tools 是否安装dpkg -lgrep vm-toolsVMCI 服务是否正常systemctl status vmware-tools.service或 vmtoolsd注意服务名可能有差异用 ps -ef重启客户机重启 Ubuntu添加共享且在开机状态时需要重启才生效以管理员身份运行 Workstation在 Windows 中退出 Workstation 右键以管理员方式重新打开Windows 11 较新版本上权限不足会导致 VMware 进程无法访问某些目录这里要特别说一句Windows 11 上如果开启了 Hyper-V 或 Windows 沙盒之类的功能VMware Workstation 的整体稳定性会受到一定影响偶尔出现无法连接虚拟机或者 Tools 通道卡死。这种情况不需要卸载 Hyper-V只要在启用或关闭 Windows 功能里把Windows 虚拟机监控程序平台关掉或者使用 VMware Workstation 17 的 TCOVBS兼容模式通常就能恢复正常。4.2 挂载报错与路径问题手动执行 vmhgfs-fuse 时的常见报错mount point /mnt/hgfs does not exist挂载点目录不存在用sudo mkdir -p /mnt/hgfs创建即可no such file or directory检查共享名是否正确执行 vmware-hgfsclient 看真实的共享名特别是当你只挂载单个共享时容易拼错Transport endpoint is not connected这个比较棘手多发生在休眠恢复之后。解决方法是先卸载再重新挂载sudo umount /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other,uid$(id -u),gid$(id -g)还有路径中的空格问题。如果你偏要在共享名或路径中使用空格比如 My Share那么在 fstab 中需要把空格写成\040.host:/My\040Share /mnt/hgfs/my_share fuse.vmhgfs-fuse defaults,allow_other 0 0这种转义方式非常容易写错所以我一直建议共享名和实际路径都用纯英文、不用空格和下划线以外的特殊字符。4.3 关于性能的几个观察共享目录毕竟不是本地磁盘性能上会打折扣但如果只是传代码、文档、图片完全够用。我在实际使用中有几个观察大量小文件比如 node_modules、编译缓存放在共享目录里会非常慢而且 CPU 占用高。原因是每次文件访问都要经过 Tools 通道做一次转换小文件数越高开销越大单个大文件的读写速度还可以我在 SATA SSD 上测过大约能到 500MB/s 到 800MB/s完全能满足视频剪辑素材交换的需求但不要拿去跑数据库如果你在共享目录里编译大型项目建议把编译输出目录指向虚拟机的本地磁盘源码保留在共享目录里。这样测试修改时能看到实时同步编译时又不受共享通道的 IO 瓶颈影响这样一来共享目录就成了开发工作流中的源代码同步层高速 IO 需求全部留在虚拟机内部体验会顺畅很多。5. 让共享目录好用到飞起的进阶技巧5.1 目录映射与符号链接共享目录挂载在 /mnt/hgfs 下但很多人希望在桌面、家目录或者某个固定开发目录里直接访问不用每次都 cd 到 /mnt/hgfs。用符号链接就能解决ln -s /mnt/hgfs/share_data ~/Desktop/share_data这样桌面就会多出一个快捷方式双击就能进到 Windows 侧的目录。我还会把常用的项目目录直接链到 home 下ln -s /mnt/hgfs/share_data/code ~/code注意一点如果你在 VMware 设置里删除了某个共享再重新添加同名共享符号链接不受影响因为 /mnt/hgfs 的挂载点还在只是内容变了。但如果整个 /mnt/hgfs 挂载失败符号链接会变成一个失效链接排查起来容易慌。5.2 结合开发工作流做个闭环说个我自己每天都在用的例子。我在 Windows 11 上用 VS Code 打开 D:\vm_share\code 里的项目直接编辑代码。Ubuntu 虚拟机的家目录里通过符号链接把 ~/code 指到 /mnt/hgfs/code。这样我在 Windows 里改一行代码保存Ubuntu 里立刻就能看到反之亦然。如果项目需要编译和运行我就在虚拟机里操作需要查资料时切回 Windows 浏览器两边完全无缝。对于数据文件也有同类场景。比如手动把 Windows 下的录屏导到 D:\vm_share\video在 Ubuntu 里用 ffmpeg 批处理压缩处理完的文件直接落在 Windows 磁盘上省去上传下载的步骤。这比 U 盘拷贝高效得多也比 Samba 在登录态管理和权限控制上省心得多。最后再分享一个我重装系统后的固定动作装完 Ubuntu 第一件事安装 open-vm-tools-desktop然后配置主机侧共享再写入 systemd 挂载单元。这个流程跑顺了基本十分钟以内就能把所有文件交换的路打通。看到这里你应该已经能自己搞定 Win11 Ubuntu 24.04 虚拟机的共享目录挂载了剩下的就是在日常使用中不断调整目录结构找到最适合你自己的节奏。