Ubuntu 22.04 VMware共享文件夹完全排障指南

1. 项目概述：为什么Ubuntu 22.04的共享文件夹总“卡在半路”

你刚装好Ubuntu 22.04，打开VMware Workstation或Fusion，点开“虚拟机设置→选项→共享文件夹”，勾上“总是启用”，添加一个Windows主机上的文件夹路径，比如D:\vmshare，确认保存。回到Ubuntu里，兴冲冲打开终端输入ls /mnt/hgfs——结果返回空目录；再试vmware-hgfsclient，命令能执行但没输出；或者更糟，/mnt/hgfs根本不存在，连目录都没创建。这时候你搜“Ubuntu 22.04 共享文件夹”，满屏都是“添加网络位置失败”“输入的文件夹似乎无效”“hgfs not found”“Permission denied”……这些不是玄学报错，而是Ubuntu 22.04与VMware工具链之间一次静默却关键的代际断层。

核心关键词就藏在这句话里：Ubuntu 22.04、共享文件夹、open-vm-tools、vmware-hgfsclient、/mnt/hgfs。它们不是孤立名词，而是一条完整依赖链：VMware宿主机→VMware Tools驱动→open-vm-tools用户态服务→hgfs内核模块→/mnt/hgfs挂载点→你的文件。任何一个环节缺位、版本不匹配、权限未释放，整条链就断在中间。尤其Ubuntu 22.04默认不再预装open-vm-tools-desktop，也不自动加载vmw_vmci和vmwgfx等基础模块，更不会为你创建/mnt/hgfs这个挂载目录——它只提供工具包，不负责“保姆式配置”。所以你看到的“共享文件夹灰色不可用”“hgfs client无响应”“挂载点拒绝访问”，本质是系统在说：“工具我给你了，但你要自己把螺丝拧紧、电线接牢、开关打开。”

这个项目适合三类人：第一类是刚从Ubuntu 20.04或更早版本升级/重装的开发者，以为老方法照搬就行，结果全卡住；第二类是在VMware里跑ROS、BevFusion、PyTorch训练环境的AI工程师，需要频繁在Windows写代码、Ubuntu跑训练，共享文件夹是刚需中的刚需；第三类是教学场景下的Linux讲师或学生，要在课堂演示跨平台协作，却因共享失效耽误进度。它解决的不是“能不能用”的问题，而是“为什么明明按教程操作却始终不生效”的确定性故障。接下来我会带你一节一节拆开这条链，不跳步骤、不省参数、不回避坑点，从内核模块加载到挂载权限控制，全部实测验证过——包括你在Win11宿主机上遇到0x80070035错误、在Ubuntu里看到“Operation not permitted”提示、甚至vmware-hgfsclient返回空白时，该查哪一行日志、改哪个配置、重启哪个服务。

2. 整体设计思路：为什么必须绕过“一键安装”陷阱

很多人第一步就栽在“sudo apt install open-vm-tools”这行命令上。看起来干净利落，但Ubuntu 22.04的open-vm-tools包默认只装最小运行时（open-vm-tools），不包含图形支持（open-vm-tools-desktop）、不启用HGFS文件系统支持（open-vm-tools-dkms）、不自动注册systemd服务（open-vm-tools-service）。这就导致三个致命后果：一是vmware-hgfsclient命令存在但无法通信（缺少内核模块）；二是/mnt/hgfs目录不自动创建（缺少挂载服务）；三是即使手动挂载，也会因缺少vmw_vmci模块而报“Protocol error”。

所以我的整体设计思路非常明确：不依赖任何“全自动脚本”，不信任默认配置，从内核模块开始逐层验证、逐层激活。整个流程分为四个硬性阶段：

第一阶段是内核兼容性确认。Ubuntu 22.04内核版本为5.15.x（LTS），而VMware Workstation 16.2+、Fusion 12.2+才正式支持该内核的HGFS模块编译。如果你用的是Workstation 15.x或更老版本，dkms build会直接失败——这不是你操作问题，是版本墙。我建议先在VMware菜单栏点击“帮助→关于”，确认版本号；若低于16.2，请升级宿主机软件，这是不可绕过的前提。

