Ubuntu 共享文件夹：open-vm-tools 与 fstab 自动挂载

1. 先想清楚：这条数据通道到底解决什么问题

共享文件夹这四个字，放在 VMware 虚拟机加 Ubuntu 的组合里，实际含义是让宿主机的某个目录直接出现在 Ubuntu 的文件系统里，读写都走虚拟化层自己的通道，不额外架设网络服务。我在本地搭开发环境有些年头了，宿主 Windows 上放着代码仓库、素材库、还有几个体积不小的数据集，Ubuntu 虚拟机里跑编译、跑脚本、跑调试，两边数据来回倒是最日常的动作。最早我用过 U 盘拷、用过 scp、也试过在两边开 SMB 对着同一个网络位置读写，但这些办法要么慢，要么断，要么重启之后莫名其妙就失效了。共享文件夹的价值就在于，配置一次，长期可用，宿主那边的目录一改，虚拟机里立刻能看到。

1.1 三个最典型的真实使用场景

第一个场景是代码开发。很多人习惯在宿主机的编辑器里写代码，因为 Windows 上的 IDE 生态、字体渲染、快捷键都更顺手，但运行环境要放到 Linux 里才准确。这时候让代码目录变成共享文件夹，宿主那边保存文件，虚拟机里终端直接执行，省掉了每次同步的步骤。我自己的做法是把整个项目根目录共享进去，虚拟机里只用命令行和调试器，编辑体验留在宿主。

第二个场景是数据交换。比如你有一批几十 GB 的日志或者图片，需要在 Ubuntu 里做处理，直接从宿主机往共享目录里拖，虚拟机里就能读到。走共享文件夹比走网络传输稳得多，因为它本质上是文件系统层的映射，不依赖网卡状态，也不受防火墙影响。

第三个场景是配置与脚本的沉淀。宿主上维护一份 dotfiles、一份初始化脚本、一份常用工具的安装包目录，新开虚拟机时把这份共享目录挂上，环境搭建的时间能省一大半。这类"环境带在身上"的思路，对经常重装系统的人来说特别省事。

1.2 为什么优先选 open-vm-tools 而不是老式 VMware Tools

早些年大家装完虚拟机第一件事是挂载 VMware Tools 的 ISO，手动跑安装脚本。那套流程现在其实有点过时了。Ubuntu 从 14.04 之后，官方仓库里就有 open-vm-tools，它是 VMware 官方开源出来、由各发行版维护的版本，安装和升级都跟着系统的包管理器走，内核升级之后也不用重新编译模块。老式的 VMware Tools 在较新的内核上时不时报编译错误，尤其是内核 5.x 之后，各种头文件变动让那份老脚本很头疼。

我现在的固定做法是：Ubuntu 装好后先sudo apt update，然后装open-vm-tools和open-vm-tools-desktop这两个包。前者负责主机与虚拟机的交互、共享文件夹的内核模块（vmhgfs），后者多带一套桌面集成组件，图形界面下剪贴板共享、窗口自适应这些功能靠它。如果你只跑命令行，装第一个就够；如果装了 Ubuntu 桌面版，两个都装上，体验完整。

注意：装完这两个包之后，共享文件夹的挂载点通常是/mnt/hgfs，但前提是宿主机那边已经在虚拟机设置里开了共享，而且虚拟机要重启一次让内核模块加载。装完不重启直接去找/mnt/hgfs，大概率是空目录。

1.3 一条容易被忽略的前提：宿主机要先"允许"共享

很多人卡在这里。虚拟机的设置面板里，共享文件夹功能默认是关闭的。你必须在虚拟机关机或挂起状态下（运行状态下部分版本的设置项是灰的），进入虚拟机设置，找到"选项"标签下的"共享文件夹"，把它启用，然后添加具体的目录。这一步没做，虚拟机里面无论怎么折腾都看不到东西。这也是为什么网上大量"共享文件夹找不到"的帖子，答案往往就是宿主机这一步没开。我在下面第二章会把这一步的细节展开。

2. 动手之前：把两边的准备工作做扎实

配置这件事，出问题的地方往往不在命令本身，而在前置条件。我见过太多人直接跳到挂载命令，结果/mnt/hgfs里空空如也，然后开始怀疑命令写错了。其实真正的原因分布很集中：要么宿主机没开共享，要么虚拟机没装工具，要么挂载时机不对。把准备工作做对，后面就是顺水推舟。

