408统考操作系统复习笔记：知识体系与思维导图全攻略
2026/10/4 6:37:00
在日常交流群里，经常有同事拿着截图来问我：VMware里明明已经开启了共享文件夹，Windows 主机上的目录也选好了，怎么到 Ubuntu 虚拟机里就是看不到？甚至有人为此重装了一遍 VMware Tools，最后还是一头雾水。说实话，这个功能本身并不复杂，但它涉及虚拟机软件、客户机系统、文件系统驱动三个层面的配合，任何一个环节断了，表现出来都是“共享文件夹不见了”。
这篇文章我就把 VMware Workstation 里 Ubuntu 与 Windows 共享文件夹这件事从头到尾拆开讲一遍。包括HGFS的工作逻辑、VMware Tools 的安装方式、共享目录的配置方法、挂载命令和开机自动挂载写法，以及我这些年踩过的权限坑和失效坑。无论你用的是桌面版的 Ubuntu 还是纯命令行服务器版，按着下面的步骤走，基本都能搞定。
1. 为什么“设置好了”却看不到：先搞懂 HGFS 的工作逻辑
很多人的第一步就理解错了，以为在 VMware 图形界面里把“共享文件夹”开关打开，宿主机目录就会像U盘一样自动出现在 Ubuntu 里。实际上，VMware 的共享文件夹功能走的是 HGFS（Host-Guest File System），这套文件系统的驱动并不是 Windows 侧提供的，而是装在虚拟机里的 VMware Tools 提供的。
1.1 “共享文件夹”和“拖拽文件”是两码事
这里先区分两个容易混淆的功能。VMware 里有一个“启用拖拽”的选项，这个功能允许你把文件从 Windows 窗口直接拖进 Ubuntu 桌面，但它走的是 VMware 的剪贴板增强和拖放通道，适合临时传几个文件，不适合作为持续存在的目录使用。而“共享文件夹”则在虚拟机里映射成一个真正的文件系统路径，比如 /mnt/hgfs/Share，你可以在里面直接读写、创建项目、跑脚本，两边看到的永远是同一份文件。
理解这个区别很重要。拖拽依赖的是图形会话，如果 Ubuntu 跑的是无桌面服务器版，拖拽基本是废的；而共享文件夹只要 HGFS 驱动正常，SSH 连进去也一样能访问。
1.2 共享文件夹的三条技术路径对比
在 VMware 虚拟机里实现 Windows 与 Ubuntu 文件互通，其实不止 HGFS 一种方式。我把几种常见方案放在一起比较过，各有各的适用场景。
| 方案 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| HGFS / vmhgfs-fuse | VMware Tools 提供的客户机文件系统驱动 | 配置简单，无需网络，隔离性好 | 性能一般，对 inotify 支持不完整，跨平台权限语义粗糙 |
| Samba / SMB | 通过网络共享协议访问 Windows 目录 | 兼容性好，多虚拟机可同时访问，稳定 | 需要网络连通，路径写起来稍长，性能受网络影响 |
| NFS | Linux 原生网络文件系统 | Linux 之间效率高，适合服务器场景 | Windows 挂载 NFS 相对麻烦，配置门槛偏高 |
单从“快速让 Windows 和 Ubuntu 互相传文件”这个需求来看，HGFS 是最省事的方案，也是本文的重点。如果你后续要把共享目录做成长期稳定的数据交换通道，或者有多台虚拟机都要访问同一份数据，那再考虑升级到 Samba 或 NFS，第五节我会展开讲。
1.3 为什么 HGFS 必须依赖 VMware Tools
这里用一个生活类比：虚拟机像你租的房子，Windows 宿主机是房东，共享文件夹是房东在墙上给你留的一个柜子，而 VMware Tools 就是打开这个柜子的钥匙。没有钥匙，你就算知道墙里有柜子，也死活打不开门。
在 HGFS 的实现里，VMware Tools 会向 Ubuntu 内核注册文件系统驱动（早期是 vmhgfs 内核模块，新版 Open-VM-Tools 里则通过 FUSE 用户态方式提供 vmhgfs-fuse）。只有驱动注册成功，你在 Ubuntu 里执行挂载命令时才能看到宿主机共享目录。所以，下一步必须先解决 VMware Tools 的安装问题。
2. VMware Tools 没装对，共享文件夹永远出不来
VMware Tools 有两种安装来源，很多教程还在教你去虚拟机菜单栏点“Install VMware Tools”，然后挂载那个虚拟光驱解压 tar 包来装。这个方法在旧版 Ubuntu 上还行，新版本内核一升级，那个官方 tar 包里的老驱动经常编不过去，或者装完一重启就失效。我现在几乎没有再用过那种手动方式。
2.1 推荐直接用 Open-VM-Tools
Ubuntu 官方软件源里维护了一套开源版 VMware Tools，叫 Open-VM-Tools，功能和 VMware 官方闭源版基本一致，而且紧跟 Ubuntu 内核更新，不会出现“升级内核后共享目录消失”这种周期性故障。
在 Ubuntu 终端里执行以下命令即可安装：
sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktop如果你是带桌面的 Ubuntu 版本，建议把 open-vm-tools-desktop 也一起装上，它会启用分辨率自适应、剪贴板共享、拖拽文件等图形会话相关功能。如果只是命令行服务器版，装 open-vm-tools 就够了，少一个包少一份依赖。
装完以后把虚拟机重启一次，或者至少把当前会话注销重新登录一次，确保服务正常启动。我个人习惯直接重启，因为后面挂载共享目录时，FUSE 模块和设备节点有时候在系统刚装完驱动时不一定会立即就绪。
2.2 确认 VMware Tools 是否生效
重启之后，先在 Ubuntu 里执行这条命令：
vmware-hgfsclient这条命令会列出虚拟机配置里所有的共享文件夹名称。注意，如果这里没有任何输出，说明 VMware Tools 没有正常工作，或者共享文件夹根本没配置。这一步就像体检报告单上的第一项指标，后面的操作都要建立在这一条有输出的基础上。
再顺手检查一下服务状态：
systemctl status open-vm-tools如果服务显示 active (running)，说明驱动框架已经在跑。这时如果 vmware-hgfsclient 有输出，就可以进入下一步配置共享文件夹了。
2.3 一个容易被忽略的版本问题
如果你是在旧版 VMware Workstation（比如 14、15）上装了新版 Ubuntu，Open-VM-Tools 的某些特性可能不完全兼容，表现症状是鼠标卡顿、剪贴板失效、共享目录时好时坏。这种组合下，可以先把 VMware Workstation 升级到 15.5 以上，或者至少确认虚拟机硬件版本设置不要太高。
另外提一句，VMware Workstation 17 Pro 从 2024 年 5 月之后对个人用户免费了，如果还在用旧版本，直接升级到 17 会省掉很多奇奇怪怪的兼容性问题。官方下载页面直接下载即可，许可证界面选择个人用途就能免费使用。
3. 一步步配置共享文件夹并挂载到 Ubuntu
准备工作做完，下面进入真正的操作环节。整个流程分三段：先在 VMware 侧添加共享目录，然后在 Ubuntu 侧挂载，最后配置开机自动挂载。
3.1 VMware 侧添加共享文件夹
打开虚拟机的设置窗口，按以下步骤操作：
- 在 VMware Workstation 中选中目标虚拟机，点击“编辑虚拟机设置”。
- 切换到“选项”选项卡。
- 左侧找到“共享文件夹”。
- 右侧选择“总是启用”。
- 点击“添加”，按向导选择 Windows 宿主机上的一个目录，比如 D:\share。
- 设置共享名称，建议纯英文，不要带空格。如果你起名“myshare”，后面挂载时就用这个名称指代该目录。
- 勾选“启用此共享”完成添加。
这里有一个细节：VMware 支持同时添加多个共享文件夹，你可以给每个目录单独命名。如果希望在 Windows 侧改动文件但 Ubuntu 侧只能读不能改，可以在添加目录时勾选“只读”。日常传文件不建议只读，容易踩“刚写一半发现没权限”的坑。
4. Ubuntu 侧挂载共享目录
回到 Ubuntu 终端，先创建挂载点。默认路径一般习惯用 /mnt/hgfs，但这个目录在较新系统中不一定自动存在，手动创建一下：
sudo mkdir -p /mnt/hgfs然后运行挂载命令：
sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other -o uid=1000,gid=1000这条命令把宿主机上所有共享文件夹的根挂载到 /mnt/hgfs。如果你只想挂载某一个共享目录，可以写成：
sudo vmhgfs-fuse .host:/myshare /mnt/hgfs/myshare -o allow_other -o uid=1000,gid=1000挂载完之后，执行：
ls -l /mnt/hgfs正常情况下你就能看到刚才在 VMware 里添加的共享文件夹名称，进去就是 Windows 那边对应的目录内容。
这里说明一下参数含义，别光复制不知道什么意思：
- .host:/ 表示宿主机共享根目录，等价于“所有共享的集合”。
- allow_other 允许除 root 之外的用户访问挂载点，不加这个参数，普通用户经常进不了目录。
- uid=1000,gid=1000 把共享目录中的文件和目录所有者映射到 Ubuntu 第一个普通用户（通常是安装系统时创建的用户）。如果不指定 uid/gid，挂载后文件所有者会显示成 root，普通用户写不进去。
关于这个 uid 值，你可以用 id -u 命令查看当前用户的 uid。绝大多数 Ubuntu 桌面版第一个用户是 1000，但如果你的系统里用户编号不同，直接把两个参数改成实际值即可。
4.1 设置开机自动挂载，避免每次重启都要手动执行
很多人配置完共享文件夹，重启虚拟机后又发现 /mnt/hgfs 空了，一脸懵。原因很简单，vmhgfs-fuse 的挂载不会自动执行，你需要把它写进 /etc/fstab，让系统启动时自动挂载。
编辑 fstab：
sudo nano /etc/fstab在文件末尾追加这一行：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other,uid=1000,gid=1000 0 0保存后，执行下面命令验证配置是否正确，不用重启就能应用：
sudo mount -a如果这条命令没有报错，再执行 ls /mnt/hgfs 确认目录内容可见，说明 fstab 配置成功。今后每次开虚拟机，目录都会自动挂载好。
这里有一个我踩过几次的坑：fstab 写错一行，系统启动时可能会卡在等待挂载超时，甚至直接进入紧急模式。所以写完 fstab 一定要先执行 mount -a 测试，确认无误再重启，别把“配置自动挂载”变成“把系统搞到起不来”。
4.2 关于“重启后共享失效”的高频场景
有些人会用 CIFS 挂载 Windows 共享（比如 //WindowsIP/share），这个在重启后也经常失效，原因通常是网络没有就绪时 fstab 里的挂载任务已经开始执行。解决办法是在 fstab 的挂载参数里加上 _netdev，告诉系统等网络可用后再挂载。HGFS 走的是虚拟设备通道，不依赖网络，所以一般不会遇到这个问题，但如果你同时配了 CIFS 或 NFS，记住 _netdev 这个参数能省不少心。
5. 常见问题排查实录：挂载失败、目录空白、权限拒绝对照表
这里把我这些年遇到过的、以及群里高频出现的问题整理成一个速查表，每一条都是实际验证过的排查思路。
| 现象 | 可能原因 | 排查与解决办法 |
|---|---|---|
| vmware-hgfsclient 无输出 | VMware Tools 未安装或服务未启动 | 重新安装 open-vm-tools；检查 systemctl status open-vm-tools；确认共享文件夹是“总是启用” |
| /mnt/hgfs 目录存在但内容为空 | 挂载未执行或未成功 | 手动执行 vmhgfs-fuse；查看 dmesg 输出是否有 fuse 错误 |
| 挂载时报 fuse: device not found | 系统未加载 fuse 模块 | 执行 modprobe fuse；再重新挂载 |
| 文件能看到但无法写入 | 挂载参数缺少 uid/gid 或 allow_other | 重新挂载，补上 -o uid=1000,gid=1000 -o allow_other |
| 普通用户打开 /mnt/hgfs 报 Permission denied | 挂载时未加 allow_other | 重新挂载并加 allow_other 参数 |
| 重启后共享目录没有被挂载 | fstab 写错或未生效 | 检查 fstab 行；执行 mount -a；确认没有多余空格或全角符号 |
| 大文件拷贝到一半失败 | HGFS 对超大文件支持不完善 | 改用 Samba 或直接拖拽；或分卷传输 |
| 在共享目录里跑代码/文件监听工具无效 | HGFS 对 inotify 事件支持不完整 | 开发目录放在虚拟机本地磁盘，共享目录只做文件交换 |
5.1 重点展开：fuse 模块问题怎么处理
在较新的 Ubuntu 版本上，fuse 默认是启用的，但如果你用的是精简安装、容器化定制系统，或者云镜像裁剪版本，偶尔会遇到 /dev/fuse 不存在的情况。这时先手动加载模块：
sudo modprobe fuse然后确认设备节点：
ls -l /dev/fuse如果 ls 之后发现连 /dev/fuse 都没有，执行：
sudo mknod -m 666 /dev/fuse c 10 229这个操作很少用到，但在定制内核环境下我确实遇到过。如果 modprobe 报错 module not found，那多半是内核没有包含 fuse 支持，这种情况建议换回 Ubuntu 官方内核，别在裁剪内核上浪费时间。
5.2 关于文件权限和换行符的“隐藏坑”
共享文件夹挂在 /mnt/hgfs 下之后，你会发现文件权限经常显示成 777 或者带有 execute 标志，因为 NTFS 文件系统本身没有 POSIX 权限概念，vmhgfs-fuse 会为所有文件分配一个统一权限。所以你可能会看到 Windows 那边存的一个 txt 文本，在 Ubuntu 里也是可执行的。这不会影响读写，但如果你习惯性地给脚本文件设置了执行权限，Windows 那边并不会感知到，换了一台机器之后脚本权限仍然是 Windows 默认状态。
还有换行符问题：在 Windows 下用记事本写的脚本文件，到 Ubuntu 里可能会因为 CRLF 换行符报错“/usr/bin/env: bad interpreter”，这个和共享文件夹本身无关，但因为它太常见了，我每次遇到有人说“共享文件夹里脚本跑不了”时，第一反应就是让他检查换行符。建议在 Windows 写代码时直接把编辑器默认换行符改成 LF，或者到 Ubuntu 里用 dos2unix 统一转一次。
5.3 开发场景下的一个实用建议
如果你打算把共享文件夹当代码目录，直接在 /mnt/hgfs/xxx 下面跑 npm、webpack、gulp，或者用 IDE 的文件监听功能，我劝你慎重。HGFS 对 inotify 事件的支持不完整，很多文件监听工具在共享目录里会失灵，表现为改文件后不触发编译、保存后页面不刷新。我的处理方式很干脆：开发目录始终放在虚拟机本地磁盘，共享文件夹只用来交换安装包、文档、数据库备份等静态文件。代码同步通过 git 仓库完成，这样既不影响 HGFS 的性能边界，也不会因为 inotify 问题耽误开发效率。
6. 更进一步：Samba、NFS 与远程开发，哪种模式更顺手
HGFS 解决的是“宿主机和这台 Ubuntu 之间快速共享”的问题。但如果你的 Ubuntu 还要和局域网里的其他电脑共享文件，或者要多台虚拟机访问同一个 Windows 目录，HGFS 就不太够用了，需要换方案。
6.1 Samba：和 Windows 共享最通用的方式
在 Ubuntu 上装 Samba 服务，Windows 打开文件管理器直接输 \ubuntuIP\share 就能访问，这是跨平台共享的标准做法。
安装并开启服务：
sudo apt install -y samba sudo systemctl start smbd sudo systemctl enable smbd然后编辑 /etc/samba/smb.conf，在文件末尾追加一个共享定义：
[share] path = /home/yourname/share browseable = yes read only = no valid users = yourname重启服务并设置 Samba 访问密码：
sudo systemctl restart smbd sudo smbpasswd -a yournameWindows 侧通过 \IP地址\share 访问。如果提示找不到网络路径，先确认 Ubuntu 防火墙是否放行 445 端口。这种方式因为是走标准 SMB 协议，稳定性比 HGFS 好，也适合长期挂载使用。网上很多“CIFS挂载共享文件夹重启失效”的求助，基本都是因为 SMB 客户端在 fstab 里没加 _netdev，我前面已经提过。
6.2 NFS：Linux 机器之间的高效通道
如果共享的两端都是 Linux，NFS 是更高效的选择。Ubuntu 上装 NFS 服务端：
sudo apt install -y nfs-kernel-server编辑 /etc/exports，添加要共享的目录：
/home/yourname/share 192.168.10.0/24(rw,sync,no_subtree_check)然后应用配置：
sudo exportfs -ra sudo systemctl restart nfs-kernel-server客户端挂载：
sudo mount -t nfs ubuntu-server-ip:/home/yourname/share /mnt/nfsNFS 在 Linux 生态里性能损耗低，权限模型也和 POSIX 一致，适合服务器之间的数据交换。缺点是 Windows 连接 NFS 需要额外安装“NFS 客户端”功能，操作路径较长，如果共享双方有一方是 Windows，还是优先 Samba 吧。
6.3 远程 SSH 模式：绕开共享目录的另一种思路
有时候你需要的可能不是挂在本地路径的共享文件夹，而是能随时操作虚拟机里的文件。这种场景下，我更推荐直接用 VSCode 的 Remote-SSH 插件，通过 SSH 连进 Ubuntu，在 VSCode 里打开远程目录写代码。远程终端、文件树、调试器都能直接用，完全没有 HGFS 的 inotify 限制，也不用操心挂载参数。
具体操作不复杂：宿主机装好 VSCode，装 Remote-SSH 插件，虚拟机里确保 openssh-server 已安装并启动，然后在 VSCode 里配置 SSH Host 就能连接。这种方式对个人开发场景来说，比折腾共享文件夹更干净。
7. 一点个人体会
在我自己的日常环境里，VMware 共享文件夹用得最多的场景是给虚拟机导安装包、传数据库备份、拿宿主机上的截图，这些场景稳定可靠就够用。倒是早期我试图把整个 Python 项目直接放在共享目录里开发，结果文件监听失效、权限总出问题，来回折腾了好几天，后来换成 git 同步代码、本地磁盘跑开发环境，世界才清净下来。
很多人喜欢问“到底用哪种方式最好”，我的回答是：先确认你的需求是文件交换还是持续开发。如果只是交换文件，HGFS 的配置成本最低，照着前面第三节的步骤十分钟就能跑通；如果是长期不断地读写同一份数据，Samba 的稳定性更值得信任；如果是开发写代码，优先考虑远程 SSH 模式。根据自己的场景选一种方式，别一上来就全都配一遍。
最后再分享一个小技巧：配置完共享文件夹以后，在 Ubuntu 里先把常用目录做一个软链接，比如 ln -s /mnt/hgfs/myshare ~/share，以后直接用 ~/share 访问，省得每次都要敲一长串路径。Windows 侧也建议在桌面放一个指向 D:\share 的快捷方式，两边各一步就能打开共享目录，日常用起来方便很多。