第二阶段是模块级驱动安装。必须显式安装open-vm-tools-dkms，它会触发DKMS（Dynamic Kernel Module Support）机制，在当前内核下重新编译vmhgfs-fuse和vmw_vmci模块。注意：dkms status命令必须显示vmhgfs-fuse/2.5.5, 5.15.0-xx-generic, x86_64: installed才算成功。如果显示built但没installed，说明模块编译成功但未加载进内核，需手动sudo modprobe vmhgfs-fuse。

第三阶段是服务级挂载管理。Ubuntu 22.04不再使用rc.local或/etc/fstab硬编码挂载，而是通过open-vm-tools.service的vmtoolsd守护进程监听VMware Tools事件。但该服务默认不启用HGFS功能，必须修改/etc/vmware-tools/tools.conf配置文件，取消[hgfs]段下enabled = true的注释，并确保mountPoint = /mnt/hgfs路径存在且权限正确。

第四阶段是用户级访问控制。即使挂载成功，普通用户仍可能遇到Permission denied。这是因为/mnt/hgfs默认属主为root:root，且挂载选项含noexec,nosuid,nodev。解决方案不是简单chmod 777（有安全风险），而是通过/etc/fstab添加uid=1000,gid=1000,fmask=113,dmask=002参数，将挂载点所有权映射到当前用户，同时保留合理权限掩码。

这个设计绕开了所有“一键安装即用”的幻觉，因为VMware Tools在Linux端从来就不是黑盒。它本质是用户空间工具（vmtoolsd）+内核模块（vmhgfs-fuse）+挂载服务（vmware-mount）的组合体。Ubuntu 22.04的精简策略恰恰暴露了它的本来面目：你得亲手把每个齿轮装进传动轴，才能让动力传到车轮上。

3. 核心细节解析：五个必须死磕的关键节点

3.1 内核模块加载：vmhgfs-fuse vs vmhgfs 的历史分叉

很多教程还在教sudo modprobe vmhgfs，但在Ubuntu 22.04上这行命令大概率会报错modprobe: FATAL: Module vmhgfs not found in directory /lib/modules/5.15.0-xx-generic。这不是模块丢失，而是VMware在2019年后彻底废弃了旧版vmhgfs内核模块，全面转向vmhgfs-fuse——一个基于FUSE（Filesystem in Userspace）框架实现的用户态文件系统。它的优势是无需修改内核、兼容性更好、调试更方便；劣势是性能略低于原生内核模块，且依赖fuse内核支持。

验证方式很简单：执行lsmod | grep vmw，正常应看到两行：

vmhgfs_fuse 90112 0 fuse 196608 1 vmhgfs_fuse

如果只有fuse没有vmhgfs_fuse，说明DKMS编译失败或模块未加载。此时不要急着重装，先检查/var/lib/dkms/vmhgfs-fuse/2.5.5/build/make.log——90%的问题出在这里。常见错误有两类：一是/lib/modules/5.15.0-xx-generic/build软链接指向错误（应指向/usr/src/linux-headers-5.15.0-xx-generic）；二是gcc版本过高（Ubuntu 22.04默认gcc-11，而VMware Tools 12.2.0要求gcc-10），需临时降级：sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 --slave /usr/bin/g++ g++ /usr/bin/g++-10。

提示：vmhgfs-fuse模块名带下划线，不是短横线。拼错会导致modprobe找不到模块。你可以用find /lib/modules/$(uname -r) -name "*hgfs*"确认实际模块名。

3.2 挂载点权限：/mnt/hgfs 的创建时机与所有权陷阱

/mnt/hgfs目录在Ubuntu 22.04中不会自动创建。很多用户手动sudo mkdir /mnt/hgfs后发现依然无法访问，原因在于：vmtoolsd服务启动时会尝试挂载，但若目录已存在且属主不是root，它会静默失败。正确的做法是让服务自己创建——删除手动创建的目录，然后重启服务：sudo systemctl restart open-vm-tools.service。服务启动后会自动创建/mnt/hgfs，并设为root:root权限。

但这带来新问题：普通用户ls /mnt/hgfs仍提示Permission denied。根源在于挂载选项。执行mount | grep hgfs，你会看到类似：

vmhgfs-fuse on /mnt/hgfs type fuse.vmhgfs-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

其中user_id=0,group_id=0意味着只有root能读写。解决方案有两个层级：

