虚拟机共享文件夹访问不了，先别急着重装系统，按“VMware Tools状态→网络连通性→共享权限配置”的顺序排查，多数情况下能在十分钟内解决。
先搞清楚是“看不见”还是“进不去”
很多朋友一遇到虚拟机共享出错，第一反应就是重新安装VMware Tools或者换一种共享方式，但实际上，业内专家指出，相当一部分共享故障的根源在于“服务没起来”或“IP地址变了”,而不是虚拟机本身坏了。
共享文件访问卡住时，先看虚拟机右下角任务栏的VMware Tools图标是否常驻，如果图标带黄色感叹号，说明Tools没装好或服务未启动，这会导致共享目录根本无法挂载，另一个常见场景是：宿主机重启后，虚拟机IP从192.168.1.100变成了192.168.1.150，配合的是NAT模式，而你用的是桥接物理网卡的固定地址去访问，自然一访问就报错，把这两个基础项排干净，再往下走权限的检查,逻辑上才顺。
第一招：修复VMware Tools与挂载状态
确认Tools是否处于“正在运行”状态
在Windows虚拟机里，按下Win+R输入services.msc，找到VMware Tools服务，如果状态不是“正在运行”，右键→启动，如果是Linux虚拟机,在终端执行：
systemctl status vmware-tools
如果显示inactive,执行：
systemctl start vmware-tools
移除并重建共享文件夹
关闭虚拟机，在VMware Workstation中右键虚拟机→设置→选项→共享文件夹。
- 选择“已禁用”,点击确定。
- 重新打开设置，选择“总是启用”。
- 勾选“在Windows客户机中映射为网络驱动器”。
再次启动虚拟机，这次进入系统后，注意观察是否有弹窗提示“网络驱动器已连接”，如果还是没有看到共享盘符，直接在虚拟机内按Win+R输入\.hostShared Folders回车,手动触发挂载。
针对VirtualBox用户的特殊处理
VirtualBox的共享文件夹机制和VMware不同，它强依赖增强功能（Guest Additions），如果共享提示“权限不足”或“找不到路径”，先卸载现有增强包，重启后重新安装，安装时需注意：在Windows虚拟机中右键“以管理员身份运行”，但在Linux虚拟机中需要使用
sudo ./VBoxLinuxAdditions.run,安装完再校验共享文件夹是否挂载成功。
第二招：排查网络与IP变动导致的“找不到网络路径”
了解NAT模式与桥接模式对共享访问的影响
虚拟机共享中的网络访问问题，通常和网络模式混淆有关，行业共识认为，NAT模式下宿主机与虚拟机之间默认有隔离策略，而桥接模式更像局域网内的两台独立电脑。
如果你原来用的是桥接模式，但虚拟机IP是通过DHCP动态获取，宿主机重启后IP变了，之前保存的映射地址自然失效，此时无需重启服务,只需要：
- 在虚拟机内执行
ipconfig（Windows）或ip addr（Linux）。 - 确认当前IP地址。
- 在宿主机上重新映射网络驱动器，或直接访问
\<新IP>sharename。
如何让共享更稳定：改用固定IP
想让虚拟机共享文件夹长期稳定，建议把虚拟机的IP地址设置为固定IP,操作路径如下：
- Windows虚拟机：控制面板→网络和共享中心→更改适配器设置→右键以太网→属性→IPv4,手动填入和宿主机同一网段的地址。
- Linux虚拟机：编辑
/etc/netplan/01-netcfg.yaml或/etc/sysconfig/network-scripts/ifcfg-ens33,设置静态IP。
防火墙端口干扰
共享文件夹依赖445端口（SMB协议），很多安全软件或Windows防火墙默认会拦截来自虚拟机的SMB请求,排查方法很简单：
在宿主机上打开命令提示符,输入：
ping <虚拟机IP>
能够ping通但共享报错“找不到网络路径”，多半是防火墙问题，此时在虚拟机的Windows防火墙中，勾选“文件和打印机共享”为允许通过即可，在Linux虚拟机中,执行：
sudo firewall-cmd --permanent --add-service=samba sudo firewall-cmd --reload
SMB协议版本不一致怎么办
老旧的Linux虚拟机访问Windows 10/11的共享文件夹时，容易出现“协议协商失败”，这是因为Windows默认禁用SMBv1，解决办法不是强行开启SMBv1（安全隐患极大），而是调整Linux客户端的挂载参数,执行：
sudo mount -t cifs //192.168.1.10/share /mnt -o username=user,vers=3.0
vers=3.0
强制使用SMB 3.0协议，能规避大部分兼容性问题，Windows虚拟机访问Linux共享（Samba）时也同理，先确认Samba配置文件/etc/samba/smb.conf中的server min protocol没有被设成NT1（SMB1）。
第三招：共享权限与密码认证失败的高级排查
解决“用户密码错误”但密码明明是正确的情况
这是Windows虚拟机访问Samba共享时的高频故障，Samba服务默认基于系统用户认证，但如果你用的是群晖或威联通NAS上的共享文件夹，可能开启了“仅允许SMB3加密连接”选项，加上Windows虚拟机的“来宾访问”策略冲突,就会造成密码正确却登不进的情况。
Windows虚拟机访问Samba共享的步骤如下：
- 打开控制面板→凭据管理器→Windows凭据→添加Windows凭据。
- 输入Samba服务器的IP、用户名、密码。
- 重启虚拟机后重新访问
\<Samba服务器IP>share。
文件夹权限叠加规则
宿主机的共享文件夹通常有“共享权限”和“NTFS权限”两套规则，如果共享权限允许“完全控制”，但NTFS权限只给了“只读”，最终以两者中最严格的权限为准，虚拟机内只读不可写？改宿主机目标文件夹的“安全”标签页，给Everyone或对应账户添加“修改”权限。
不能修改宿主机权限的替代方案
有些特殊场景下，宿主机（比如公司电脑）的文件夹权限不允许修改，这时可以换个思路，在宿主机上创建一个专门用于共享的目录，把需要访问的文件复制进去，并为这个目录单独设置共享权限。不直接共享系统盘或用户目录，能规避大部分权限冲突,这也是Windows专业用户在主机无法访问虚拟机时的做法。
共享文件夹访问权限正常但写入速度极慢
这种问题经常被误判为共享故障，当你在虚拟机中解压一个大文件夹到共享目录时，速度可能只有几MB/s，这并不一定是配置问题，而是VMware Workstation的共享文件夹机制在复制大量小块文件时性能较差，遇到这种情况，改用Samba或Windows自带的网络共享（在虚拟机内连接宿主机的某个文件夹）通常能得到大幅提升，性能与易用性之间的取舍,需要根据实际场景权衡。
常见问题解答：虚拟共享文件打不开
虚拟机共享文件夹挂载成功后，重启虚拟机关闭又失效了，怎么解决？
在Windows虚拟机中，先检查是否存在域组策略限制了网络驱动器的重新连接，可以打开命令行输入gpresult /v查看，如果策略没限制，手动在启动文件夹中放置一个net use Z: \.hostShared Folders /persistent:yes的批处理文件，开机时会自动重建映射，如果是Linux虚拟机，在/etc/fstab中添加挂载条目，并在挂载参数中加上_netdev,防止因网络未就绪导致的挂载错误。
使用NAT模式的虚拟机，为什么宿主机能访问虚拟机共享，但其他电脑不行？
NAT模式下虚拟机对外部设备不可见，宿主机能访问是因为VMware虚拟网卡直连，但其他物理机想访问这台虚拟机，需要将其网络模式改为“桥接模式”，并确保虚拟机和物理机处于同一局域网，如果共享权限已经配好，修改完网络模式后虚拟机IP通常会变,需同步调整访问地址。
VMware Tools显示已安装但没有共享选项，如何触发重新挂载？
这种状况下无需卸载Tools，进入虚拟机所在虚拟机的目录，找到.vmx配置文件，用记事本编辑，删除共享文件夹相关的条目（sharedFolder开头的行），保存后重新打开虚拟机设置，手动添加一次共享即可，VMware Tools的安装包默认在虚拟机的光驱中，挂载对应ISO文件后运行setup.exe执行修复安装，也能同步恢复共享状态，Linux虚拟机则执行vmware-config-tools.pl重新配置共享目录缓存。
共享文件夹出错的修复逻辑本质上是“由内到外”的排查过程：先确认客户机系统内的组件工作正常，再检查网络联通性，最后才是权限和策略限制，按照上述三个维度逐层处理，绝大多数场景下的文件无法访问问题都能得到缓解，如果三个方向都排查过仍无法解决，有一个相对省力的兜底方案：在虚拟机内直接使用scp或rsync命令，通过SSH协议进行文件传输，这种方式完全绕过共享文件夹机制，不依赖SMB、不依赖Tools，仅需虚拟机开启SSH服务，配合Windows 10及以上系统自带的OpenSSH客户端，在命令行中输入scp rstudio_user@虚拟IP:/home/user/文件名 .就能把文件拉取到宿主机，工具是死的，思路是活的,目标是文件能流动起来。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/632494.html
