1. 把三条链路搞清楚剪贴板、拖拽、共享文件夹不是一回事很多人第一次在 VMware Workstation 里装完 Ubuntu第一反应是我怎么把 Windows 桌面上的文件拖进去。拖了一下没反应复制一段文字粘不进去于是开始到处搜VMware 共享文件夹怎么开。结果折腾半天把三个互相独立的功能当成一个问题在处理越弄越乱。这三件事——共享剪切板、拖拽文件、共享文件夹——在 VMware 里走的是三条不同的链路依赖的组件也不完全一样任何一个环节缺了都会表现为没反应但排查方向完全不同。先给个结论级的区分共享剪切板和拖拽属于图形会话级功能需要客户机桌面里跑着一个和 VMware 通信的用户态进程共享文件夹属于文件系统级功能走的是主机侧的一个虚拟块设备/文件系统通道最终在 Ubuntu 里挂载成一个目录。前者断了你什么也看不见后者断了你用vmware-hgfsclient还能看到共享名只是目录里空的。理解这一层后面的排查才不会瞎撞。这篇内容写给三类人刚在 VMware 里装完 Ubuntu、想把开发环境打通的新手共享文件夹每次重启就失效、被自动挂载折腾过的老用户以及升级了 Ubuntu 24.04 LTS 之后发现剪切板突然不灵、需要快速定位的人。我会把宿主机侧怎么设置、Ubuntu 侧挂载命令怎么写、uid/gid 参数怎么算、开机自动挂载用哪种方案最稳全部按实操顺序讲清楚中间穿插我自己踩过的坑。1.1 三条通道各自解决什么问题共享剪切板是让你在宿主机和客户机之间复制文本有时包括图片。你在 Windows 里 CtrlC 一段命令切到 Ubuntu 里 CtrlV能粘上这就是它在工作。它依赖的是open-vm-tools-desktop这个包提供的用户会话代理进程以及 VMware Workstation 里客户机隔离那一栏的两个开关。注意它和拖拽是两个独立复选框可以只开一个。拖拽文件是从宿主机文件管理器直接把文件拖进 Ubuntu 桌面。它同样依赖桌面代理但对文件大小和类型更敏感大文件拖拽经常表现为进度条卡住或者中途失败。我的经验是小文件用拖拽没问题超过几十 MB 的东西老老实实走共享文件夹。共享文件夹是把宿主机上的某个目录映射进 Ubuntu变成一个普通目录。这条路和图形会话无关——哪怕 Ubuntu 是纯命令行、没装桌面共享文件夹照样能用。它依赖的是open-vm-tools不含 desktop 后缀提供的vmhgfs-fuse工具。所以如果你装的是 Ubuntu Server 版共享文件夹能用剪切板用不了这是正常的不是配置错了。把这三者的依赖关系列成表一眼就能看出该装什么功能依赖组件是否需要桌面宿主机侧开关位置共享剪切板open-vm-tools-desktop是虚拟机设置 → 选项 → 客户机隔离拖拽文件open-vm-tools-desktop是同上共享文件夹open-vm-tools否虚拟机设置 → 选项 → 共享文件夹1.2 为什么我推荐 open-vm-tools 而不是 VMware Tools 光盘这是新手最容易走错的一步。装完 Ubuntu 后VMware Workstation 菜单里会提示你安装 VMware Tools点一下会挂载一个 ISO 镜像里面是一堆 tar.gz 和 perl 脚本。传统教程会让你解压、sudo ./vmware-install.pl一路回车。我不推荐这么做尤其是在 Ubuntu 18.04 之后的版本上。原因有三个第一光盘版 VMware Tools 需要针对当前内核编译vmhgfs、vmxnet等内核模块Ubuntu 内核一升级模块就对不上重启后报VMware Tools 继续运行脚本未能在虚拟机中成功运行第二Ubuntu 官方仓库里已经有open-vm-tools是 Canonical 和 VMware 一起维护的随内核更新一起走省心第三光盘版的安装脚本在新版内核上经常编译失败报错信息还特别晦涩。所以我的固定操作是先挂载 VMware Tools 光盘如果它已经自动挂载了就把它卸载掉然后打开终端装仓库版本。sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktop sudo rebootopen-vm-tools-desktop是给带桌面环境用的它会把open-vm-tools作为依赖自动装上。装完必须重启因为要加载相关服务并让用户会话代理起来。重启后你在 Ubuntu 里执行vmtoolsd --version能打印出版本号就说明核心组件到位了。注意如果你之前用光盘版装过一次并失败残留的/usr/bin/vmware-*文件可能和仓库版冲突。保险做法是先卸载光盘版残留如果有/usr/bin/vmware-uninstall-tools.pl就执行它再装仓库版。1.3 装之前先确认的三件事在动手配共享之前有三件事必须先确认否则后面会浪费大量时间在错误的方向上。第一虚拟机设置里的共享文件夹开关是否打开。这个开关是宿主机侧的总闸默认是已禁用。只要它是禁用的Ubuntu 里怎么挂载都是空的vmware-hgfsclient也不会输出任何东西。很多人挂载命令写对了但目录空问题就在这儿。第二Ubuntu 里有没有vmhgfs-fuse这个可执行文件。执行which vmhgfs-fuse如果没有输出说明open-vm-tools没装好或者装的是不含该工具的精简版本。第三当前登录用户有没有 sudo 权限。挂载到/mnt下的目录需要 root普通用户直接跑会报fuse: mountpoint is not accessible或者权限拒绝。这三件事确认完再往下走基本就是一路顺畅。2. 共享文件夹宿主机侧怎么配Ubuntu 侧怎么挂共享文件夹是这三件事里最实用的一个因为它是持久可用的——只要挂载好了Ubuntu 里的任何程序都能像访问本地目录一样访问宿主机文件编译、跑脚本、读日志都不受影响。但它的坑也最多主要集中在三个地方宿主机侧的路径格式、Ubuntu 侧的挂载命令参数、以及开机自动挂载的时序问题。这一章先把前两个解决掉。2.1 宿主机 VMware Workstation 侧的设置细节关掉虚拟机或者至少确保能改设置进入虚拟机 → 设置 → 选项 → 共享文件夹。这里有个文件夹共享的单选总是启用和在下次关机或挂起前一直启用。选总是启用否则重启虚拟机后共享就没了这也是重启后共享失效这个问题的常见原因之一。然后点添加走一个向导。名称Name建议用纯英文、不含空格比如share、work、code。这个名称就是 Ubuntu 里.host:/下面看到的目录名用中文或者空格会让你在命令行里多敲一堆转义字符没必要给自己找麻烦。主机路径选好之后下面有两个复选框启用此共享和只读。如果你只是往虚拟机里拷资料勾只读更安全能避免虚拟机里的误操作把宿主机文件删了。如果是双向协作比如宿主机 IDE 写代码、虚拟机里编译就得取消只读。提示共享文件夹的路径不要选整个盘符根目录也不要选系统盘上正在被其他程序占用的目录。选一个专门的、独立的目录比如D:\vm-share能省掉一堆莫名其妙的权限和占用问题。设置完成后不用重启宿主机但 Ubuntu 侧需要重新触发一次挂载检测。如果你想立刻验证先别关虚拟机设置窗口去 Ubuntu 终端里跑vmware-hgfsclient正常情况下会把你刚配置的共享名打印出来。2.2 Ubuntu 侧扫描与手动挂载含参数计算进 Ubuntu第一步是确认宿主机到底共享了哪些目录vmware-hgfsclient如果这条命令输出了你刚才设置的名称比如share说明主机侧的虚拟通道是通的剩下就是挂载。如果什么都没输出回到 2.1 检查开关或者重启一次虚拟机。接下来创建挂载点并挂载。我习惯把整个共享根挂到/mnt/hgfs这样以后在宿主机上新增共享目录不用改挂载配置sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other -o uid1000 -o gid1000这里的.host:/就是宿主机共享根的固定写法不要改。几条参数逐个解释一下因为这几个参数就是权限问题的全部答案allow_other是 FUSE 的参数意思是允许非 root 用户访问这个挂载点。不加它的话挂载出来的目录只有 root 能进你在普通用户下cd /mnt/hgfs会直接 Permission denied。这是最常见的挂载成功但打不开的原因。uid1000和gid1000是把挂载出来的文件属主和属组映射成指定的数字 ID。Ubuntu 桌面版安装时创建的第一个用户UID 和 GID 通常就是 1000但不要假设一定要查一下id -u # 输出当前用户的 UID id -g # 输出当前用户的 GID把查出来的数字填进去。填错的后果是文件虽然能读写但属主变成别人某些 IDE 会提示文件只读或者保存时报权限错误。挂载完成后验证ls -l /mnt/hgfs能看到共享名就往里进。如果目录是空的但vmware-hgfsclient有输出先检查宿主机侧那个只读复选框和目录里到底有没有文件。还有一种用法是只挂某一个共享名比如只把share这一个目录挂到/home/you/sharemkdir -p ~/share sudo vmhgfs-fuse .host:/share ~/share -o allow_other -o uid$(id -u) -o gid$(id -g)注意~在 sudo 下会被解析成 root 的家目录所以这里要写绝对路径或者先mkdir好再挂。这个细节坑过我不止一次。2.3 权限问题的根源uid/gid 与 allow_other共享文件夹的权限问题说穿了就是 FUSE 的一次身份转换。VMware 提供的是一个虚拟文件系统它不知道 Ubuntu 里的用户是谁默认把所有文件的属主设成 root、权限设成 root 可读写。你以普通用户身份访问自然处处受限。uid/gid参数解决的是属主是谁allow_other解决的是别人能不能进来。这两个是必配项。如果你还想控制新建文件的权限掩码可以再加一个umask比如sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other -o uid1000 -o gid1000 -o umask022umask022意味着新建文件权限是 755 减去掩码的结果跟系统默认行为一致。这个参数不是必须的但在多人共用一个虚拟机的场景下有用。另一个常见现象是能读不能写。这通常不是 Linux 权限问题而是宿主机侧勾了只读或者宿主机那个目录本身是只读介质。先看宿主机再看权限顺序别搞反。还有一个更隐蔽的坑目录名带空格或者中文。挂载本身没问题但你在 fstab 里写的时候会被解析成两段参数导致整个挂载失败。命名规范这件事从创建共享的第一秒就该守住。如果你需要让 Docker 容器也能访问共享目录光配allow_other还不够因为容器用的是宿主机上的 Docker 守护进程的权限上下文。这种情况下更稳的做法是把共享目录再 bind mount 进容器或者干脆用 NFS/SMB 方案不要硬扛 FUSE。3. 共享剪贴板和拖拽失效原因与逐层排查剪切板这个问题比共享文件夹更让人抓狂因为它是看不见的——没有任何报错就是复制粘贴没反应。而且它和桌面环境、显示服务器协议Xorg 还是 Wayland强相关Ubuntu 从 21.04 开始默认用 Wayland导致一大批老教程里的解决方案直接失效。3.1 前提条件与桌面组件的关系剪切板共享的第一个前提是宿主机侧的开关虚拟机设置 → 选项 → 客户机隔离里面有两个复选框启用拖放和启用复制粘贴。这两个默认是勾上的但如果你新建虚拟机时选了某些精简配置或者克隆的虚拟机继承了一个关掉的模板它们可能是关闭的。先检查这里。第二个前提是客户机里跑着用户态的代理进程。open-vm-tools-desktop装完之后每个登录会话里会启动一个vmtoolsd用户进程它负责和 VMware 的虚拟通道通信。你可以这样确认它活着pgrep -a vmtoolsd正常应该看到两个进程一个是 root 的系统级服务一个是当前用户的会话级进程。如果只有 root 那个说明桌面组件没起来或者当前会话不是图形会话。这时候可以试着手动重启用户级服务systemctl --user restart vmtoolsd如果这条命令报 Failed to connect to bus说明你当前不在图形会话里比如是通过 SSH 连进来的这很正常剪切板只在本地图形会话中生效。还有一个容易被忽略的点客户机里必须处于已登录的图形会话。如果你把 Ubuntu 锁屏了或者停在登录界面剪切板共享是不工作的。这不是 bug是设计如此因为代理进程挂在用户会话下。3.2 Wayland/Xorg 会话的坑Ubuntu 20.04 之后桌面默认会话在 Xorg 和 Wayland 之间切换过几次。到 22.04 / 24.04默认是 Wayland。问题在于VMware 的剪切板共享机制在 Wayland 下支持得并不完整尤其是拖拽功能经常完全没反应。怎么判断自己现在是哪个会话echo $XDG_SESSION_TYPE输出x11就是 Xorg输出wayland就是 Wayland。如果确认是 Wayland 且剪切板不工作最直接的解法是切回 Xorg。方式有两种第一种是在登录界面切换。注销当前用户回到 GDM 登录界面点右下角的齿轮图标选 Ubuntu on Xorg再登录。这个方式临时生效重启后可能又回到默认。第二种是永久禁用 Wayland。编辑/etc/gdm3/custom.confsudo nano /etc/gdm3/custom.conf找到这一行#WaylandEnablefalse把前面的#去掉变成WaylandEnablefalse保存后重启。这样 GDM 就不会再启动 Wayland 会话剪切板和拖拽会明显稳定。注意切到 Xorg 之后如果你平时依赖 Wayland 的某些特性比如更好的多显示器缩放体验可能会有取舍。但对虚拟机场景来说Xorg 的兼容性明显更好值得换。3.3 一次完整的排查流程含命令我把剪切板失效的排查整理成一个固定顺序从外往里一层层剥避免东试一下西试一下第一步查宿主机开关。虚拟机设置 → 选项 → 客户机隔离两个复选框必须勾上。第二步查包是否装全。dpkg -l | grep open-vm-tools应该有open-vm-tools和open-vm-tools-desktop两行。第三步查进程。pgrep -a vmtoolsd确认有会话级进程。第四步查会话类型。echo $XDG_SESSION_TYPE如果是 wayland 且前面几步都正常基本可以确定是协议兼容问题。第五步重启用户级代理。systemctl --user restart vmtoolsd然后立刻测试复制粘贴。有时候只是代理进程卡死了重启一下就好。第六步如果以上都没用重启整个客户机。VMware 的虚拟通道偶发会进入异常状态重启客户机比重启宿主机便宜得多。这套流程走下来我遇到过的九成问题都能定位。剩下那一成通常是快照。如果你在剪切板正常的时候打了快照之后回滚有时会残留一个失效的通道状态这时候需要重启客户机而不是恢复快照。顺便说一个反向的坑有些人为了追求纯净把open-vm-tools-desktop卸载了只留open-vm-tools。结果共享文件夹一切正常剪切板完全没反应然后花两小时怀疑人生。这两个包的功能边界心里要有数。4. 开机自动挂载三种方案怎么选手动挂载的共享文件夹有个致命问题重启就没了。每次开机都要敲一遍vmhgfs-fuse命令谁受得了。自动挂载这件事社区里有三种常见方案各有各的适用场景和坑这里逐个说清楚。4.1 fstab 方案最省事但最容易翻车最直觉的做法是写进/etc/fstab因为它就是干这个的。写法大概是这样.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,defaults,uid1000,gid1000,nofail,x-systemd.automount 0 0注意几点文件系统类型写fuse.vmhgfs-fuse不是vmhgfs选项里必须有allow_othernofail意思是挂载失败也不阻塞开机很重要否则挂载失败可能让你进不了系统x-systemd.automount让 systemd 在第一次访问该目录时才真正挂载能绕过一部分时序问题。但 fstab 方案的核心风险是时序。vmhgfs-fuse依赖 VMware 的虚拟块通道这个通道是由vmware-vmblock-fuse.service提供、挂载在/run/vmblock-fuse的。如果你的 fstab 条目在 systemd 启动的早期就被处理而此时 vmblock 还没就绪挂载就会失败。重启后你看到的现象是/mnt/hgfs空着手动sudo mount -a一下又好了——这就是典型的时序问题。要彻底解决可以在 fstab 选项里加上对服务的强依赖.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,uid1000,gid1000,nofail,x-systemd.automount,x-systemd.requiresvmware-vmblock-fuse.service 0 0加上x-systemd.requires之后systemd 会等 vmblock 服务起来再挂。这个写法不常见但在我自己的 Ubuntu 22.04 和 24.04 上验证过是有效的。改动 fstab 之前一定要先备份sudo cp /etc/fstab /etc/fstab.bak改完先运行sudo mount -a验证语法和挂载效果确认没问题再重启。如果直接重启而 fstab 写错了遇到的问题是开机进不了图形界面得进恢复模式改回来很麻烦。4.2 systemd 单元方案最稳适合长期使用如果你不想在 fstab 里和时序较劲写一个独立的 systemd service 是更可控的方案。因为 service 可以显式声明After和Requires把依赖关系写死。先创建文件/etc/systemd/system/mnt-hgfs.service[Unit] DescriptionMount VMware Shared Folders Aftervmware-vmblock-fuse.service Requiresvmware-vmblock-fuse.service [Service] Typesimple ExecStart/usr/bin/vmhgfs-fuse -f .host:/ /mnt/hgfs -o allow_other,uid1000,gid1000,umask022 ExecStop/bin/umount /mnt/hgfs [Install] WantedBymulti-user.target几个关键点解释一下。-f是让vmhgfs-fuse保持在前台运行因为Typesimple要求主进程不能 fork 之后就退出否则 systemd 会认为服务启动失败。After和Requires保证 vmblock 服务先起来。ExecStop负责在服务停止时卸载。写完之后sudo systemctl daemon-reload sudo systemctl enable --now mnt-hgfs.service systemctl status mnt-hgfs.service状态显示active (running)就对了。以后重启虚拟机systemd 会自动把这个服务拉起来不需要你干预。这个方案还有个好处服务挂了能立刻看出来。systemctl status一看就知道是不是挂载失败比 fstab 那种静静地失败友好得多。想知道具体报错就journalctl -u mnt-hgfs.service -e。我自己的虚拟机现在全用这个方案。唯一需要注意的是如果你换了用户名或者 UID 变了比如重装系统后重建用户要回来改 uid/gid否则挂载出来的文件属主又不对了。4.3 桌面自启动与 rc.local轻量但局限还有两种更轻量的做法适合临时用或者不想碰系统配置的人。第一种是在 GNOME 的启动应用程序里加一条命令。打开启动应用程序首选项新增一项命令填/usr/bin/vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other,uid1000,gid1000问题很明显它只在图形登录之后才执行而且需要挂载点已经存在、当前用户对挂载点有权限还得解决 sudo 的问题挂载需要 root。所以这条命令实际上通常得配合pkexec或者让/mnt/hgfs预先 chown 给当前用户比较别扭。我一般不推荐。第二种是/etc/rc.local。新建这个文件写挂载命令然后sudo chmod x /etc/rc.local再sudo systemctl enable rc-local.service。它比桌面自启动早一些但仍然不保证在 vmblock 之后执行时序上不如 systemd service 可靠。而且 Ubuntu 从 20.04 之后默认没有 rc-local.service需要手动启用多了一步。这两条路我不是说不能用而是说既然 systemd 单元方案写得也不复杂何必用更脆的方式。4.4 三种方案横向对比把三种方案的特性摊开对比选哪个一目了然方案启动时机时序可靠性需要 sudo故障可见性适用场景/etc/fstabsystemd 早期需额外参数是差熟悉 fstab 的老用户systemd service等 vmblock 之后高是好长期使用的开发机桌面自启动图形登录后中需要绕过中临时用、单用户桌面/etc/rc.local多用户目标前中是差无桌面环境如果你是长期在虚拟机里做开发我建议直接上 systemd service一次性配好后面几年都不用管。如果你是偶尔用一下手动挂载其实也够了——反正重启频率不高。5. 高频故障实录与避坑清单前面四章讲的是怎么做这一章讲做不成怎么办。我把这几年在虚拟机里折腾共享遇到的典型故障整理成一张速查表再加上几条文档里不会写的经验。5.1 故障速查表先看现象再对原因最后按解法处理。现象最可能的原因处理方式vmware-hgfsclient无输出宿主机共享开关未启用虚拟机设置里勾总是启用挂载成功但目录为空共享名写错 / 挂载了错误的子路径用.host:/挂根目录核对目录能进但提示权限不足缺allow_other重新挂载并加上该参数能读不能写宿主机勾了只读或文件属主不对取消只读核对 uid/gid重启后共享消失未配置自动挂载用 systemd service 方案重启后/mnt/hgfs空但mount -a后正常fstab 时序问题加x-systemd.requires或改用 service剪切板完全无反应未装 desktop 包 / 开关关闭装open-vm-tools-desktop剪切板时好时坏Wayland 兼容问题切到 Xorg 会话安装 VMware Tools 时报脚本失败光盘版与新内核不兼容卸载光盘版改用 open-vm-tools内核升级后共享全挂光盘版内核模块未重建同上改用 FUSE 方案这张表里的每一条我基本都亲自遇过。看起来最玄学的是最后两条但原因其实很朴素光盘版 VMware Tools 依赖内核模块内核一换就得重编译open-vm-tools 走的是 FUSE用户态实现内核升级不受影响。这就是我一直坚持用仓库版本的技术理由。5.2 那些文档里不会写的心得第一条心得是先确认失败发生在哪一层。共享文件夹这条链路上有四个关键节点宿主机开关、虚拟通道、挂载命令、文件权限。每次出问题先用vmware-hgfsclient快速判断是前两层的问题还是后两层的问题能省掉大量试错。第二条心得是挂载点不要用/mnt/hgfs这种系统级路径来存重要东西。因为/mnt下的目录在某些发行版里会被临时清理或者被其他挂载覆盖。我自己习惯在/home/you/vm-share建软链接指向/mnt/hgfs日常操作走软链接改配置时改系统路径两边不打架。这样做还有个附带好处IDE 里打开项目路径短看着清爽。第三条是关于 umask 和 setgid。如果你需要在共享目录里和宿主机上的其他人协作可以用umask002让新建文件对同组可写再给目录设 setgid 位。不过这个用法比较少见绝大多数单人开发场景用umask022就够了别过度设计。第四条是快照会继承挂载状态但不会继承运行时进程。如果你在共享正常的时候打了快照之后回滚挂载点目录里可能有残留的挂载记录表现为目录里有个诡异的空文件夹删不掉。这时候先mount | grep hgfs看有没有残留挂载有的话sudo umount -l /mnt/hgfs懒卸载掉再重新挂。第五条是不要把共享目录当数据库用。FUSE 的性能和一致性跟本地 ext4 完全不在一个量级SQLite 文件放在共享目录里跑写并发高的时候非常容易锁死。要跑数据库文件放 Ubuntu 本地磁盘共享目录只用来交换源码和配置。最后一条也是被问得最多的如果 Ubuntu 是 Server 版、没有图形界面剪切板和拖拽是绝对用不了的这不是配置问题是架构上就没这条通道。别在这上面浪费时间直接用scp或者共享文件夹传文件效率更高。5.3 关于性能和日常维护的一点补充共享文件夹的读写速度受虚拟通道影响实际跑下来通常是宿主机本地磁盘速度的一半到三分之二小文件多的时候损耗更明显。如果你要编译一个几万文件的大项目源码放共享目录、编译输出放虚拟机本地磁盘是更合理的安排——用符号链接或者构建脚本里的输出路径参数就能做到。日常维护上我建议定期检查三件事systemctl status mnt-hgfs.service是否还是 runningdf -h | grep hgfs看挂载点容量是否正常以及每次 Ubuntu 大版本升级后重新验证一次剪切板和挂载。Ubuntu 24.04 LTS 升级后我就重新折腾过一次 Wayland 的问题提前发现比某天突然不能复制粘贴要好。还有一个很实用的小技巧把常用的挂载确认命令做成一个 alias 或者小脚本比如alias checkhgfsvmware-hgfsclient mount | grep hgfs ls -l /mnt/hgfs每次开机后随手跑一下三秒确认所有通道正常比等到用的时候才发现问题从容得多。我个人在虚拟机里跑开发环境有六七年了从最早的 VMware Tools 光盘一路折腾到现在全用 open-vm-tools 加 systemd 单元最大的体会是把共享这三件事拆开理解和配置比混在一起瞎调要高效得多。共享文件夹交给 systemd 管剪切板依赖桌面组件和会话协议两者互不影响出了问题也知道该查哪张表。至于自动挂载能写 systemd 单元就别省那几步——省下的十分钟会在之后某次内核升级的深夜里加倍还给你。