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-toolsVMware 检测不到工具就不给配二是虚拟机处于挂起状态。正确做法是先关机装好 open-vm-tools再关机状态下配置共享文件夹开机后自动生效。配置的时候选 “Always enabled”然后 Add 一个条目Host path 选宿主机上你想共享的目录Name 填一个简短的英文名比如share、dev这个 Name 后面会直接对应/mnt/hgfs/Name里的目录名。不要用中文名也不要用带空格的路径FUSE 挂载对特殊字符处理很别扭。配置项推荐值说明Folder sharingAlways enabled选 Enabled until next power off 会导致重启失效Host path纯英文、无空格路径避免 FUSE 挂载解析异常Name简短英文如 share对应 /mnt/hgfs/shareAttributes按需勾选 Read-only只读挂载能避免误删宿主机文件3. 配置共享文件夹之后为什么 /mnt/hgfs 是空的这是被问得最多的一个问题没有之一。设置界面显示已启用open-vm-tools 也在跑但ls /mnt/hgfs什么都不显示。这个问题的排查有一条清晰的链路按顺序走基本都能定位。3.1 先确认挂载点本身的状态第一步不是急着挂载而是看系统当前有没有挂载记录mount | grep hgfs df -h | grep hgfs如果两条命令都没输出说明压根没挂上需要手动挂。如果mount有输出但ls是空那可能是宿主机目录本身就空或者权限问题导致列不出来。手动挂载的标准命令新版 Ubuntusudo mkdir -p /mnt/hgfs sudo /usr/bin/vmhgfs-fuse .host:/ /mnt/hgfs -o subtypevmhgfs-fuse,allow_other这里.host:/是 VMware 提供的特殊路径代表宿主机所有共享文件夹的根。挂载之后ls /mnt/hgfs应该能看到你在设置里定义的那个 Name 目录。3.2 allow_other 这个参数为什么不能省allow_other是 FUSE 的挂载选项意思是允许非 root 用户访问挂载点。如果不加这个参数挂载出来的目录只有 root 能进普通用户ls会提示 Permission denied。很多人手动挂载时能看到目录但进不去就是漏了这个参数。还有几个常用参数值得了解uid和gid指定挂载后文件的属主比如uid1000,gid1000对应 Ubuntu 默认的第一个用户。不指定的话文件属主可能显示为 root 或者一个奇怪的数字 ID。umask控制权限掩码umask022表示文件默认权限是 644目录是 755。nonempty允许挂载到非空目录一般用不上。一条更完整的挂载命令长这样sudo vmhgfs-fuse .host:/ /mnt/hgfs -o subtypevmhgfs-fuse,allow_other,uid1000,gid1000,umask0223.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,uid1000,gid1000,umask022 0 0但这里有个坑fstab 在系统启动早期执行那时候 open-vm-tools 的服务可能还没起来导致挂载失败系统进入紧急模式或者报错。这也是关键词里“cifs挂载共享文件夹重启后失效”同类问题的根源——时序问题。要减弱这个影响可以加nofail和x-systemd.automount选项.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,uid1000,gid1000,umask022,nofail,x-systemd.automount 0 0nofail表示挂载失败也不阻塞启动x-systemd.automount表示等到第一次访问这个目录时才真正挂载这样能避开启动早期的时序竞争。但要注意automount 第一次访问会有轻微延迟而且如果一直不访问用df看不到这个挂载。提示改 fstab 之前一定要先备份sudo cp /etc/fstab /etc/fstab.bakfstab 写错会导致系统起不来只能进 recovery 模式修。4.2 systemd mount unit更干净但更啰嗦systemd 的方式是写一个.mount单元文件比如/etc/systemd/system/mnt-hgfs.mount[Unit] DescriptionVMware Shared Folders Afteropen-vm-tools.service Requiresopen-vm-tools.service [Mount] What.host:/ Where/mnt/hgfs Typefuse.vmhgfs-fuse Optionsallow_other,uid1000,gid1000,umask022 [Install] WantedBymulti-user.target然后sudo systemctl daemon-reload sudo systemctl enable --now mnt-hgfs.mount。这个方案的最大好处是可以通过Afteropen-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这就是为什么普通用户看不到写权限。加上uid1000,gid1000Ubuntu 第一个用户的默认 ID之后虚拟机里看到的文件属主就变成你自己了写权限问题基本解决。先确认自己的 uid 和 gidid输出里的uid1000(yourname) gid1000(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/Debianopen-vm-toolsvmhgfs-fuse/mnt/hgfsRocky/Alma/CentOSopen-vm-toolsvmhgfs-fuse/mnt/hgfsKaliopen-vm-toolsvmhgfs-fuse/mnt/hgfs部分旧版open-vm-toolsmount -t vmhgfs/mnt/hgfs命名看起来统一但旧发行版里还残留着内核态的vmhgfs方案命令和参数都不一样。判断方法还是那句which vmhgfs-fuse有就用新方案没有就看是不是老内核模块方案。7. 一套可以直接抄的完整落地流程说了这么多原理和坑最后把一整套流程串起来从零到开机可用你照着走一遍就行。假设宿主机是 Windows虚拟机是 Ubuntu 22.04 桌面版目标是共享一个名为D:\code的目录虚拟机用户 uid1000。第一步确认 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:\codeName 填code→ 确定。第三步开机后验证识别情况vmware-hgfsclient应该输出code。如果没有回第二步检查。第四步手动挂载测试sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o subtypevmhgfs-fuse,allow_other,uid1000,gid1000,umask022 ls /mnt/hgfs/code能看到宿主机目录里的文件就说明通了。第五步配置开机自动挂载。推荐用 systemd mount unitsudo tee /etc/systemd/system/mnt-hgfs.mount /dev/null EOF [Unit] DescriptionVMware Shared Folders Afteropen-vm-tools.service Requiresopen-vm-tools.service [Mount] What.host:/ Where/mnt/hgfs Typefuse.vmhgfs-fuse Optionsallow_other,uid1000,gid1000,umask022 [Install] WantedBymulti-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 的性能损耗舒服得多。
VMware Ubuntu共享文件夹配置、权限与开机自动挂载全解
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-toolsVMware 检测不到工具就不给配二是虚拟机处于挂起状态。正确做法是先关机装好 open-vm-tools再关机状态下配置共享文件夹开机后自动生效。配置的时候选 “Always enabled”然后 Add 一个条目Host path 选宿主机上你想共享的目录Name 填一个简短的英文名比如share、dev这个 Name 后面会直接对应/mnt/hgfs/Name里的目录名。不要用中文名也不要用带空格的路径FUSE 挂载对特殊字符处理很别扭。配置项推荐值说明Folder sharingAlways enabled选 Enabled until next power off 会导致重启失效Host path纯英文、无空格路径避免 FUSE 挂载解析异常Name简短英文如 share对应 /mnt/hgfs/shareAttributes按需勾选 Read-only只读挂载能避免误删宿主机文件3. 配置共享文件夹之后为什么 /mnt/hgfs 是空的这是被问得最多的一个问题没有之一。设置界面显示已启用open-vm-tools 也在跑但ls /mnt/hgfs什么都不显示。这个问题的排查有一条清晰的链路按顺序走基本都能定位。3.1 先确认挂载点本身的状态第一步不是急着挂载而是看系统当前有没有挂载记录mount | grep hgfs df -h | grep hgfs如果两条命令都没输出说明压根没挂上需要手动挂。如果mount有输出但ls是空那可能是宿主机目录本身就空或者权限问题导致列不出来。手动挂载的标准命令新版 Ubuntusudo mkdir -p /mnt/hgfs sudo /usr/bin/vmhgfs-fuse .host:/ /mnt/hgfs -o subtypevmhgfs-fuse,allow_other这里.host:/是 VMware 提供的特殊路径代表宿主机所有共享文件夹的根。挂载之后ls /mnt/hgfs应该能看到你在设置里定义的那个 Name 目录。3.2 allow_other 这个参数为什么不能省allow_other是 FUSE 的挂载选项意思是允许非 root 用户访问挂载点。如果不加这个参数挂载出来的目录只有 root 能进普通用户ls会提示 Permission denied。很多人手动挂载时能看到目录但进不去就是漏了这个参数。还有几个常用参数值得了解uid和gid指定挂载后文件的属主比如uid1000,gid1000对应 Ubuntu 默认的第一个用户。不指定的话文件属主可能显示为 root 或者一个奇怪的数字 ID。umask控制权限掩码umask022表示文件默认权限是 644目录是 755。nonempty允许挂载到非空目录一般用不上。一条更完整的挂载命令长这样sudo vmhgfs-fuse .host:/ /mnt/hgfs -o subtypevmhgfs-fuse,allow_other,uid1000,gid1000,umask0223.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,uid1000,gid1000,umask022 0 0但这里有个坑fstab 在系统启动早期执行那时候 open-vm-tools 的服务可能还没起来导致挂载失败系统进入紧急模式或者报错。这也是关键词里“cifs挂载共享文件夹重启后失效”同类问题的根源——时序问题。要减弱这个影响可以加nofail和x-systemd.automount选项.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,uid1000,gid1000,umask022,nofail,x-systemd.automount 0 0nofail表示挂载失败也不阻塞启动x-systemd.automount表示等到第一次访问这个目录时才真正挂载这样能避开启动早期的时序竞争。但要注意automount 第一次访问会有轻微延迟而且如果一直不访问用df看不到这个挂载。提示改 fstab 之前一定要先备份sudo cp /etc/fstab /etc/fstab.bakfstab 写错会导致系统起不来只能进 recovery 模式修。4.2 systemd mount unit更干净但更啰嗦systemd 的方式是写一个.mount单元文件比如/etc/systemd/system/mnt-hgfs.mount[Unit] DescriptionVMware Shared Folders Afteropen-vm-tools.service Requiresopen-vm-tools.service [Mount] What.host:/ Where/mnt/hgfs Typefuse.vmhgfs-fuse Optionsallow_other,uid1000,gid1000,umask022 [Install] WantedBymulti-user.target然后sudo systemctl daemon-reload sudo systemctl enable --now mnt-hgfs.mount。这个方案的最大好处是可以通过Afteropen-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这就是为什么普通用户看不到写权限。加上uid1000,gid1000Ubuntu 第一个用户的默认 ID之后虚拟机里看到的文件属主就变成你自己了写权限问题基本解决。先确认自己的 uid 和 gidid输出里的uid1000(yourname) gid1000(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/Debianopen-vm-toolsvmhgfs-fuse/mnt/hgfsRocky/Alma/CentOSopen-vm-toolsvmhgfs-fuse/mnt/hgfsKaliopen-vm-toolsvmhgfs-fuse/mnt/hgfs部分旧版open-vm-toolsmount -t vmhgfs/mnt/hgfs命名看起来统一但旧发行版里还残留着内核态的vmhgfs方案命令和参数都不一样。判断方法还是那句which vmhgfs-fuse有就用新方案没有就看是不是老内核模块方案。7. 一套可以直接抄的完整落地流程说了这么多原理和坑最后把一整套流程串起来从零到开机可用你照着走一遍就行。假设宿主机是 Windows虚拟机是 Ubuntu 22.04 桌面版目标是共享一个名为D:\code的目录虚拟机用户 uid1000。第一步确认 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:\codeName 填code→ 确定。第三步开机后验证识别情况vmware-hgfsclient应该输出code。如果没有回第二步检查。第四步手动挂载测试sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o subtypevmhgfs-fuse,allow_other,uid1000,gid1000,umask022 ls /mnt/hgfs/code能看到宿主机目录里的文件就说明通了。第五步配置开机自动挂载。推荐用 systemd mount unitsudo tee /etc/systemd/system/mnt-hgfs.mount /dev/null EOF [Unit] DescriptionVMware Shared Folders Afteropen-vm-tools.service Requiresopen-vm-tools.service [Mount] What.host:/ Where/mnt/hgfs Typefuse.vmhgfs-fuse Optionsallow_other,uid1000,gid1000,umask022 [Install] WantedBymulti-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 的性能损耗舒服得多。