• 轻量级方案：在/etc/vmware-tools/tools.conf中添加[hgfs]段，写入user = yourusername（替换为你的用户名），然后重启服务。这会让vmtoolsd以你的用户身份挂载。
• 生产级方案：禁用vmtoolsd自动挂载，改用/etc/fstab手动管理。添加行：vmhgfs-fuse /mnt/hgfs fuse.vmhgfs-fuse allow_other,uid=1000,gid=1000,fmask=113,dmask=002 0 0，其中uid=1000对应你用户的id -u值，fmask=113（二进制1001001）表示文件权限掩码，最终文件权限为664（rw-rw-r--），dmask=002使目录权限为775（rwxrwxr-x）。这样既保证安全，又免去每次sudo。

3.3 VMware Tools版本映射：宿主机与客户机的协同要求

Ubuntu 22.04的open-vm-tools包版本（如22.04.0-1ubuntu1）必须与VMware宿主机版本严格匹配。这不是营销话术，而是ABI（Application Binary Interface）兼容性问题。例如：

• VMware Workstation 16.1.0 → 支持open-vm-tools11.3.x
• VMware Workstation 16.2.0 → 要求open-vm-tools12.1.0+
• VMware Workstation 17.0.0 → 需要open-vm-tools12.2.0+

你可以在Ubuntu终端执行vmtoolsd --version查看实际版本，再对比VMware官网的 Compatibility Matrix 。如果版本不匹配，最稳妥的做法是从VMware官网下载对应版本的open-vm-tools源码包，而不是用APT安装。例如，Workstation 17.0.1对应open-vm-tools-12.2.0-18332333.tar.gz，解压后执行：

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-sysconfdir=/etc --without-x --without-gtk --without-pam --without-systemd --enable-deploypkg=no make && sudo make install

注意--without-x和--without-gtk参数，它们禁用图形依赖，避免在纯命令行环境中编译失败。

3.4 Windows宿主机配置：共享文件夹路径的隐藏规则

很多用户把Windows文件夹路径设为C:\Users\YourName\Documents\vmshare，结果Ubuntu里始终看不到。问题不在Linux端，而在Windows的共享策略。Windows 10/11对C:\Users下的子目录有严格UAC保护，VMware Tools进程（以SYSTEM权限运行）无法穿透其ACL（Access Control List）。解决方案是：

• 将共享文件夹移到非用户目录，如D:\vmshare或C:\vmshare（需管理员权限创建）；
• 或右键目标文件夹→“属性→共享→高级共享”，勾选“共享此文件夹”，点击“权限”，添加Everyone组并赋予“完全控制”；
• 最关键一步：在PowerShell（管理员）中执行icacls "D:\vmshare" /grant "NT AUTHORITY\SYSTEM:(OI)(CI)F"，赋予SYSTEM账户继承式完全控制权。

注意：icacls命令中的(OI)表示“对象继承”，(CI)表示“容器继承”，F表示“完全控制”。缺少任一标志，VMware Tools都无法访问该路径。

3.5 网络位置映射失败：SMB协议与HGFS的本质区别

当你在Ubuntu文件管理器里点击“其他位置→连接服务器”，输入smb://192.168.100.1/vmshare却提示“输入的文件夹似乎无效”，这不是HGFS问题，而是你误用了SMB协议。HGFS（Host-Guest File System）是VMware专有协议，工作在VMware虚拟网卡（如VMnet8）的私有网络层，不走TCP/IP栈；而SMB是标准网络文件协议，依赖Windows SMB服务开启和防火墙放行。两者完全无关。正确做法是：

• 确保VMware网络适配器设为“NAT模式”或“桥接模式”，而非“仅主机模式”（后者会切断HGFS通道）；
• 在VMware菜单栏点击“虚拟机→设置→选项→共享文件夹”，确认状态为“已启用”，且共享文件夹列表中有你的路径；
• 不要尝试用Nautilus的“连接服务器”功能，HGFS挂载点永远是/mnt/hgfs，不是网络地址。

如果/mnt/hgfs下有内容但Nautilus打不开，检查文件管理器是否启用FUSE支持：sudo apt install gvfs-fuse，然后注销重登录。

4. 实操过程：从零开始的七步精准复现

4.1 步骤一：确认宿主机与客户机基础环境

首先，在Windows宿主机上打开VMware Workstation，点击“帮助→关于”，记录版本号（如17.0.1 build-21594870）。同时确认虚拟机设置中：