2.1 Ubuntu 侧的环境检查

先确认虚拟机里已经装了 open-vm-tools。检查方法很简单，终端里跑：

dpkg -l | grep open-vm-tools

输出里应该能看到open-vm-tools和（如果你装了桌面版）open-vm-tools-desktop两行，前面是ii表示已安装。如果没有，就装上：

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

装完之后，确认 vmhgfs 这个内核模块是否加载：

lsmod | grep vmhgfs

正常情况下会看到vmhgfs这一项。如果没有，先重启虚拟机；重启后还是没有，就试试手动加载：

sudo modprobe vmhgfs

报模块找不到，通常意味着 open-vm-tools 没装全，或者内核头文件与当前内核版本对不上。Ubuntu 上很少出现后者，除非你手动换过内核。我建议装工具之前先uname -r看一下当前内核版本，心里有数。

2.2 宿主机侧的共享设置与命名规范

VMware Workstation 里，选中目标虚拟机，右键进入"设置"，切到"选项"标签页，找到"共享文件夹"。这里有两个层级：一是顶部的"总是启用"或"在下次关机或挂起前一直启用"，二是下面具体的文件夹列表。想让共享长期有效，必须选"总是启用"，这一条坑过不少人——选了临时启用，重启之后共享就没了，表现就是共享文件夹重启后失效。

添加目录时，宿主机路径选你想共享的那个文件夹，名称填一个简短的英文别名，比如share、projects、data。这个名称就是后面在 Ubuntu 里看到的目录名，所以别用中文、别带空格，省得后面挂载参数里还要转义。我一般统一叫share，一个就够用；如果确实要分多个，比如代码一个、数据一个，就用share和data这种清晰的名字。

注意：有些版本的 VMware Workstation 在虚拟机运行状态下，"共享文件夹"的设置项是灰的，改不了。这不是故障，先关机再改就行。另外 Windows 11 上如果共享的是网络位置或者需要凭据的目录，宿主机本身要先能访问，虚拟机才能通过这层映射读进去。

2.3 关于授权与来源的一点经验

网上搜这类教程，经常会撞见各种"密钥""破解"字眼。我自己的态度很明确：这类工具用官方渠道下载的正版授权，长期省心，升级不用折腾，也不会因为某个补丁把环境搞崩。虚拟机是吃饭的家伙，为了省那点钱去折腾来源不明的东西，风险和收益完全不成比例。下载走官网，安装包干净，装完该更新的更新，这是基本盘。

3. 核心实现：从手动挂载到开机自动生效

准备做完了，真正动命令的部分其实不长。但我建议分两步走：先手动挂载，确认路径和权限都对，再写进 fstab 做开机自启。一上来就改 fstab，语法错一个字符，开机进不去系统，那种体验很劝退。

3.1 先看看共享目录到底在哪

装好工具、宿主机开好共享、虚拟机重启之后，先别急着挂载，看看系统认到了什么：

ls /mnt/hgfs/

如果这里直接列出了你在宿主机设置里填的别名，比如share，那说明自动挂载已经生效了，你甚至什么都不用做。但实际情况是，很多发行版和 VMware 版本组合下，/mnt/hgfs是空的，需要手动挂。判断依据是：

vmware-hgfsclient

这个命令会列出所有宿主机共享给当前虚拟机的目录名。如果它输出了share，但/mnt/hgfs是空的，那就是挂载没做。这条命令也是排查问题的第一站：它空着，说明问题在宿主机或工具层；它有输出，说明问题只在挂载这一步。

3.2 手动挂载验证

创建挂载点，然后挂：

sudo mkdir -p /mnt/hgfs/share sudo mount -t fuse.vmhgfs-fuse .host:/share /mnt/hgfs/share -o allow_other

这里有几个细节值得说清楚。挂载类型用的是fuse.vmhgfs-fuse，这是新版 open-vm-tools 的 fuse 实现，比老的内核态 vmhgfs 更稳定，也不需要专门的挂载工具。挂载源写成.host:/share，.host是虚拟机内部对宿主机的固定指代，冒号后面就是共享别名。allow_other这个参数是给普通用户用的——不加它，只有 root 能访问挂载点，你平时用的普通账户进不去，表现就是"权限不够"。

