装虚拟机这件事，头几次都挺顺，真正开始难受，往往是在往虚拟机里塞文件的那一刻。宿主机的项目目录、数据集、安装包、脚本，怎么让虚拟机里也能读写，同时改完立刻生效、不用来回拷贝，这就是VMware 共享文件夹要解决的问题。说白了，它是在宿主机和客户机之间搭一条"内部通道"，虚拟机开机就能看到一个目录，两边看到的还是同一份文件，宿主机改了配置文件，客户机里cat一下立刻是新内容，反过来也一样。这套机制对做开发、测环境、跑数据、搞运维的人特别值钱：不用再靠 U 盘、网盘、邮箱附件倒腾，也不用为了改一个参数就重新打包一份代码。
我自己的使用场景挺杂，Windows 宿主机跑 Linux 客户机做编译和靶场练习，Linux 宿主机开 Windows 客户机测客户端程序，还有同事之间互传虚拟机镜像那种情况。用下来最大的感受是：共享文件夹本身不难，难的是版本差异、系统差异、权限差异叠加在一起，导致"我明明设置了就是看不到文件""重启之后挂载没了""Windows 里提示找不到网络路径"这类问题反复出现。下面我把这些年踩过的坑、验证过的做法、以及一些救急的排查手法完整整理一遍，从原理到配置到排错，新手可以直接照着抄，有基础的可以跳到故障排查那一节找答案。
1. 先搞清楚共享文件夹的适用边界
在动手配置之前，我觉得有必要先说清楚"什么时候该用它、什么时候别用它"。很多人一上来就配共享文件夹，结果发现传输大文件慢得离谱，或者权限怎么写都不对，然后开始怀疑人生。其实这类问题大部分不是配置错了，而是选错了方案。
1.1 共享文件夹的本质与它擅长的事
VMware 的共享文件夹走的是 VMware Tools 里的一套驱动，Linux 客户机上叫hgfs（Host-Guest File System），Windows 客户机上则表现为一个虚拟网络位置\\vmware-host\Shared Folders。它不依赖真实的网络协议栈，也不需要你在客户机里配 IP、开端口、调防火墙，虚拟机设置面板里勾一下、把宿主机的目录指过去，客户机装了 Tools 就能看见。这个特性决定了它的优势区间：配置成本极低、双向实时同步、跨重启仍然存在（只要你别删设置）。
它最舒服的用法有这么几类。第一类是放代码和配置，宿主机上用顺手的编辑器改，客户机里跑编译或者跑服务，省掉来回同步的动作。第二类是放资源文件，比如字体包、数据集、测试用的样本文件，虚拟机重建之后这些还在宿主机上，随时能拿。第三类是放交付物，客户机里跑出来的日志、测试报告、生成的文件，宿主机直接就能打开看，不用先导出来。第四类是做练习环境，靶场、实验目录挂进去，出了一堆临时文件也不怕污染客户机磁盘。
反过来说，它不太适合的场景也很明确：海量小文件的高频读写、几十 GB 以上的大文件搬运、需要多台虚拟机同时高并发读写同一个目录。前两种情况下 hgfs 的吞吐表现经常不如走真实网络协议，第三种情况则容易出现锁竞争和"我写的文件你看不到"的诡异现象。这些在后面的性能章节我会展开讲。
1.2 四种文件交换方式的横向对比
光说优劣太虚，直接上表更直观。下面这张表是我根据实际使用感受整理的，不代表绝对数值，但方向性上是靠谱的。
| 方式 | 配置难度 | 传输速度（大文件） | 传输速度（大量小文件） | 是否需要网络 | 适用场景 |
|---|---|---|---|---|---|
| VMware 共享文件夹（hgfs） | 低 | 中等 | 偏慢 | 不需要 | 代码、配置、日常小文件同步 |
| SMB/CIFS 网络共享 | 中 | 快 | 快 | 需要（推荐仅主机网络） | 大文件、多虚拟机、跨物理机 |
| SFTP/SCP | 中 | 快 | 中等 | 需要 | 单向传输、脚本化批量同步 |
| ISO 挂载 / U 盘直通 | 低 | 快（只读为主） | 快 | 不需要 | 一次性大文件分发、装机介质 |
这张表里我最想强调的是最后两列的"是否需要网络"。共享文件夹和 ISO 挂载是"零网络依赖"的方案，虚拟机网卡没配好、网段冲突、防火墙拦了，都不影响它们工作。这就是为什么在做网络实验的时候，很多人宁愿用共享文件夹传脚本，也不愿意去调 SMB——少一个变量就少一次排查。
还有一点常被忽略：这几种方式是可以叠加使用的。我自己的习惯是日常开发用共享文件夹，需要拉大数据集的时候临时起一个 SMB 共享或者直接用scp推过去，跑完再关掉。不需要死守一种方案。
1.3 选型时真正该问自己的三个问题
我在给别人做环境的时候，通常会先问三个问题，答完基本就能定方案了。
第一个问题：这些文件是长期驻留还是用完就走？长期驻留用共享文件夹，宿主机的目录当"真身"，虚拟机只是借用。用完就走，尤其是几百 MB 以上的数据包，scp或者临时 ISO 更省事。
第二个问题：是双向改写还是单向投喂？双向改写要注意权限和文件属主，共享文件夹里 Linux 侧挂载时的uid/gid参数很关键。单向投喂就简单了，只读挂载最安全，也不怕客户机里的程序误删源文件。
第三个问题：虚拟机会不会重建、快照回滚、或者被复制到别人机器上？如果会，那共享文件夹的宿主机路径就不能写死。因为在别人机器上打开虚拟机，那个路径不存在，共享文件夹会直接失效甚至报错。这种情况我建议在虚拟机设置里用相对语义的目录名，并且在说明文档里写清楚"共享目录需要在本机先建好"。
2. VMware Tools 是绕不开的前置条件
所有关于共享文件夹的问题，大概有七成最后都追到了 VMware Tools 上。这一节单独拿出来讲，是因为它太容易出事了，而且出事的现象千奇百怪，不看原理根本找不到方向。
2.1 VMware Tools 与 open-vm-tools 到底用哪个
这两个东西很容易搞混。VMware Tools是官方随 VMware Workstation 一起分发的那套工具，通常以 ISO 镜像形式挂载到客户机里，进去之后自己编译安装。open-vm-tools是各大 Linux 发行版仓库里自带的开源实现，本质上做的是同一件事，功能覆盖也基本一致。
我的实践结论很直接：只要发行版仓库里有 open-vm-tools，就别去手动编译官方那套。原因有几条。一是编译需要内核头文件和编译工具链，build-essential、linux-headers-$(uname -r)这些依赖一旦对不上版本，编译直接失败，报错还特别不友好。二是官方安装包在客户机内核升级之后经常失效，得重装一遍，而仓库里的包会跟着内核更新自动重建模块。三是 open-vm-tools 的安装就是一行命令，五分钟搞定。
当然也有例外。某些定制程度很高的发行版仓库里没有对应包，或者版本太老不支持你当前的内核，那就只能走官方 ISO。另外 Windows 客户机没有"open-vm-tools"这个概念，只能用官方 Tools，这个后面单独说。
2.2 Linux 客户机的安装实操
以 Debian 系（含 Ubuntu、Kali）为例，安装命令是这样的：
sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktop fuse3open-vm-tools是核心组件，负责 hgfs 挂载、时间同步、内存气球这些底层功能。open-vm-tools-desktop提供桌面集成能力，比如分辨率自适应、剪贴板互通、拖拽支持，桌面版客户机建议一起装上。fuse3是用户态文件系统支持，hgfs 的挂载依赖它。
RHEL 系（含 Rocky Linux、CentOS Stream）用的是另一套命令：
sudo dnf install -y open-vm-tools open-vm-tools-desktop fuse sudo systemctl enable --now vmtoolsd注意 RHEL 系装完要确认vmtoolsd这个服务起来了。Debian 系一般装完自动起，但也可以在装完之后用systemctl status vmtoolsd确认一下，状态不是active (running)的话手动启一下。
银河麒麟、统信这类基于 Debian 或 RHEL 的国产发行版，同样优先在仓库里找open-vm-tools，找不到再考虑官方 ISO。它们通常预装了桌面环境，open-vm-tools-desktop也一并装上体验会好很多。
装完之后先别急着配共享文件夹，跑一条命令验证：
vmware-hgfsclient如果这条命令有输出，说明 Tools 工作正常，后面就是挂载的问题了。如果提示command not found，那说明 Tools 压根没装成功，或者装了但没生效，两种情况分别处理：前者重装，后者重启客户机。
提示：安装 open-vm-tools 之前，先把客户机的软件源更新一遍。仓库索引过旧会导致装到老版本，老版本的 hgfs 对新内核支持不好。
2.3 Windows 客户机的 Tools 安装与"脚本未能成功运行"报错
Windows 客户机这边没有选择，只能装官方 Tools。常规流程是在 VMware 菜单里点"虚拟机 → 安装 VMware Tools"，客户机里会自动挂载一个光驱，进去双击setup.exe一路下一步就行。
但很多人会撞上这个报错："继续运行脚本未能在虚拟机中成功运行"，然后安装回滚，Tools 装上又好像没全装上，共享文件夹自然也用不了。这个报错的根因通常是安装程序在后续阶段没拿到足够的权限，或者被安全软件拦了。我处理过的案例里，有效的做法有这几个：
第一个，用管理员身份跑安装程序。不要双击setup.exe，而是右键选择"以管理员身份运行"。听起来很废话，但确实解决过好几次。
第二个，临时把用户账户控制调到最低并暂停安全软件。安装过程会注册驱动和写系统目录，被拦了就回滚。装完记得调回去。
第三个，先装好系统补丁再装 Tools。特别是比较老的 Windows 客户机，缺运行库会导致后续脚本执行失败，先打补丁再装。
第四个，确认虚拟机满足 Tools 的最低要求。Windows 7、Windows 10、Windows 11、Windows Server 各版本对 Tools 版本有对应关系，用太新的 Tools 去装太老的系统，或者反过来，都可能出问题。看 VMware 官方文档的兼容矩阵最靠谱。
如果实在装不上，还有个绕路方案：不装 Tools，直接在宿主机开一个 SMB 共享，客户机通过映射网络驱动器访问。功能上少了一些集成特性，但文件交换这件事完全能满足。这个方案我在第四节展开。
2.4 装不上时的清理与重装思路
反复安装失败会留下残留，这时候继续装只会越来越乱。思路是先清干净再重来。Windows 侧可以从控制面板卸载 VMware Tools，重启之后再装一次；残留的驱动目录和注册表项如果影响安装，用官方提供的清理工具处理会彻底一些。Linux 侧相对简单，apt purge或者dnf remove之后把/etc/vmware-tools、/usr/lib/vmware-tools这些目录一并删掉，重启再装。
这里我要提醒一个细节：卸载完一定要重启。驱动级的组件不重启，内核里还挂着旧模块，新装上去就会各种冲突，表现出来就是"装了但没效果"。这个坑我踩过不止一次，后来养成习惯，凡涉及驱动变更，装和卸都重启一遍，省下的排查时间远比重启那几十秒值。
3. Windows 宿主机 + Linux 客户机：完整配置流程
这是最常见也最需要讲清楚的一种组合，尤其对做开发的同学来说，Windows 用着顺手，Linux 客户机跑服务和编译。下面按顺序走一遍。
3.1 宿主机目录的准备与命名规则
先在 Windows 上选一个目录，比如D:\vm-share\project。这个目录的选址有讲究，我建议遵守这几条经验。
不要放在系统盘的用户目录下面。C:\Users\你的名字\Desktop这种路径在某些语言环境下会出现编码问题，Windows 自己用着没事，Linux 客户机挂载之后可能就出现乱码或者干脆挂不上。放在 D 盘或 E 盘的独立目录下最稳。
目录名和子文件名尽量用 ASCII。中文目录名在 hgfs 上表现不稳定，有的版本没问题，有的版本直接看不到。文件名也一样，我遇到过中文文件名在客户机里变成一长串问号的情况，虽然文件内容没坏，但脚本处理起来就麻烦了。
路径不要带空格。虽然现在大部分工具都能处理带空格的路径，但在fstab里写挂载项的时候，空格会给你带来额外的转义麻烦，能不踩就不踩。
规划好只读还是可写。纯资料目录建议设成只读，代码目录设成可写。VMware 的设置面板里有个"只读"勾选框，勾上之后客户机完全没有写权限，比在客户机里靠文件权限控制更硬。
3.2 虚拟机设置面板里的启用步骤
共享文件夹的开关在虚拟机设置里，路径是：选中虚拟机 → 编辑虚拟机设置 → 选项标签页 → 共享文件夹。这里有三个层次要依次打开。
首先是文件夹共享这个总开关，有三个选项：禁用、仅启用以下文件夹、总是启用。我一般用"总是启用"，这样虚拟机开机就自动挂上，不用每次手动操作。如果你有多个虚拟机、共享目录又不希望互相干扰，那就用"仅启用以下文件夹"，逐个添加。
然后是添加具体文件夹，点"添加"按钮，弹出向导，依次填宿主机的目录路径、共享名称、是否只读。这里的"共享名称"是客户机里看到的挂载名，和宿主机的目录名可以不一样。我习惯用简短的小写名，比如project、data、tools，方便在命令行里敲。
最后是在 Windows 客户机中映射为网络驱动器这个选项，它是给 Windows 客户机用的，Linux 客户机不需要，保持不勾或者按需勾。
设置完之后最好重启一次客户机，让 Tools 重新枚举共享项，比手动折腾快得多。
3.3 Linux 侧挂载：两种做法的取舍
重启之后，Linux 客户机里先确认共享项被识别到了：
vmware-hgfsclient输出的名字列表里应该有你在面板里加的那些。如果这里有输出，但/mnt/hgfs下面空空如也，那就是挂载这一步没做。有两种做法。
第一种是临时手动挂载，适合先验证能不能用：
sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other -o uid=1000 -o gid=1000 -o umask=022 ls /mnt/hgfsvmhgfs-fuse是新的挂载工具，老版本的工具用的是mount -t vmhgfs，如果你的系统里没有vmhgfs-fuse，先看看open-vm-tools是不是版本太老。.host:/这个写法意思是"所有共享项"，也可以写成.host:/project只挂某一个。
allow_other参数很关键，它让非 root 用户也能访问挂载点内容。不加这个参数，普通用户进去会看到权限拒绝，很多人卡在这一步就是因为漏了它。
uid和gid是指定挂载后文件的属主，一般填你当前登录用户的 ID。查一下：
id -u id -g大多数桌面发行版第一个用户是 1000，但云镜像或者某些定制系统上不一定是，别想当然。填错的后果是所有文件在客户机里都归 root，普通用户改不了，编辑器保存就报错。
umask=022控制的是默认权限掩码，效果是文件 644、目录 755，日常够用。
第二种是写入 fstab 持久化，一劳永逸：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,defaults,nofail 0 0写完之后sudo mount -a验证一下有没有报错，然后重启测试。这里的文件系统类型要写fuse.vmhgfs-fuse，有些老教程写的是vmhgfs，在新系统上会报"unknown filesystem type"。
nofail这个选项强烈建议加上。它的作用是：挂载失败也不阻塞开机。共享文件夹在虚拟机启动早期可能还没准备好，没有nofail的话，客户机会卡在开机流程里等你输入 root 密码进维护模式，体验非常糟糕。
注意：如果你的用户不是 root，想用
allow_other参数，需要先确认/etc/fuse.conf里user_allow_other这一行没有被注释掉。有些发行版默认注释，不加的话挂载直接失败。
改法很简单：
sudo sed -i 's/^#user_allow_other/user_allow_other/' /etc/fuse.conf这个细节在 Kali 和部分 Ubuntu 版本上特别容易踩，因为它们的默认配置就是注释状态。
3.4 多共享项与目录结构的组织建议
当共享目录多了以后，全挂在/mnt/hgfs下面会有点乱。我自己的做法是在 fstab 里逐个挂到独立的挂载点：
.host:/project /mnt/share/project fuse.vmhgfs-fuse allow_other,defaults,nofail 0 0 .host:/data /mnt/share/data fuse.vmhgfs-fuse allow_other,defaults,nofail,ro 0 0 .host:/tools /mnt/share/tools fuse.vmhgfs-fuse allow_other,defaults,nofail,ro 0 0这样project可写，data和tools只读，权限边界在挂载层就定好了，客户机里的程序再怎么乱写也伤不到源文件。这比在宿主机上靠共享面板的只读开关控制要灵活，因为可以精确到单个共享项。
挂载点目录记得先建好，mkdir -p /mnt/share/{project,data,tools}，fstab 不会自动帮你创建目录。
4. 反向与跨系统：Linux 宿主、Windows 客户机以及纯网络方案
前面讲的是最典型的一种组合，但现实里情况要杂得多。这一节把其他几种常见组合和替代方案捋一遍。
4.1 Linux 客户机里的 Windows 网络共享挂载
先说一个很实用的场景：宿主机是 Windows，你要在 Linux 客户机里访问宿主机上已经存在的网络共享，而不是用 VMware 的共享文件夹机制。这种场景在混合环境里很常见，比如公司内网的文件服务器、NAS，或者同事共享出来的目录。
Linux 侧要装 cifs 工具：
sudo apt install -y cifs-utils # Debian 系 sudo dnf install -y cifs-utils # RHEL 系临时挂载：
sudo mkdir -p /mnt/win sudo mount -t cifs //192.168.1.100/share /mnt/win \ -o username=youruser,password=yourpass,uid=1000,gid=1000,iocharset=utf8这里的//192.168.1.100/share是共享地址，iocharset=utf8解决中文文件名乱码，uid/gid和前面一样，决定挂载后文件的属主。
持久化到 fstab 的时候，千万别把密码明文写进去。正确做法是单独建一个凭据文件：
sudo tee /root/.smbcred > /dev/null <<'EOF' username=youruser password=yourpass domain=WORKGROUP EOF sudo chmod 600 /root/.smbcred注意chmod 600是必须的，权限太松 cifs 会拒绝读取凭据文件，报"permission denied"之类的错误。然后 fstab 写成这样：
//192.168.1.100/share /mnt/win cifs credentials=/root/.smbcred,uid=1000,gid=1000,iocharset=utf8,nofail,_netdev 0 04.2 CIFS 挂载重启后失效的完整解法
"重启后挂载没了"这个现象，问的人非常多。原因通常有四个，逐一排除就行。
第一个原因是网络还没起来就去挂载了。fstab 在开机很早的阶段就会执行，那时候网卡可能还没拿到 IP，mount -t cifs自然失败。解决办法是加_netdev选项，告诉系统"这个挂载需要网络，等网络就绪再挂"。在 systemd 的系统上还可以配合x-systemd.automount用自动挂载，第一次访问目录时才真正挂载，彻底避开开机时序问题。
第二个原因是没加nofail。挂载失败会阻塞开机，然后你可能在维护模式里手动注释掉 fstab 才进得去系统。加nofail之后，失败就失败，不影响开机，你还能进去慢慢查。
第三个原因是凭据文件的权限或路径不对。/root/.smbcred在某些精简系统上权限是 644，cifs 会拒绝读。检查一下ls -l /root/.smbcred，确保是 600。
第四个原因是主机地址变了。如果你写的是主机名而不是 IP，DNS 解析失败就会挂不上。虚拟机环境下 IP 相对固定的时候，直接写 IP 更省心。
综合下来我推荐的 fstab 写法是这样：
//192.168.1.100/share /mnt/win cifs credentials=/root/.smbcred,uid=1000,gid=1000,iocharset=utf8,file_mode=0664,dir_mode=0775,nofail,_netdev,x-systemd.automount 0 0file_mode和dir_mode是给不支持 Unix 权限的 SMB 服务器打的补丁，用来在客户机侧模拟出一套合理的权限位。如果你挂载之后发现文件全是-rwxr-xr-x或者全是----------，改这两个参数就能解决。
改完 fstab 的第一件事永远是：
sudo systemctl daemon-reload sudo mount -adaemon-reload是让 systemd 重新读 fstab 生成的挂载单元，不执行这一步，改了等于没改。这个是很多人忽略的关键动作。
4.3 Windows 客户机怎么访问共享文件夹
Windows 客户机的路径不太一样。装了 Tools 之后，共享文件夹不会出现在"此电脑"里，而是要通过网络位置访问。地址是：
\\vmware-host\Shared Folders\共享名称在资源管理器地址栏敲这个路径就能进去。想省事的话，右键映射成网络驱动器：
net use Z: \\vmware-host\Shared Folders\project /persistent:yes/persistent:yes让这个映射在重启后依然存在。查看已有的映射用net use，删除用net use Z: /delete。
如果你的 Tools 装得不太顺利，共享文件夹列表是空的，可以试试在 VMware 设置里勾上"在 Windows 客户机中映射为网络驱动器"，某些版本上这个选项会触发不同的挂载路径，反而能绕开问题。
4.4 Windows 11 访问 Windows 7 共享提示找不到网络路径
这个组合在老旧内网里特别常见：新机器是 Windows 11，老设备还在跑 Windows 7 或者更早的 SMB 实现。典型症状是资源管理器里能看到设备名，点进去却提示**"找不到网络路径"**，或者弹一个"你不能访问此共享文件夹，因为安全策略阻止了未经身份验证的来宾访问"。
根因是较新的 Windows 默认关闭了 SMB1 客户端，并且禁用了"不安全的来宾登录"。解决方向有两个。
方向一是用账号密码访问，不要走来宾。在目标共享所在的机器上建一个带密码的本地账号，给它共享目录的读取权限，然后在 Windows 11 这边用\\IP\共享名访问，弹窗里输入账号密码，勾选"记住我的凭据"。这是最干净的做法。
方向二是临时放开来宾登录，仅限完全可信的内网环境使用。专业版可以通过本地组策略调整：计算机配置 → 管理模板 → 网络 → Lanman 工作站 → 启用不安全的来宾登录。家庭版没有组策略编辑器，用注册表方式：
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v AllowInsecureGuestAuth /t REG_DWORD /d 1 /f改完重启一下相关服务或者重启系统生效。
注意：放开来宾登录属于降低安全门槛的操作，只在完全可控的内网里做，做完之后把共享目录的权限收紧，别给写的权限。
配套还要检查几件事：目标机器的共享服务是否在跑、防火墙有没有放行文件和打印机共享、网络配置文件是不是设成了"专用网络"（公用网络下发现功能默认关闭）。这些一条条过一遍，基本上都能定位到。
5. 高频故障排查速查
前面各种情况散着讲了，这一节集中整理成速查表，出问题的时候直接对号入座。
5.1 共享文件夹目录是空的怎么办
这是最高频的问题。排查顺序我建议这样走，从下往上、从易到难。
第一步，在客户机里跑vmware-hgfsclient。有输出说明 Tools 正常、共享项也识别到了，问题在挂载；没输出说明 Tools 层面就没通，回到第二节处理 Tools。
第二步，确认挂载点。mount | grep hgfs看一眼，没挂上就手动挂一次，看报什么错。
第三步，手动挂载报错的话，逐条看。报"permission denied"多半是allow_other和/etc/fuse.conf的问题；报"no such device"通常是 Tools 版本和内核不匹配，需要重装或者编译官方版本；报"Connection timed out"则是 Tools 服务没跑起来。
第四步，如果挂上了但目录还是空，检查宿主机目录是不是真的存在、有没有被删掉、路径里有没有特殊字符。有个经典情况是宿主机上改了目录名，但虚拟机设置里还指向旧路径，这种时候vmware-hgfsclient可能有输出，挂载也成功，但里面是空的。
5.2 权限拒绝与文件属主异常
现象是能看到文件，但改不了、删不掉，或者保存时报"只读文件系统"。
先看挂载参数里的uid和gid是不是你当前用户的 ID。挂载之后ls -l /mnt/hgfs看一眼，如果文件属主是root root，说明挂载时没指定或者指定错了。重新挂载，带上正确的uid/gid。
再看虚拟机设置里那个"只读"勾选框。勾上了的话，客户机侧完全没有写权限，怎么调都不行，取消勾选就行。
还有一种情况是宿主机侧的文件权限。Windows 宿主机上文件如果被别的进程独占（比如 Excel 打开了一个表格），客户机侧写入也会失败。Linux 宿主机上则是文件属主和权限位的问题，chmod/chown处理一下。
5.3 常见报错与对应处置速查表
| 现象 | 最可能的原因 | 处置动作 |
|---|---|---|
vmware-hgfsclient无输出 | Tools 未安装或未运行 | 重装 open-vm-tools，检查 vmtoolsd 服务 |
/mnt/hgfs为空但共享项存在 | 没有执行挂载 | 手动 vmhgfs-fuse 挂载，或写入 fstab |
| 挂载报 unknown filesystem type | fstab 里类型名写错 | 改成fuse.vmhgfs-fuse |
| 普通用户进去提示权限拒绝 | 缺allow_other | 修改/etc/fuse.conf后重新挂载 |
| 开机卡住进维护模式 | 挂载失败阻塞启动 | fstab 加nofail |
| CIFS 重启后失效 | 网络未就绪 | 加_netdev、x-systemd.automount |
| CIFS 报凭据读取失败 | 凭据文件权限过松 | chmod 600 /root/.smbcred |
| 中文文件名乱码 | 字符集未指定 | 挂载参数加iocharset=utf8 |
| Windows 提示找不到网络路径 | 来宾登录被禁 / SMB1 关闭 | 改用账号密码访问，或按需放开来宾登录 |
| 提示阻止未经身份验证的来宾访问 | 同上 | 同上 |
| Tools 安装报"脚本未能成功运行" | 权限不足或安全软件拦截 | 管理员身份运行，临时关闭拦截后重装 |
5.4 查看和清理已保存的共享凭据
Windows 这边有个很容易被忽略的地方：凭据管理器里缓存的账号密码。第一次访问共享输错密码并勾了记住，之后就一直用错的那份，怎么输新的都提示失败。
查看已保存的凭据：
cmdkey /list清理某个目标：
cmdkey /delete:192.168.1.100也可以打开控制面板的"凭据管理器 → Windows 凭据"，图形界面里删。这个操作在调试共享访问问题时几乎是必做项，因为凭据缓存导致的失败太隐蔽了，表面上看就是"密码明明是对的"。
Linux 侧则是检查~/.smbcredentials之类被 cifs-utils 生成的文件，以及 keyring 里存的内容，一般用mount.cifs时不会自动缓存，但桌面环境通过文件管理器挂载时会存到 keyring 里，清理方式是打开"密码和密钥"应用手动删对应条目。
6. 性能调优与工程化实践
配置能跑通只是及格线，用久了才会发现性能和协作层面的问题更磨人。这一节聊点进阶的。
6.1 大文件与小文件：两种截然不同的表现
我做过不少对比测试，结论可以概括成两句话：hgfs 在单个大文件的顺序读写上表现中等偏下，在大量小文件的随机读写上表现明显偏弱。
造成这个差异的原因跟它的实现方式有关。hgfs 走的是 VMware 自己的驱动通道，没有真实网络的 MTU、窗口、重传这些概念，但也没有针对大块传输做过深度优化。小文件场景下，每次文件操作都要经过一次用户态和内核态之间的往返，开销被摊薄不了，文件一多就累加得很明显。
所以我的实用建议是分场景处理。代码、配置、脚本这类小文件，用共享文件夹最合适，因为总量小，慢一点无感，胜在方便。数据集、镜像、视频这类大文件，别用共享文件夹，改成在宿主机上开一个仅主机网络（Host-Only）的 SMB 共享，或者干脆用scp推。仅主机网络的好处是流量不出物理网卡，速度基本能跑满虚拟网卡的上限，实测比共享文件夹快不少。
如果非得用共享文件夹传大文件，有个小技巧是先在客户机本地打包再拷贝。把一万个小文件打包成一个 tar 再传，速度差距非常明显，因为把一万次小操作合并成了一次顺序读写。这个思路在其他文件传输场景里同样适用。
6.2 共享文件夹的安全边界
共享文件夹有一个容易被忽视的特性：客户机的写入直接落到宿主机文件系统上。这意味着客户机里的恶意程序、失控脚本，可以删掉或篡改你在宿主机上的文件。做安全测试、跑来路不明的程序的时候，这一点必须处理好。
我自己的做法有三条。第一条，测试类虚拟机的共享目录一律设成只读，需要往客户机里送东西的时候，走单独的只读共享项，宿主机侧用完就删。第二条，共享目录不要和宿主机上的重要目录重合。有人图省事把整个D:\挂进去，这个习惯风险太高，一旦客户机里跑了个删文件的脚本，后果不可逆。第三条，共享目录里的数据要纳入备份。因为它的真身就在宿主机上，宿主机磁盘出问题，数据一样丢，共享机制本身不提供任何冗余。
另外，宿主机上共享出去的那个目录，权限设置要合适。Windows 上不要给 Everyone 完全控制，Linux 上注意目录的组权限，避免同机器上其他用户看到不该看的内容。
6.3 团队协作时的共享目录规范
如果是小团队共用一个宿主机、或者互相分发虚拟机镜像，共享目录的约定就很重要了。我踩过的坑主要有两个。
一是路径写死在虚拟机配置里。别人拿到你的虚拟机文件，打开之后共享文件夹全是感叹号，因为D:\vm-share\project在他机器上不存在。解决办法是在团队里约定统一的目录结构，或者干脆在虚拟机里放一份说明文档，写清楚需要先建哪些目录。
二是多台虚拟机同时挂同一个目录。如果这些虚拟机只是读，问题不大。如果都在写，尤其是写同名文件，就会出现覆盖和锁冲突。我的建议是把共享目录按虚拟机切分，比如share/vm-dev、share/vm-test，需要交换文件的话走一个专门的share/exchange目录，并且约定好文件命名带机器标识和时间戳。
还有一个细节是换行符。Windows 宿主机和 Linux 客户机之间传递文本文件，换行符不一致的问题会时不时冒出来。编辑器一般能识别，但脚本处理的时候容易出问题。我的习惯是在客户机侧统一用dos2unix转换一遍再执行，或者在编辑器里把默认换行符设置成 LF，从源头上避免。
最后说一个我用了很久的小技巧：写一个开机自检脚本。内容很简单，检查/mnt/hgfs有没有挂上、共享目录里能不能读到预期文件、写一个临时文件试试权限，任何一项不通过就在终端上打印提示。放在客户机的自动启动里，开机第一眼就知道环境是不是正常，比事后一个个排查快得多。脚本长这样：
#!/bin/bash if ! mountpoint -q /mnt/hgfs; then echo "[警告] 共享文件夹未挂载，尝试手动挂载" sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other -o uid=$(id -u) -o gid=$(id -g) fi if [ -d /mnt/hgfs/project ]; then echo "[正常] project 共享目录可访问" else echo "[警告] project 共享目录不可见，请检查虚拟机设置" fi这段脚本没什么技术含量，但省下的时间很实在。用虚拟机的人都知道，环境相关的零碎问题最消耗耐心，能用一条脚本提前暴露出来，就别等到干活干到一半才发现。