• “硬件→网络适配器”设为“NAT模式”；
• “选项→共享文件夹”已勾选“总是启用”，且至少添加一个共享文件夹（路径不含中文、空格、特殊字符，如D:\vmshare）；
• “选项→客户机隔离”未勾选“禁用拖放和复制粘贴”（否则HGFS可能被联动禁用）。

在Ubuntu 22.04终端执行以下命令，获取关键信息：

# 查看内核版本 uname -r # 应返回 5.15.0-xx-generic # 查看open-vm-tools安装状态 dpkg -l | grep open-vm-tools # 查看当前用户ID id -u # 记录此数字，后续fstab中要用

如果dpkg输出为空，说明未安装任何open-vm-tools包，需进入步骤二；如果已安装但版本过低（如11.x），需先卸载：sudo apt remove --purge open-vm-tools*。

4.2 步骤二：安装匹配版本的open-vm-tools套件

根据宿主机版本选择安装方式。若Workstation ≥16.2，执行：

# 安装完整套件（含DKMS、桌面支持、服务） sudo apt update sudo apt install open-vm-tools open-vm-tools-desktop open-vm-tools-dkms # 验证DKMS编译状态 sudo dkms status | grep vmhgfs # 应显示 installed，否则查看 /var/lib/dkms/vmhgfs-fuse/*/build/make.log

若宿主机为Workstation 17.0.1，推荐从源码安装：

# 下载官方源码（以12.2.0为例） wget https://github.com/vmware/open-vm-tools/releases/download/stable-12.2.0/open-vm-tools-12.2.0-18332333.tar.gz tar -xzf open-vm-tools-12.2.0-18332333.tar.gz cd open-vm-tools-12.2.0 # 安装编译依赖 sudo apt install build-essential linux-headers-$(uname -r) libdumbnet-dev libicu-dev libmspack-dev libssl-dev libxml2-dev # 配置并编译（禁用GUI和PAM） ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --without-x --without-gtk --without-pam --without-systemd --enable-deploypkg=no make -j$(nproc) # 安装（覆盖系统包） sudo make install

安装完成后，重启服务：sudo systemctl restart open-vm-tools.service。

4.3 步骤三：强制加载内核模块并验证

即使DKMS显示installed，模块也可能未加载。执行：

# 卸载可能冲突的旧模块 sudo modprobe -r vmhgfs-fuse sudo modprobe -r vmw_vmci # 加载必需模块 sudo modprobe vmw_vmci sudo modprobe vmhgfs-fuse # 验证加载状态 lsmod | grep -E "(vmw|fuse)" # 正常输出应含 vmhgfs_fuse 和 fuse

如果modprobe vmhgfs-fuse报错Required key not available，说明内核模块签名验证失败（常见于Secure Boot启用时）。临时解决方案：

# 临时禁用Secure Boot（需重启进入BIOS设置） # 或者为模块签名（较复杂，不推荐新手） sudo mokutil --disable-validation # 重启后按提示输入密码，选择“Enroll MOK”→“Continue”→“Yes”

4.4 步骤四：配置vmtoolsd服务启用HGFS

编辑配置文件：

sudo nano /etc/vmware-tools/tools.conf

取消以下段落的注释，并确保内容如下：

[hgfs] enabled = true mountPoint = /mnt/hgfs user = yourusername # 替换为你的实际用户名，如 ubuntu

保存后重启服务：

sudo systemctl restart open-vm-tools.service # 等待10秒，检查挂载点 ls /mnt/hgfs

如果/mnt/hgfs存在且列出Windows共享文件夹名，说明服务级挂载成功；如果目录为空，执行sudo journalctl -u open-vm-tools.service -n 50 --no-pager查看最近50行日志，重点搜索hgfs或error关键字。

4.5 步骤五：修复挂载点权限（两种方案任选）

方案A（推荐新手）：修改tools.conf指定用户
已在步骤四完成，只需确认user = yourusername正确，且该用户属于plugdev组：

sudo usermod -aG plugdev $USER # 注销重登录生效

方案B（推荐生产环境）：fstab手动挂载