如果你想挂载宿主机共享的全部目录，可以用：

sudo mount -t fuse.vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other

把整个.host:/挂到/mnt/hgfs下，所有共享别名会作为子目录出现。这个写法更省事，我个人更常用。

挂完验证：

ls /mnt/hgfs/share

能看到宿主那边的文件，就说明通道打通了。

3.3 写进 fstab：让重启后自动挂载

手动挂载重启就没了，要长期生效得写进/etc/fstab。编辑之前先备份：

sudo cp /etc/fstab /etc/fstab.bak

然后在文件末尾加一行：

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

uid和gid是文件在虚拟机里的属主和属组。填1000是因为 Ubuntu 默认的第一个普通用户 UID 就是 1000，你可以用id命令确认一下自己的：

id

输出里的uid=1000(yourname) gid=1000(yourname)就是依据。填对了，共享目录里的文件在虚拟机里就显示成你自己的，不用每次sudo才能读写。不填这一步，文件属主会是 root，普通用户只能读不能写，这是"共享文件夹权限不够"最常见的原因之一。

改完 fstab 别急着重启，先用这条命令验证语法：

sudo mount -a

没有报错就说明配置没问题。有报错，把错误信息贴出来看，别硬重启，否则可能进不去系统。真要进了不去的应急办法是在 GRUB 里进恢复模式，或者用安装盘挂载后改回 fstab，但这属于兜底，能提前验证就别走到那一步。

3.4 处理中文文件名乱码

共享目录里如果有中文文件名，偶尔会出现乱码或者显示成问号。这通常是编码参数的问题。可以在挂载选项里加上：

iocharset=utf8

对于 fuse 版的 vmhgfs，多数现代 Ubuntu 版本默认就是 UTF-8，不太会遇到。真遇到了，先确认宿主机文件名本身的编码，再考虑在挂载参数里显式指定。我的经验是这种问题在 Windows 宿主 + 较新 Ubuntu 的组合里已经很少见，主要出现在老系统上。

4. 权限、失效与各种疑难杂症排查实录

真正耗时间的从来不是配置，而是配好之后突然不灵了。共享文件夹这套东西的故障表现高度集中，排查路径也很固定，理清楚之后基本能自己对号入座。

4.1 权限不够：uid、gid 和 dmask

"Ubuntu 共享文件夹权限不够"这个搜索词背后，通常是三类原因。第一类是挂载时没加allow_other，导致普通用户根本进不去挂载点，表现是Permission denied。第二类是没指定uid/gid，文件属主是 root，普通用户只能读。第三类是宿主机那边的文件本身设了只读属性，虚拟化层会把这个属性透传进来，这种情况在虚拟机里改权限是没用的，得回宿主机改。

还有一种控制权限的方式是文件掩码。如果你希望共享目录里的所有文件在虚拟机里都是某个固定权限，可以在挂载参数里加dmask和fmask。比如想让目录权限为 755、文件权限为 644，就写：

dmask=022,fmask=133

这里的数字是"要被屏蔽掉的权限位"，和 umask 一个逻辑。用得不多，但排查"为什么文件权限和我预期不一样"的时候，知道有这么个东西就行。

4.2 重启后失效的三种典型情况

第一种是宿主机设置里选的是"临时启用"。这个我前面提过，选"总是启用"就解决。

第二种是 fstab 里写的挂载源或挂载点不对。比如挂载点目录不存在，或者别名写错了。重启后mount -a会失败，共享就没挂上。解决办法是核对vmware-hgfsclient的输出，确认别名拼写一致。

第三种是系统启动顺序问题。有些情况下 fstab 在 vmhgfs 模块加载之前就执行了，导致挂载失败。可以给 fstab 那一行加上nofail和_netdev选项：

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

nofail保证挂载失败也不阻塞启动，_netdev告诉系统等依赖就绪后再挂。这两个选项组合起来，能解决大部分启动时机导致的自启失败。

4.3 常见问题速查表

这张表基本覆盖了我这些年遇到过的九成情况，剩下的一成多半和具体的系统版本组合有关，得看日志。排查时养成一个习惯：先跑vmware-hgfsclient，这一步能立刻把问题定位到宿主机侧还是虚拟机侧，比盲目改配置高效得多。

