1. 先把共享文件夹这件事的边界搞清楚
在 VMware Workstation 里给 Ubuntu 虚拟机配共享文件夹，表面上看只是点几下鼠标、填一个宿主机路径的事，但我见过太多人卡在“设置里明明配好了，进系统却找不到目录”或者“重启之后挂载没了”这类问题上。根本原因不是操作步骤记错了，而是没搞清楚这套机制到底在什么层面工作。它既不是网络共享，也不是简单的磁盘映射，而是 VMware Tools（现在叫 open-vm-tools）在虚拟机内部提供的一套伪文件系统服务，理解这一点，后面所有的权限、重启失效、路径找不到的问题才有解。
先把适用场景说清楚。这套方案适合本地开发调试：宿主机是 Windows 或 Linux，虚拟机里跑 Ubuntu，需要频繁在两边传代码、传配置文件、传数据集。不适合生产环境的大规模文件服务，也不适合需要高性能 IO 的场景，因为共享文件夹走的是 VMware 的 HGFS 协议，吞吐和延迟都比原生磁盘差一截。如果你的需求是几个 G 的数据集频繁读写，老老实实配 SMB 或者直接挂块虚拟磁盘更靠谱。
关键词里出现的“cifs挂载共享文件夹重启后失效”“ubuntu共享文件夹权限不够”“物理机和虚拟机共享文件夹”，其实都指向同一类困惑。共享文件夹（Shared Folders）和 CIFS/SMB 挂载是两条完全不同的路：前者依赖 open-vm-tools，后者是走网络协议挂宿主机暴露的共享。很多人把两者混为一谈，配了一套 CIFS 自动挂载，结果 VMware 那边的共享文件夹压根没生效，白折腾半天。这篇就把 VMware 原生共享文件夹这条路从头到尾讲透，包括环境准备、配置、权限、开机自动挂载、以及那几个最容易踩的坑。
需要提前说明的是，下面涉及的版本以 VMware Workstation 17 和 Ubuntu 22.04/24.04 LTS 为主，其他版本大同小异。如果你用的是较老的 Ubuntu 或者非 LTS 版本，个别包名和路径可能有差异，我会在对应位置标注。
2. 环境准备：别急着点“共享文件夹”，先把这三样确认了
很多人一上来就打开虚拟机设置找“Options - Shared Folders”，结果发现选项是灰的，或者配完不生效。问题通常出在三个前置条件上：open-vm-tools 没装全、虚拟机没装桌面环境导致部分组件缺失、或者 VMware Workstation 本身的版本与 Ubuntu 内核不匹配。这三样按顺序确认，能省掉后面 80% 的返工。
2.1 open-vm-tools 和 open-vm-tools-desktop 的区别与取舍
Ubuntu 从某个版本开始，官方仓库里的 open-vm-tools 是默认推荐方案，比手动装 VMware 官方的 VMware Tools 更省事，内核升级后也不容易崩。但这里有个关键点：只装open-vm-tools是不够的，共享文件夹的挂载功能由open-vm-tools提供，而宿主机与虚拟机之间的拖拽、剪贴板共享、分辨率自适应这些桌面特性由open-vm-tools-desktop提供。如果你装的是 Ubuntu Server（无桌面），装前者就够；如果是桌面版，两个都装。
命令如下，先更新源再安装：
sudo apt update sudo apt install open-vm-tools open-vm-tools-desktop -y注意：如果你之前手动装过 VMware 官方的 VMware Tools，先把它卸干净再装 open-vm-tools，两套工具会冲突，最典型的表现就是
/mnt/hgfs目录时有时无。
判断是否装全，可以用这个命令看服务状态：
systemctl status open-vm-tools正常应该是active (running)。如果显示inactive或者failed，先journalctl -u open-vm-tools看日志，常见原因是内核模块vmw_vmci、vmhgfs没加载成功，通常重启一次虚拟机就好了。
2.2 共享文件夹功能到底依赖哪个内核模块
这一点值得单独拎出来说，因为它直接决定了你能不能看到/mnt/hgfs。VMware 的共享文件夹在内核层面依赖vmhgfs（较新版本是vmhgfs-fuse）这个模块。早期版本是内核态实现，新版本改成了 FUSE（用户态文件系统）实现，所以你会看到vmhgfs-fuse这个进程。这也是为什么新版 Ubuntu 上/mnt/hgfs挂载方式和老教程对不上——老教程让你mount -t vmhgfs，新版得用vmhgfs-fuse。
验证模块是否加载：
lsmod | grep vmhgfs如果没有输出，说明模块没加载。先确认 open-vm-tools 装好了，然后手动加载试试：
sudo modprobe vmhgfs新版本可能提示模块不存在，因为已经改用 FUSE 方案，这时候看的是vmhgfs-fuse命令是否存在：
which vmhgfs-fuse如果这个命令存在，说明环境是 OK 的，只是还没挂载而已。
2.3 虚拟机设置里那个选项为什么是灰的
回到 VMware Workstation 界面，选中虚拟机 → 右键 → Settings → Options 标签页 → Shared Folders。如果这里整个是灰色不可点，通常是两个原因：一是虚拟机正在运行且没有装 open-vm-tools（VMware 检测不到工具就不给配）；二是虚拟机处于挂起状态。正确做法是：先关机，装好 open-vm-tools，再关机状态下配置共享文件夹，开机后自动生效。
配置的时候选 “Always enabled”，然后 Add 一个条目，Host path 选宿主机上你想共享的目录，Name 填一个简短的英文名（比如share、dev），这个 Name 后面会直接对应/mnt/hgfs/<Name>里的目录名。不要用中文名，也不要用带空格的路径，FUSE 挂载对特殊字符处理很别扭。
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| Folder sharing | Always enabled | 选 Enabled until next power off 会导致重启失效 |
| Host path | 纯英文、无空格路径 | 避免 FUSE 挂载解析异常 |
| Name | 简短英文，如 share | 对应 /mnt/hgfs/share |
| Attributes | 按需勾选 Read-only | 只读挂载能避免误删宿主机文件 |
3. 配置共享文件夹之后，为什么 /mnt/hgfs 是空的
这是被问得最多的一个问题，没有之一。设置界面显示已启用，open-vm-tools 也在跑，但ls /mnt/hgfs什么都不显示。这个问题的排查有一条清晰的链路，按顺序走基本都能定位。
3.1 先确认挂载点本身的状态
第一步不是急着挂载，而是看系统当前有没有挂载记录：
mount | grep hgfs df -h | grep hgfs如果两条命令都没输出，说明压根没挂上，需要手动挂。如果mount有输出但ls是空，那可能是宿主机目录本身就空，或者权限问题导致列不出来。
手动挂载的标准命令（新版 Ubuntu）：
sudo mkdir -p /mnt/hgfs sudo /usr/bin/vmhgfs-fuse .host:/ /mnt/hgfs -o subtype=vmhgfs-fuse,allow_other这里.host:/是 VMware 提供的特殊路径，代表宿主机所有共享文件夹的根。挂载之后ls /mnt/hgfs应该能看到你在设置里定义的那个 Name 目录。
3.2 allow_other 这个参数为什么不能省
allow_other是 FUSE 的挂载选项，意思是允许非 root 用户访问挂载点。如果不加这个参数，挂载出来的目录只有 root 能进，普通用户ls会提示 Permission denied。很多人手动挂载时能看到目录但进不去，就是漏了这个参数。
还有几个常用参数值得了解：
uid=和gid=：指定挂载后文件的属主，比如uid=1000,gid=1000对应 Ubuntu 默认的第一个用户。不指定的话，文件属主可能显示为 root 或者一个奇怪的数字 ID。umask=：控制权限掩码，umask=022表示文件默认权限是 644，目录是 755。nonempty：允许挂载到非空目录，一般用不上。
一条更完整的挂载命令长这样：
sudo vmhgfs-fuse .host:/ /mnt/hgfs -o subtype=vmhgfs-fuse,allow_other,uid=1000,gid=1000,umask=0223.3 从宿主机侧反查共享是否真的生效
有时候问题不在虚拟机，而在宿主机。在 Ubuntu 里执行：
vmware-hgfsclient这个命令会列出当前 VMware 识别到的所有共享文件夹名称。如果输出为空，说明宿主机侧根本没把共享传进来，回去检查虚拟机设置里的 Shared Folders 是否真的启用了、是不是在关机状态下配置的。如果输出里有你配的 Name，但/mnt/hgfs下没有，那就是挂载没做，回到 3.1 手动挂载即可。
我自己的经验是，vmware-hgfsclient是排查共享文件夹问题最有效的一把钥匙，比反复看设置界面靠谱得多。只要它列不出名字，后面所有操作都是白费。
4. 让共享文件夹开机自动挂载的三种方案与取舍
手动挂载只是让你当下能用，重启之后就没了。要持久化，常见有三种方案：写进/etc/fstab、用 systemd mount unit、或者写个开机脚本。这三种各有利弊，我实际都试过，下面说说各自的门道。
4.1 写 fstab 的方案以及它为什么不总是可靠
最直觉的做法是把挂载命令写成 fstab 条目：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,uid=1000,gid=1000,umask=022 0 0但这里有个坑：fstab 在系统启动早期执行，那时候 open-vm-tools 的服务可能还没起来，导致挂载失败，系统进入紧急模式或者报错。这也是关键词里“cifs挂载共享文件夹重启后失效”同类问题的根源——时序问题。
要减弱这个影响，可以加nofail和x-systemd.automount选项：
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,uid=1000,gid=1000,umask=022,nofail,x-systemd.automount 0 0nofail表示挂载失败也不阻塞启动，x-systemd.automount表示等到第一次访问这个目录时才真正挂载，这样能避开启动早期的时序竞争。但要注意，automount 第一次访问会有轻微延迟，而且如果一直不访问，用df看不到这个挂载。
提示：改 fstab 之前一定要先备份
sudo cp /etc/fstab /etc/fstab.bak，fstab 写错会导致系统起不来，只能进 recovery 模式修。
4.2 systemd mount unit：更干净但更啰嗦
systemd 的方式是写一个.mount单元文件，比如/etc/systemd/system/mnt-hgfs.mount：
[Unit] Description=VMware Shared Folders After=open-vm-tools.service Requires=open-vm-tools.service [Mount] What=.host:/ Where=/mnt/hgfs Type=fuse.vmhgfs-fuse Options=allow_other,uid=1000,gid=1000,umask=022 [Install] WantedBy=multi-user.target然后sudo systemctl daemon-reload && sudo systemctl enable --now mnt-hgfs.mount。这个方案的最大好处是可以通过After=open-vm-tools.service显式声明依赖，启动顺序可控，不会像 fstab 那样抢跑。缺点是单元文件名字必须和挂载路径严格对应（/mnt/hgfs对应mnt-hgfs.mount），写错了 systemd 会拒绝加载。
4.3 写个简单的开机脚本
如果不想折腾 systemd，也可以在/etc/rc.local或者用户登录脚本里加一行挂载命令。但 rc.local 在新版 systemd 系统里默认不启用，需要自己创建并赋可执行权限，而且同样面临时序问题。我一般把这个方案留给临时调试用，不作为长期方案。
三种方案的对比：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| fstab | 简单直观，一行搞定 | 时序竞争，可能阻塞启动 | 对启动顺序不敏感的环境 |
| systemd mount | 依赖可控，启动顺序精确 | 文件名规则严格 | 生产或长期使用的开发机 |
| rc.local / 脚本 | 灵活，可加自定义逻辑 | 新版默认不启用，时序不可控 | 临时调试 |
我的建议是：如果你只是偶尔用用，fstab 加nofail,x-systemd.automount就够了；如果这台虚拟机是你的主力开发环境，用 systemd mount unit，多写几行换来的稳定性值得。
5. 权限问题的根因：共享文件夹和 Linux 文件权限的错位
“ubuntu共享文件夹权限不够”这个搜索词背后的场景我太熟悉了：挂载成功，目录能进，但往里写文件提示 Permission denied，或者宿主机创建的文件在虚拟机里属主是 root、权限是 755 改不动。这个问题的根因在于，共享文件夹是宿主机文件系统的映射，Linux 端的权限表现由挂载参数决定，而不是由 Linux 的 chmod/chown 决定。你在虚拟机里对一个共享文件执行chmod 777，宿主机那边可能毫无反应，反之亦然。
5.1 uid/gid 参数如何决定文件属主
FUSE 挂载时如果不指定uid和gid，默认所有文件的属主是挂载进程的用户（通常是 root），这就是为什么普通用户看不到写权限。加上uid=1000,gid=1000（Ubuntu 第一个用户的默认 ID）之后，虚拟机里看到的文件属主就变成你自己了，写权限问题基本解决。
先确认自己的 uid 和 gid：
id输出里的uid=1000(yourname) gid=1000(yourname)就是你要填的值。如果系统里有多个用户，按实际需要填。
5.2 宿主机文件权限对虚拟机的影响
这里有个不对称的地方：Linux 作为宿主机时，共享目录里的文件权限会部分透传到虚拟机；Windows 作为宿主机时，NTFS 权限和 Linux 权限模型完全不同，VMware 会做一层转换，通常表现为所有文件都是 777 或者根据 uid/gid 参数统一设置。所以如果你用 Windows 宿主，虚拟机里看到的所有文件权限基本一致，改也改不动，这是正常的，不是你配错了。
反过来，如果你的宿主机是 Linux，共享目录里某个文件权限是 600 且属主不是当前用户，那虚拟机里即使加了uid参数也可能读不了，因为底层文件权限先拦了一道。
5.3 只读挂载与可写挂载的选择
虚拟机设置里每个共享条目的 Attributes 可以勾 Read-only。如果你的场景只是从宿主机往虚拟机传文件（比如同步代码），勾只读更安全，避免虚拟机里误操作删了宿主机的东西。但如果需要双向读写，就别勾，然后在挂载参数里保证uid/gid正确。
提示：一个常见的误解是“共享文件夹里改了文件，宿主机立刻就能看到”。实际是双向实时的，因为底层就是同一个文件系统，不存在同步延迟。但也正因为如此，在虚拟机里删文件会直接删宿主机文件，没有回收站，操作前想清楚。
6. 那些搜索结果里高频出现但容易混淆的相邻问题
围绕共享文件夹这个主题，搜索热词里还挤着一堆相关但不相同的诉求，我挑几个真实遇到过、也最容易被绕进去的说说，免得你按共享文件夹的思路去排错，方向就错了。
6.1 CIFS/SMB 挂载和 VMware 共享文件夹不是一回事
前面提过，但现在展开说。CIFS 挂载是让 Ubuntu 通过网络协议访问宿主机（或其他机器）暴露的共享目录，需要宿主机开 SMB 服务、配置共享、处理用户名密码，虚拟机侧用mount -t cifs挂载。这条路和 VMware 的 HGFS 完全独立，两者可以同时存在，也可以互相替代。
什么时候用哪个？如果宿主机就是本机的 Windows 且你不想折腾 SMB 服务配置，用 VMware 共享文件夹最省事。如果需要跨多台机器访问同一个共享、或者虚拟机要在网络层看到一个独立存储，用 CIFS。搜索结果里“cifs挂载共享文件夹重启后失效”多半是因为 fstab 里写了 CIFS 条目但没加nofail，网络还没起来就挂载失败了，加上nofail,_netdev一般能解决。
6.2 Win11 找不到网络路径与共享文件夹的排查差异
“win11共享文件夹找不到网络路径”这个热词针对的是 Windows 之间的 SMB 共享，和 VMware 共享文件夹是两个层面。如果宿主机是 Win11，虚拟机是 Ubuntu，走 VMware 共享文件夹这条路过完全没有网络路径的概念，不会遇到这个问题。只有当你要用 CIFS 从 Ubuntu 访问 Win11 的 SMB 共享时，才会碰到网络路径、SMB 版本协商、凭据这些问题。排查思路完全不同，别混着找方案。
6.3 不同发行版的 open-vm-tools 包名差异
热词里有“rockylinux共享文件夹”“kali共享文件夹”，说明很多人不只玩 Ubuntu。核心机制是一样的，但包名和默认路径有差别：
| 发行版 | 工具包名 | 挂载工具 | 默认挂载点 |
|---|---|---|---|
| Ubuntu/Debian | open-vm-tools | vmhgfs-fuse | /mnt/hgfs |
| Rocky/Alma/CentOS | open-vm-tools | vmhgfs-fuse | /mnt/hgfs |
| Kali | open-vm-tools | vmhgfs-fuse | /mnt/hgfs |
| 部分旧版 | open-vm-tools | mount -t vmhgfs | /mnt/hgfs |
命名看起来统一，但旧发行版里还残留着内核态的vmhgfs方案，命令和参数都不一样。判断方法还是那句：which vmhgfs-fuse，有就用新方案，没有就看是不是老内核模块方案。
7. 一套可以直接抄的完整落地流程
说了这么多原理和坑，最后把一整套流程串起来，从零到开机可用，你照着走一遍就行。假设宿主机是 Windows，虚拟机是 Ubuntu 22.04 桌面版，目标是共享一个名为D:\code的目录，虚拟机用户 uid=1000。
第一步，确认 Ubuntu 里装好了工具：
sudo apt update sudo apt install open-vm-tools open-vm-tools-desktop -y sudo systemctl enable --now open-vm-tools第二步，关闭虚拟机，在 VMware 里配置共享。Settings → Options → Shared Folders → 选 Always enabled → Add → Host path 填D:\code，Name 填code→ 确定。
第三步，开机后验证识别情况：
vmware-hgfsclient应该输出code。如果没有，回第二步检查。
第四步，手动挂载测试：
sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o subtype=vmhgfs-fuse,allow_other,uid=1000,gid=1000,umask=022 ls /mnt/hgfs/code能看到宿主机目录里的文件就说明通了。
第五步，配置开机自动挂载。推荐用 systemd mount unit：
sudo tee /etc/systemd/system/mnt-hgfs.mount > /dev/null <<'EOF' [Unit] Description=VMware Shared Folders After=open-vm-tools.service Requires=open-vm-tools.service [Mount] What=.host:/ Where=/mnt/hgfs Type=fuse.vmhgfs-fuse Options=allow_other,uid=1000,gid=1000,umask=022 [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now mnt-hgfs.mount第六步，验证持久化：
sudo systemctl status mnt-hgfs.mount df -h | grep hgfs重启虚拟机，再执行一遍上面两条命令，如果还能看到挂载，说明彻底搞定。
整个过程里最容易出错的环节是第二步的配置时机（必须在关机状态）和第四步的挂载参数（漏了allow_other或uid/gid）。把这两个点盯住，其余基本不会出岔子。
最后再分享两个我踩出来的小经验。一个是共享文件夹的 Name 尽量和宿主机目录名错开，比如宿主机叫D:\dev_folder，虚拟机里 Name 就填dev，这样/mnt/hgfs/dev直观好记，也不会因为路径太长在命令里容易打错。另一个是如果你在虚拟机里用 IDE（比如 VS Code、PyCharm）直接打开/mnt/hgfs下的项目，文件监听可能会因为 FUSE 的 inode 行为异常导致自动刷新失灵，遇到这种情况把项目复制到虚拟机本地磁盘再开发，共享目录只做文件传递用，会比硬扛着 FUSE 的性能损耗舒服得多。