# 卸载现有挂载 sudo umount /mnt/hgfs # 编辑fstab sudo nano /etc/fstab # 添加一行（替换your_uid为id -u输出值）： vmhgfs-fuse /mnt/hgfs fuse.vmhgfs-fuse allow_other,uid=1000,gid=1000,fmask=113,dmask=002 0 0 # 创建挂载点并挂载 sudo mkdir -p /mnt/hgfs sudo mount -a # 验证权限 ls -ld /mnt/hgfs # 应显示 drwxrwxr-x 1 youruser yourgroup ...

4.6 步骤六：Windows宿主机权限加固

在Windows PowerShell（管理员）中执行：

# 替换 D:\vmshare 为你的实际路径 icacls "D:\vmshare" /grant "NT AUTHORITY\SYSTEM:(OI)(CI)F" icacls "D:\vmshare" /grant "Everyone:(OI)(CI)R" # 刷新共享 net stop server && net start server

然后在VMware中右键虚拟机→“重新安装VMware Tools”，强制刷新HGFS通道。

4.7 步骤七：终极验证与故障快照

创建测试文件验证全流程：

# 在Ubuntu中创建测试文件 echo "Hello from Ubuntu 22.04" > /mnt/hgfs/test.txt # 切换到Windows，打开D:\vmshare，确认test.txt存在且内容正确 # 在Windows中修改文件 # 回到Ubuntu，执行 cat /mnt/hgfs/test.txt # 应看到更新后的内容 # 检查实时同步延迟（正常应在1秒内） watch -n 1 'ls -la /mnt/hgfs'

如果以上全部通过，恭喜你完成了Ubuntu 22.04共享文件夹的全链路打通。此时你可以安全地：

• 在VS Code for Windows中编辑Python脚本，Ubuntu终端直接python3 /mnt/hgfs/script.py运行；
• 将ROS工作空间放在/mnt/hgfs/ros_ws，在Ubuntu中source /mnt/hgfs/ros_ws/devel/setup.bash；
• 用Blender加载Windows端的纹理贴图资源，路径为/mnt/hgfs/textures/。

注意：HGFS不支持硬链接、符号链接、文件锁（flock）等高级文件系统特性。若你的应用依赖这些功能（如Git LFS、Docker构建缓存），请改用rsync或sshfs替代。

5. 常见问题与排查技巧实录：那些搜不到答案的真坑

5.1 问题速查表：症状、原因、解决方案

5.2 独家避坑技巧：来自三年踩坑的实战经验

技巧一：用strace定位挂载失败点
当mount -t fuse.vmhgfs-fuse .host:/ /mnt/hgfs失败时，不要只看错误信息。执行：

sudo strace -e trace=openat,connect,write,mount -f mount -t fuse.vmhgfs-fuse .host:/ /mnt/hgfs 2>&1 | grep -E "(openat|connect|mount)"

输出中若出现connect(3, {sa_family=AF_UNIX, sun_path="/var/run/vmtoolsd.sock"}, 110) = -1 ENOENT，说明vmtoolsd服务未运行；若出现mount("vmhgfs-fuse", "/mnt/hgfs", "fuse.vmhgfs-fuse", MS_MGC_VAL, "allow_other") = -1 EPERM，则是权限问题。strace比日志更底层，能直击故障源头。

技巧二：HGFS通道自检脚本
把以下脚本保存为hgfs-check.sh，一键诊断：

#!/bin/bash echo "=== HGFS Self-Check ===" echo "1. Kernel modules:" lsmod | grep -E "(vmw|fuse)" || echo "MISSING" echo "2. vmtoolsd service:" systemctl is-active open-vm-tools.service || echo "INACTIVE" echo "3. Mount point:" ls -ld /mnt/hgfs 2>/dev/null || echo "NOT FOUND" echo "4. HGFS client:" vmware-hgfsclient 2>/dev/null | head -5 || echo "NO OUTPUT" echo "5. Shared folders:" vmware-hgfsclient 2>/dev/null | wc -l | sed 's/^ *//;s/ *$//' | awk '{print "COUNT: "$1}'

赋予执行权限chmod +x hgfs-check.sh，运行./hgfs-check.sh，5秒内定位问题环节。

技巧三：Windows防火墙的隐形拦截
即使关闭了Windows防火墙，某些安全软件（如McAfee、Bitdefender）会劫持vmtoolsd.exe进程的网络调用。临时解决方案：

