我每天都在用的 10 个 Claude Code 命令，你可能漏掉了几个：TaoToken 统一 Key 接入 settings.json 配置骨架
2026/9/29 21:41:19
遇到Failed to mount /mnt/hgfs和Dependency failed for Local File Systems这个组合报错，基本可以确定是VMware共享文件夹机制和Ubuntu 22.04的启动流程打架了。这不是系统坏了，也犯不上重装虚拟机。这篇文章我会从问题根源讲起，给出一条从恢复模式进root、注释fstab残留项、重装open-vm-tools到恢复共享文件夹挂载的完整处理路径。刚被黑屏卡住的新手可以直接对照操作，被这问题反复折腾过、每次升级内核后就复发的读者，也能在这里找到原因。
1. 先搞明白“黑屏+挂载失败”是怎么来的
1.1 从报错信息反推启动链路
Ubuntu 22.04使用systemd管理开机流程，整个启动过程是以“目标单元”为节点串起来的。local-fs.target是其中一个关键节点，它负责确认所有本地文件系统挂载完毕、可以正常读写。你可以把它理解成一个宴会开席前的“服务员集合点”——只有所有服务员都到位了，宴会才敢正式开始。systemd也一样，只要某个挂载项失败，local-fs.target就会进入failed状态，接下来依赖它的服务全部遭殃。
你在黑屏上看到的那句Failed to mount /mnt/hgfs，就是在告诉systemd：有一个挂载任务失败了。后面那句Dependency failed for Local File Systems，就是local-fs.target这个节点本身宣布失败。此时图形界面GDM还没有拿到启动权限，Ubuntu默认的splash画面又只显示logo，于是你看到的就是一块黑屏或者卡在logo界面不动。整个过程不是死机，而是systemd在等待一个永远完不成的挂载任务，最终因依赖关系连锁失败。
这里有个关键认知：这个错误根本不是硬盘故障，也不是Ubuntu系统本身损坏。它跟VMware的共享文件夹机制强相关。只要把挂载链路修好，系统就能正常进桌面。我见过太多人一看到Dependency failed就重装系统，其实完全没到那一步。
1.2 共享文件夹在VMware里的真实实现
在VMware Workstation中配置了共享文件夹后，宿主机目录会通过VMware Tools组件映射到虚拟机内的/mnt/hgfs。这个挂载动作有两种实现方式：一种是传统的内核模块vmhgfs.ko，另一种是更现代的用户态方案vmhgfs-fuse。无论哪种方式，都需要一个前提——open-vm-tools或者VMware官方Tools正确安装并能运行。
实际工作中，挂载失败通常逃不出这三种情况：
- fstab里残留了挂载项，但对应的服务或模块根本没启动；
- open-vm-tools未安装、损坏或者版本太旧，VMware共享开关虽然开着，Linux侧却没人干活；
- 升级内核后，vmhgfs内核模块没跟上新内核版本，出现模块缺失或CRC校验失败。
打个比方：宿主机共享目录是仓库里的货，/mnt/hgfs是收货口，vmhgfs模块是叉车。现在调度表（fstab）上写着“三号叉车给一区送货”，但三号叉车今天根本不在岗（内核模块没加载），调度台只能一直干等。系统启动流程就是这么卡住的。
2. 修复流程：先让系统能进桌面，再谈共享文件夹
2.1 从GRUB恢复模式进入root shell
修复的第一步，是拿到一个有写入权限的root shell。重启虚拟机，在开机画面出现时快速按Shift，或者连续点Esc。VMware里GRUB菜单显示窗口很短，动作慢了就直接进系统了，所以我通常的做法是开机后立刻把手放在按键上连按，宁可多按几下也别错过。
进入GRUB菜单后，选择“Advanced options for Ubuntu”，然后找到带“recovery mode”的内核条目。回车后你会看到一个蓝色界面的Recovery Menu，里面有一系列选项，选中“root”并回车，就进入了root shell。这里有个细节：此时根文件系统是只读挂载的，必须先执行mount -o rw,remount /让它可写，否则后面所有修改fstab和apt安装操作都会报“read-only file system”。
如果你在Recovery Menu里找不到root选项，也可以按Ctrl+Alt+F3切换到纯文本终端，用普通账号登录后执行sudo。核心目标只有一个：拿到一个能写文件的shell。只要能做到，这台虚拟机就有救。
2.2 第一步永远是注释fstab里的残留挂载项
拿到root shell后，先看/etc/fstab。一般情况下你会看到类似这样的行：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults 0 0或者早期一些的写法：
vmhgfs-fuse /mnt/hgfs fuse defaults 0 0这行配置不一定是使用者亲手写的。有些版本的open-vm-tools在启用共享文件夹时会自动向fstab追加挂载项，系统升级后环境变了，这行就成了地雷。我处理这类问题的顺序是：不管三七二十一，先把含hgfs的行注释掉，让启动链路先恢复健康，再谈后续恢复功能。
操作上，直接用nano /etc/fstab最直观，在对应行前面加#，保存退出。如果用sed，注意点号转义，命令大致是：
sed -i 's|^\.host:/|#.host:/|' /etc/fstab为什么坚持“先注释”而不是“先重装”？因为重装open-vm-tools后，旧内核下模块加载未必能立即生效，系统启动到挂载步骤照样会失败或长时间等待。先把失败源从启动链路上摘掉，让系统能正常开机，是最快的止损手段。注释不等于放弃共享文件夹，只要你愿意，修好服务后可以随时恢复这一行。
2.3 重装open-vm-tools并验证内核模块
注释完fstab后，在root shell中执行：
apt update apt install --reinstall open-vm-tools open-vm-tools-desktop这里多说一句为什么强调用open-vm-tools而不是VMware官方安装包。Ubuntu 22.04的仓库里维护的open-vm-tools会跟随系统更新，和内核版本保持同步。而VMware官方tarball安装的vmware-tools，在Ubuntu每次发新内核后很容易出现模块不匹配的问题，这是很多“升级后黑屏”案例的根源。
装完后验证三件事。第一，内核模块能否正常加载：
modprobe vmhgfs没有输出就说明模块加载正常。第二，服务是否启动：
systemctl status open-vm-tools如果服务没跑起来，用systemctl enable --now open-vm-tools启动并设置开机自启。第三，用vmware-hgfsclient列出宿主机共享目录：
vmware-hgfsclient这条命令会返回你在VMware Workstation里配置的所有共享文件夹名称。如果返回为空，回到VMware菜单里检查Shared Folders是否处于Always enabled状态，这个开关没打开，Linux侧怎么折腾都白搭。
2.4 重启后的正确共享文件夹挂载配置
修好Tools后别急着把fstab原样写回去。先手动验证挂载是否正常，再考虑自动化。手动挂载命令：
sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other,uid=1000,gid=1000如果不报错，ls /mnt/hgfs能看到宿主目录，说明整条链路已经通了。此时再决定是否写回fstab。如果需要开机自动挂载，推荐写法是：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,defaults,uid=1000,gid=1000 0 0我见过不少人纠结用vmhgfs内核模块方式还是vmhgfs-fuse方式，这里直接给结论：Ubuntu 22.04推荐fuse方式。因为传统的内核模块方式在新内核升级后经常出问题，而fuse方案是用户态进程，不依赖内核模块编译，稳定性好很多。两者对比可以看下表。
| 挂载方式 | 依赖组件 | 常见问题 | 稳定性 |
|---|---|---|---|
| 传统vmhgfs | 内核模块vmhgfs.ko | 内核升级后模块未重编，加载失败 | 一般 |
| vmhgfs-fuse | open-vm-tools用户态程序 | 需确保fusermount权限和open-vm-tools已安装 | 更稳定 |
3. 实际操作记录：从黑屏到恢复桌面的完整过程
3.1 问题现场还原
下面这场操作我实打实走过一遍。虚拟机环境是VMware Workstation 17 Pro，客户机Ubuntu 22.04.2，之前一切正常，Windows宿主机上配了一个共享目录，映射到虚拟机内的 /mnt/hgfs。某天执行apt upgrade后重启，虚拟机开机后迟迟不出桌面，屏幕最终停在一行Failed to mount /mnt/hgfs，紧接着就是那句Dependency failed for Local File Systems。
第一反应不是重装，而是先ping一下这台虚拟机的IP——居然通了。这里给你一个判断依据：如果虚拟机IP能ping通，说明内核、网络服务都起来了，系统不是真死，只是桌面没起来。这种情况下按本文流程修就能解决。如果ping不通，那是内核阶段就崩了，问题性质完全不同，需要走Live CD修复流程，不在本文讨论范围。
3.2 一步步操作实录
我按当时实际敲命令的顺序记录下来，你可以完全照着做。
第一步，重启虚拟机。开机画面出现时不停按Shift，进入GRUB菜单，选Advanced options for Ubuntu，再选带recovery mode的内核，在Recovery Menu里选root。进入root shell后立刻执行：
mount -o rw,remount /第二步，查看fstab内容：
cat /etc/fstab屏幕上出现了一行典型的残留配置：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults 0 0我用nano打开fstab，在这一行最前面加了一个#，保存退出。稳妥起见又执行一遍cat /etc/fstab复查，确认注释生效。
第三步，重装工具包：
apt update apt install --reinstall open-vm-tools open-vm-tools-desktop等待安装结束后，验证模块加载：
modprobe vmhgfs命令执行后没有任何输出，说明模块正常。接着又确认了服务状态和服务启动：
systemctl enable --now open-vm-tools systemctl status open-vm-tools服务显示active (running)，这步通过。
第四步，重启虚拟机：
reboot这次启动很顺利，没再看到那行碍眼的错误，桌面正常出现。登录后我用journalctl -b -p err检查本次启动的错误日志，确认没有新的挂载失败记录。
第五步，恢复共享目录。回到VMware菜单，确认Shared Folders开关仍处于Always enabled。然后在虚拟机里执行：
sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other,uid=1000,gid=1000执行后/mnt/hgfs里出现了宿主机的共享文件夹，一切恢复原状。
3.3 如果fstab里根本没有hgfs行，问题在哪
如果你按上面的方法打开fstab，发现里面压根没有hgfs相关行，那问题就另当别论了。这种情况我遇到过几次：fstab是干净的，但系统里安装了旧版vmware-tools的init脚本，或者某个systemd服务里残留了挂载指令，一样会报这个错。
这时候别只盯着屏幕上最后一行的hgfs报错，要一次看全部失败项：
journalctl -b | grep -i fail我见过最典型的案例是fstab里某个UUID写错了，比如分区UUID和实际对不上，local-fs.target一样失败，而hgfs报错只是恰好显示在屏幕末尾，给人造成是hgfs导致一切的错觉。排查时可以用这两个命令定位真实问题：
systemd-analyze blame systemd-analyze critical-chain local-fs.targetblame按耗时排序显示启动阶段每个单元的耗时，critical-chain显示目标单元的依赖链。依赖链上一目了然，哪个环节failed就是罪魁祸首，主意直接打到那一个环节上。
4. 常见问题与排查技巧实录：Failed to mount /mnt/hgfs速查表
4.1 问题速查表
把几个月来处理过的相关咨询和踩坑经验整理成一张表，方便你直接对号入座。
| 现象 | 原因 | 处理办法 |
|---|---|---|
| 一直黑屏但虚拟机IP能ping通 | 挂载失败导致systemd等待，桌面没起来 | 按Ctrl+Alt+F3切TTY，注释fstab，重装open-vm-tools |
| 报错后进入emergency mode | fstab里有无效挂载项 | recovery模式进入root，修复fstab或恢复快照 |
| modprobe vmhgfs报module not found | 内核模块未安装或与当前内核不匹配 | 安装linux-headers，重装open-vm-tools或open-vm-tools-dkms |
| /mnt/hgfs目录不存在 | open-vm-tools服务未启动或VMware共享开关未开启 | systemctl enable --now open-vm-tools，检查VMware Shared Folders配置 |
| 桌面黑屏但Ctrl+Alt+F3能切到终端 | GDM或桌面会话服务失败 | 重装gdm3或ubuntu-desktop，必要时切换Xorg会话 |
| 复制粘贴、窗口自适应失效 | 缺open-vm-tools-desktop包 | apt install open-vm-tools-desktop |
这张表里的第三行尤其重要。很多人升级内核后复发，就是因为在新的内核目录下找不到vmhgfs模块。你可以在重启前主动检查：
ls /lib/modules/$(uname -r)/misc | grep vmhgfs如果这个目录下没有vmhgfs相关文件，说明新内核缺少模块，重启后必挂。
4.2 三个实操中容易踩的坑
第一个坑：只注释fstab不重装Tools。这种情况我当时见过不止一次：用户把fstab里的挂载行注释掉，系统能启动了，就以为完事了。结果VMware里的共享文件夹开关还开着，某些版本的open-vm-tools会在下次重启时重新注入挂载配置，问题又回来了。正确做法是注释fstab和重装open-vm-tools同时做，缺一不可。
第二个坑：直接删除fstab里的那行，而不是注释。删除虽然也能让系统启动，但以后想恢复共享文件夹时，你得重新复习挂载配置的正确写法。以我自己的习惯，注释行保留着反而是个提示：这里曾经挂载过共享目录，以后环境变了也知道去哪改。删除一旦误删其他行，恢复起来更麻烦。
第三个坑：升级内核后不管模块状态就重启。Ubuntu 22.04使用HWE内核机制，apt upgrade很可能把内核版本更换掉。升级后如果不确认vmhgfs模块是否匹配新内核，重启大概率回到黑屏状态。我现在养成一个习惯：升级完先不急着重启，执行一遍uname -a和ls /lib/modules/$(uname -r)/misc | grep vmhgfs确认新内核有共享目录模块，再执行reboot。
5. 避免以后重启再黑屏：内核升级与快照习惯
5.1 内核升级前后记住这三条
把下面这套动作变成例行公事，基本能把这类问题堵在门外。
升级前，在VMware里先给虚拟机拍快照。右键虚拟机 -> Snapshot -> Take Snapshot，整个过程不影响虚拟机关机状态下的文件，也可以开着机直接拍。有这个快照垫底，后面升级装包再出什么幺蛾子，回滚只需要一分钟。
升级后、重启前，检查新内核的模块目录和当前内核是否一致：
uname -r ls /lib/modules/$(uname -r)/misc | grep vmhgfs modinfo vmhgfs如果查到模块缺失，执行：
apt install --reinstall open-vm-tools open-vm-tools-desktop或者安装open-vm-tools-dkms重新构建模块。确认无误后再重启。这一套流程本质上就是把“不等重启发现黑屏”变成“重启前主动排雷”，看起来多花两分钟，实际省下的是黑屏后半小时的折腾。
5.2 现实一点的建议：fstab别写太满
再分享一个我自己的习惯：共享文件夹不一定要写进fstab。如果你只是偶尔传个文件，完全可以在需要的时候手动执行vmhgfs-fuse挂载，用完再umount。这样fstab里少一行，启动阶段就少一个失败点，系统也更干净。
如果确实需要开机自动挂载，建议在fstab里加上nofail选项：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,defaults,uid=1000,gid=1000,nofail 0 0加上nofail后，即使这个挂载项失败了，systemd也只会把它标记为失败，不会拖累整个local-fs.target。这笔交易很划算：你不需要在功能性和启动成功率之间二选一。
最后说个私心话：我现在看到Ubuntu 22.04虚拟机报这个错，第一反应永远是进恢复模式看fstab。90%以上的“Dependency failed for Local File Systems”，最后查出来都是fstab挂载项和VMware Tools之间打架。别被那句“Dependency failed”吓到，它不过是个传话的，真正的问题藏在fstab和服务状态里。把这两样搞明白了，这个坑你以后基本不会再踩第二次。