4.4 几个踩过的坑

第一个坑是把宿主机的用户主目录整个共享进去。听起来很方便，实际上虚拟机里做任何全盘搜索或者索引都会去遍历这个挂载点，速度奇慢，桌面环境偶尔直接卡死。共享范围要精准，只共享真正需要交换的那几个目录。

第二个坑是在 fstab 里用了中文挂载点路径。虽然理论上能跑，但一旦出问题，日志里的报错信息读起来非常痛苦，而且有些工具处理不了非 ASCII 路径。挂载点用纯英文，这是硬规矩。

第三个坑是版本兼容。open-vm-tools 的版本和 VMware Workstation 的版本之间偶尔会有不匹配，表现是挂载成功但读写大文件时中断。遇到这种情况，先把两边都升到较新的稳定版本，多数能解决。

5. 进阶对比：共享文件夹放在整个方案里的位置

共享文件夹是 VMware 提供的一条捷径，但它不是唯一的路。搞清楚它和其他几种数据交换方式的边界，能帮你判断什么时候该用它，什么时候该换别的。

5.1 和 SMB、NFS、scp 的横向比较

SMB 和 NFS 是走网络协议的文件共享，配置起来要架服务、要处理认证、要开端口，但胜在通用——多台机器同时访问、跨物理机、跨网段都能用。共享文件夹走的是虚拟化层自己的通道，配置轻，不依赖网络，但只能在单台虚拟机和它的宿主之间用。

scp 和 rsync 属于一次性传输，适合搬运不需要实时同步的文件。共享文件夹的优势是实时——宿主那边改一个字，虚拟机里立刻是新的，不需要手动同步。

拖拽复制（装了 open-vm-tools-desktop 之后支持的）适合偶尔扔一两个文件，不适合大量文件或者需要持续访问的目录。

我个人的排序是：日常开发的代码目录用共享文件夹，因为它要实时；大批量一次性数据用 rsync，因为它可以断点续传；需要多机访问的场景才上 NFS 或者 SMB。

5.2 性能上的实感

共享文件夹的性能不差，但也别期待它和本地磁盘一样快。做小文件密集读写（比如编译一个几千文件的项目）的时候，能感觉到延迟比放在虚拟机本地磁盘上高。我的做法是把源码放在共享目录里编辑，但把编译输出目录配置到虚拟机本地磁盘上，两边各取所长。

如果确实需要虚拟机本地的高性能，又想在宿主上编辑，可以用 rsync 定时同步的方式做折中：宿主上改，后台定时把变更推到虚拟机本地目录。这套方案配置起来比共享文件夹麻烦，但对于大规模项目编译，收益明显。

5.3 后续还能往哪扩展

这套东西搭好之后，能扩展的方向不少。比如把共享目录里的初始化脚本和 dotfiles 做成一套自己的环境模板，新装虚拟机时挂上就能一键恢复工作环境。再比如把共享目录接到容器里，让 Ubuntu 里跑的 Docker 容器直接挂载宿主共享的目录，宿主编辑、容器运行，链路很短。

还有一点值得提醒：如果虚拟机里装了图形桌面，共享目录在文件管理器里可能默认不显示，需要手动输入路径或者加书签。这不是故障，只是桌面环境不会自动把/mnt/hgfs加进侧边栏，加个书签就顺手了。

6. 写在最后的一点个人体会

这套配置我从最早的 VMware Tools ISO 时代一路换到现在的 open-vm-tools + fstab 方案，踩的坑基本都在前面那张表里了。真要说最值钱的经验，其实就两条：一是任何配置改动之前先备份 fstab，先用mount -a验证再重启；二是遇到"找不到共享目录"的时候，永远从vmware-hgfsclient开始查，这一条命令能省掉大量来回试错的时间。

另外提醒一句，Ubuntu 安装完第一件事我一般不是配共享，而是先确认网络和软件源是通的，因为 open-vm-tools 得从仓库装。源不通的情况下去折腾共享文件夹，方向就错了。工具装好、宿主机共享开好、fstab 写对，这套东西稳定运行好几年都不用再碰，是那种"配一次受益很久"的基础设施。