• 在Windows任务管理器中结束vmtoolsd.exe进程；
• 以管理员身份运行CMD，执行："C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" --cmd "info-get guestinfo.ipaddress"；
• 如果返回IP地址，说明进程正常；如果卡住，检查安全软件是否阻止了vmtoolsd.exe。

技巧四：Ubuntu休眠唤醒后的HGFS失效
Ubuntu 22.04休眠后，vmhgfs-fuse模块常被卸载。添加唤醒后自动重载脚本：

sudo nano /lib/systemd/system-sleep/hgfs-reload

内容为：

#!/bin/sh case $1/$2 in pre/*) # 休眠前卸载 umount /mnt/hgfs 2>/dev/null ;; post/*) # 唤醒后重载模块并挂载 modprobe vmw_vmci modprobe vmhgfs-fuse systemctl restart open-vm-tools.service sleep 2 mount /mnt/hgfs 2>/dev/null ;; esac

赋予执行权限：sudo chmod +x /lib/systemd/system-sleep/hgfs-reload。

5.3 那些“搜不到答案”的诡异现象

现象：vmware-hgfsclient能列出共享文件夹，但ls /mnt/hgfs为空
原因：vmtoolsd服务启用了HGFS，但挂载点/mnt/hgfs被其他进程占用（如旧的gvfs挂载）。执行fuser -v /mnt/hgfs查看占用进程，sudo fuser -km /mnt/hgfs强制释放，再重启服务。

现象：共享文件夹在Nautilus中显示，但双击打开报“Failed to open directory”
原因：GNOME文件管理器的gvfs组件与vmhgfs-fuse冲突。解决方案：卸载gvfs-fuse（sudo apt remove gvfs-fuse），改用Thunar或PCManFM等轻量文件管理器，或在Nautilus中直接访问/mnt/hgfs路径而非“其他位置”。

现象：在ROS工作空间中catkin_make报Permission denied
原因：/mnt/hgfs挂载时dmask=002使目录权限为775，但catkin_make需要755。临时方案：sudo chmod 755 /mnt/hgfs/ros_ws/src；长期方案：在fstab中改为dmask=022。

我在实际部署BevFusion复现环境时，曾因dmask=002导致colcon build失败三次。后来发现colcon在创建build目录时，会继承父目录的setgid位（由dmask=002触发），而ROS的ament_cmake对此敏感。把dmask改为022后问题消失——这种细节，官方文档从不提及，只能靠实测。

6. 后续扩展：当HGFS不够用时的替代方案

HGFS是VMware生态的最优解，但并非万能。当你遇到以下场景时，该考虑替代方案：

• 需要跨平台实时同步（如Windows、macOS、Ubuntu三端协作）：用Syncthing。它基于Bittorrent协议，加密传输，支持冲突解决，且不依赖虚拟化平台。在Ubuntu中：sudo apt install syncthing，浏览器访问http://localhost:8384配置，Windows端下载Syncthing客户端，添加同一文件夹即可。
• 需要高性能I/O（如训练大型模型读取TFRecord数据集）：用NFS。在Ubuntu中安装NFS服务端：sudo apt install nfs-kernel-server，编辑/etc/exports添加/mnt/nfs *(rw,sync,no_subtree_check)，然后sudo exportfs -a。Windows需启用“适用于Linux的Windows子系统（WSL2）”，在WSL2中sudo mount -t nfs 192.168.100.1:/mnt/nfs /mnt/nfs。
• 需要版本控制集成（如Git仓库跨平台开发）：用SSHFS。在Ubuntu中：sudo apt install sshfs，创建挂载点mkdir ~/winrepo，执行sshfs yourname@192.168.100.1:/d/vmshare ~/winrepo -o uid=$(id -u),gid=$(id -g),umask=002。这样Git操作完全透明，且SSH加密保障安全。

最后再分享一个小技巧：如果你只是偶尔需要传几个文件，别折腾HGFS。在VMware菜单栏点击“虚拟机→拖放→启用”，然后直接把文件从Windows资源管理器拖进Ubuntu桌面——它底层用的是VMware Tools的剪贴板通道，比HGFS更轻量，且100%兼容Ubuntu 22.04。我现在的日常开发流是：小文件拖放，大项目HGFS，数据集NFS，Git仓库SSHFS。工具没有高下，只有合不合适。