Forest Hu“无法打开虚拟机。获得所有权失败”这个弹窗，应该能排进 VMware Workstation 日常使用里最让人莫名其妙的前三名。明明上一秒电源还开着，下一秒关掉界面再开就报错；有时虚拟机关机后重启一次又恢复正常，有时死活打不开。很多人一搜都是“删除 .lck 锁文件”这一个解法，但照着做完可能发现还是弹同样的错——因为“获得所有权失败”背后其实藏着好几层完全不同的原因，对应的处理方式也不一样。
这篇文章就把 VMware Workstation 里这个报错从原理到排查从头捋一遍，不只告诉你锁文件怎么删，还会说明为什么删了有时候管用、有时候不管用，以及遇到“删除锁文件仍然失败”的时候还能做什么。无论你用 Windows 宿主跑 VMware Workstation，还是在 Linux 或 macOS 宿主上遇到类似问题，都可以按顺序试下来。
1. “获得所有权失败”到底是怎么来的
1.1 先理解一个概念：VMware 的“锁”不是抽象概念
在 VMware Workstation 里，每台虚拟机在运行的时候，配置文件、虚拟磁盘、内存状态文件都会被加上一层“独占所有权”，这层所有权不是注册表里的标记，而是直接落在虚拟机目录里的锁定文件。
你打开虚拟机的时候，VMware Workstation 会先尝试“获得这台虚拟机的所有权”。如果目录里没有其他进程留下的锁，Workstation 就会创建锁并正常启动；如果锁已经存在，且这个锁还被另一个 vmware-vmx.exe 进程占着，那么新打开的实例就没办法再获得所有权，于是弹窗告诉你：“无法打开虚拟机。获得所有权失败。”
所以这句话翻译过来就是：VMware 认为这台虚拟机已经有主人了，当前打开的界面拿不到管理权。
因为这个机制很像一个“令牌”，只要令牌没被拿走，别人就无法使用同一台虚拟机。对于单机软件来说，这个设计是为了防止用户在同一台电脑上开两个 VMware Workstation，分别去启动同一台虚拟机，然后造成虚拟磁盘文件写入冲突。类似 Word 打开一个被其他 Word 实例占用的 .docx 时提示“文件被锁定”，原理上是同一条思路，只不过 VMware 的表达方式会更绕一些。
1.2 “获得所有权失败”与弹窗出现时 VMware 正在做什么
当你双击一台虚拟机并触发这个报错的时候，VMware Workstation 通常会先做这些事：
- 校验虚拟机配置文件（.vmx）路径是否可以访问。
- 检查虚拟机同级目录下是否存在
.lck锁定文件。 - 如果存在锁定文件，尝试和持有该锁的进程进行通信，判断锁是否为“活跃锁”。
- 如果发现锁是“陈旧锁”或当前进程无法控制它，就会报告所有权获取失败。
关键在第三步和第四步之间的区别。如果锁是活跃状态，说明确实有一个 vmware-vmx.exe 在跑这台虚拟机；如果锁是陈旧状态，虽然没有任何进程持有它，但锁文件仍然存在于文件系统里，VMware 依然会认为锁所指的那台虚拟机处于“被打开”状态。
有些用户一遇到这个错误就去目录里删 .lck 文件，这在部分场景下可以解决，但在虚拟机实际还在运行的情况下，这属于强制拆锁，轻则导致正在运行的虚拟机失去响应，重则损坏虚拟机磁盘状态。所以不管网上帖子怎么教你“删锁”，第一步都应该是先确认锁到底是不是残留的。
1.3 多个常见场景的区分
从我实际遇到的案例来看，这个报错主要有四种常见诱导场景：
- 多开冲突：主机上已经开了另一个 VMware Workstation 窗口，并且正在运行同一台虚拟机，再次打开时会直接提示获得所有权失败。
- 异常退出留下的残留锁：虚拟机关机过程中崩溃、宿主机断电、VMware Workstation 被任务管理器强制结束，导致 vmware-vmx.exe 还没来得及清理锁文件就消失了。
- 文件权限不足：虚拟机文件所在目录的 ACL 权限只有某个旧账户或管理员拥有，当前用户没有创建锁文件、修改文件的权限，VMware 无法完成所有权获取，也会报这个错。
- 虚拟机被移动到只读/网络存储位置：在 U 盘、NAS、共享文件夹等场景下，文件系统本身不允许写入锁文件，或者锁文件被其他主机的文件锁机制占住，同样会造成失败。
下面几个章节就按照这些不同场景来分别拆解法子，不要从第一步直接跳到删锁重装。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 别急着删锁文件，先按这个顺序排查
2.1 先确认这台虚拟机是不是真的开着
遇到“获得所有权失败”，先别急着定位虚拟机目录，第一件事是打开任务管理器，确认有没有 vmware-vmx.exe 进程在运行。
vmware-vmx.exe 是 VMware Workstation 真正运行虚拟机的核心进程，注意不是 VMware Workstation 主界面进程。有时候主界面进程崩溃了，但真正运行虚拟机的 vmware-vmx.exe 还残留在系统后台，这时候你去删锁，删掉的其实是正在运行的那台虚拟机的防线，后果相当危险。
更稳妥的方法是看 CPU、内存和命令行参数。
在 Windows 上可以打开任务管理器，切到“详细信息”，找到 vmware-vmx.exe，查看它的“命令行”列（如果没有这一列，在表头右键选择列即可）。命令行里通常会包含虚拟机的 .vmx 配置文件路径。如果命令行里明确写着某台虚机的路径，而报错提示的也是这台虚机，那就说明它确实还在后台运行，这时直接把这个 vmware-vmx.exe 进程正常结束后再打开即可。
如果不习惯用任务管理器看命令行，可以用 PowerShell 执行一条命令：
powershell复制Get-CimInstance Win32_Process -Filter "name='vmware-vmx.exe'" |
Select-Object ProcessId, CommandLine
这条命令会列出所有 vmware-vmx.exe 进程以及它们对应的虚拟机配置文件路径。看到路径就知道是哪台虚拟机抢了所有权。
2.2 挂起与异常断电后容易出现的“残留锁”
排除了进程占用之后，最常见的场景是 VMware Workstation 或虚拟机被杀进程、宿舍断电、休眠唤醒后虚拟机状态不正常，残留锁还在。
如果虚拟机目录里还有 .lck 文件，且没有任何 vmware-vmx.exe 进程，那么这个锁就是典型的陈旧锁，可以安全删除。
有个很容易混淆的判断点：虚拟机的窗口已经关闭了，不代表锁一定会被释放。 VMware Workstation 的设计虽然比较规范，但宿主机强制重启、杀软把 vmware-vmx.exe 拦截、Windows 蓝屏这类意外发生后，锁文件并不会自己消失。而且 Windows 下很多软件的锁本身就是一个目录或文件，进程被杀不会触发文件自动清理，锁就一直留在那里。
所以看到报错时，可以先自己简单画一条线：进程列表里没有对应 vmware-vmx.exe，并且这台虚拟机没有跑在别的主机上，那么剩下的问题基本就是这些锁文件在捣乱。
2.3 锁文件的名称与位置
要清理锁文件，得先知道虚拟机目录里哪些东西是锁。VMware Workstation 的锁文件一般和虚拟机的文件同名，但扩展名不同，常见的有这么几类：
| 文件名规则 | 主要含义 |
|---|---|
| 虚拟机名.vmx.lck | 虚拟机配置级锁定，代表整台虚拟机被某个 VMware 实例“拥有” |
| 虚拟机名.vmdk.lck | 虚拟磁盘被占用，常见于某个磁盘正在被读写 |
| 虚拟机名-Snapshot1.vmdk.lck | 快照差分盘对应的磁盘锁 |
| 虚拟机名.vmem.lck | 内存状态文件被锁定，常见于挂起/休眠相关操作 |
有些版本的 VMware 会把 .lck 做成文件夹，内部还有小文件；有些版本或网盘同步盘里看到的会是 .lck 后缀文件。不管是文件夹还是文件，处理思路一致：在确认没有进程占用的情况下，把它们删除，等 VMware 重新创建。
2.4 完整的锁定文件清理流程
这是我实际验证过比较稳妥的流程，Windows 和 Linux 宿主都会用到。以 Windows 为例：
- 关闭 VMware Workstation 主界面，确保任务管理器里没有任何 vmware-vmx.exe 进程。
- 打开虚拟机文件所在的目录。不知道目录在哪里的话，可以在 VMware 主界面中找到虚拟机名称，右键选择“打开虚拟机目录”，或者在“虚拟机设置”的“选项”页里查看“工作目录”。
- 开启文件资源管理器的“隐藏的项目”显示，确保不会漏掉隐藏锁目录。
- 在目录里全选所有
.lck结尾的文件或文件夹，执行删除。也可以在目录地址栏输入 cmd 后用 PowerShell 删除：
powershell复制Get-ChildItem -Recurse -Force -Filter *.lck |
Remove-Item -Recurse -Force
- 重新打开 VMware Workstation，双击虚拟机，看是否正常启动。
第一次删除时如果提示“文件正在使用中”，说明还有一个隐藏进程占用锁文件，回到第 1 步继续排查，不要使用强制解锁工具强杀。
提示：删除锁文件这个操作完全可以逆，锁文件只是 VMware 运行时的状态标记，不是虚拟机数据的核心文件。它被删除后，VMware 会在下次启动虚拟机时自动重新创建，不会影响虚拟机的磁盘数据和系统内容。但如果虚拟机上设了“开机自动启动”，且某个 VMware 实例仍在后台持有它，这种删除就会破坏正在运行的虚拟机的状态保护。所以还是要先确认进程。
3. 有权限才能“获得所有权”：文件权限与账户问题
3.1 虚拟机文件放在什么位置会直接影响所有权
我遇到过不少案例，情况和锁文件完全无关，纯粹是文件权限导致 VMware 没有办法在虚拟机目录里写入锁文件。这个表现也很有意思——如果你把虚拟机放在一个当前账户没有写权限的目录里，VMware Workstation 可能不会直接报“拒绝访问”，而是笼统地报“无法打开虚拟机。获得所有权失败”。
这其实非常坑人，因为你按经验去删 .lck 文件，可能发现根本没有 .lck 文件，那问题就变成了“明明没有锁，为什么还是失败”。
最典型的几种权限坑：
- 虚拟机文件被放在
C:\Program Files\下，普通用户对该目录只有读取权限，没有写入权限。 - 虚拟机文件是从另一台电脑、另一个账户拷贝过来的，原文件权限只保留了原用户的 ACL，现在的用户没有完全控制权。
- 使用公司电脑时，用户的账户权限受域策略限制，本地管理员权限被阉割，导致 VMware 无法在 D 盘虚拟目录里创建锁文件。
- 虚拟机文件所在磁盘的根目录权限被人为修改过，继承了非常严格的 ACL。
凡是没有 .lck 文件但报所有权失败的场景，优先检查目录权限，永远不会错。
3.2 用 Windows 权限修复解决 ACL 相关问题
处理思路很简单：让当前用户对该虚拟机目录具备“修改”以上的权限，最好给到“完全控制”。因为 VMware 运行虚拟机会创建锁文件、写入内存临时数据、可能需要修改 .vmx 文件，这些都会落在虚拟目录里。
如果虚拟机目录里已经有 .lck 文件，但删除时提示没有权限，也可以在资源管理器里先修改权限再删。
比较推荐的命令行方式是直接用管理员身份打开一个 PowerShell 或 cmd，然后执行：
cmd复制takeown /f "D:\Virtual Machines\Win10" /r /d y
icacls "D:\Virtual Machines\Win10" /grant "%USERNAME%:(OI)(CI)F" /T
takeown 是把目录的所有权拿回来，icacls 是给当前用户授予包含继承的完全控制权。执行完成后，再回到 VMware Workstation 里重新打开虚拟机。
要注意的一点是：很多用户只改了虚拟机目录的权限，却没有改磁盘文件本身的权限。虽然虚拟目录包含磁盘文件，ACL 默认会继承，但如果是手动复制出来的文件，没有继承父目录权限，就仍然可能失败。保险的做法是对整个虚拟机目录执行递归授权。
改完权限后，再删除残留锁文件。很多用户改完权限后虚拟机还是打不开，原因就在于锁文件在权限修改前已经无法写入或删除，必须把这个遗留问题一并解决。
3.3 非 Windows 宿主环境下的权限问题
如果你用的是 Linux 宿主上的 VMware Workstation，会遇到略有区别的权限问题。
比较常见的是用 root 用户创建或解压了虚拟机文件夹，然后又用普通用户去启动 VMware Workstation。这时普通用户没有虚拟目录的写权限，同样无法创建锁文件，从而报所有权失败。
处理方式是把虚拟机目录的所有者改成当前用户：
bash复制sudo chown -R $USER:$USER ~/vmware/虚拟机文件夹
sudo chmod -R u+rwx ~/vmware/虚拟机文件夹
之后在 VMware Workstation 里重新打开虚拟机。如果在 /tmp 或没有正确挂载 exec 权限的磁盘上遇到问题，还需要看看挂载参数是否带了 noexec 之类限制。
macOS 宿主上的 VMware Fusion 逻辑类似，只要客户机文件被放在了没有写权限的系统卷或网络卷，一样会出现所有权相关问题。处理方法就是在 Finder 的“显示简介”里给当前用户“读与写”权限，并把整个虚拟机文件夹复制到本机用户目录下手动处理，别直接在只读安装介质里双击打开。
4. 别漏掉快照、共享磁盘和 vmem 残留锁
4.1 快照锁文件：不要只盯着 .vmx.lck
很多人在删锁文件时习惯只删 .vmx.lck 这个文件夹，结果重新打开依然报错。原因很简单：如果你这台虚拟机创建过快照，而且系统异常退出时锁在了快照对应的差分磁盘上，那么只删配置锁根本没用，程序在尝试读取快照差分盘时依旧会发现磁盘被占用。
一台做过快照的 Windows 虚拟机，目录里除了主磁盘 Windows.vmdk，通常还会看到：
Windows-Snapshot1.vmdkWindows-Snapshot2.vmdkWindows.vmsdWindows-Snapshot1.vmsn
对应的磁盘锁就会以 Windows-Snapshot1.vmdk.lck 这样的名字存在。如果在快照目录里看到了带 .lck 的文件，确认没有进程占用后，把整个虚拟机目录下所有 .lck 文件一起清掉，不要只关注主 vmx 的锁。
我自己遇到的一次情况是：虚拟机在创建快照过程中宿主蓝屏，重启后开机，弹出“获得所有权失败”。找来找去只有一个名为 Windows-Snapshot3.vmdk.lck 的目录存在。删掉它之后，虚拟机就能正常启动，而主配置锁根本都没有出现。
4.2 多个虚拟机共用同一块虚拟磁盘的“磁盘锁”
有些用户图省事，创建新虚拟机时选了“复用已有虚拟磁盘文件”，也就是把同一块 vmdk 作为两台虚拟机的系统盘来启动。正常情况下这种做法 VMware 是禁止的，但如果绕开检查硬加载，就可能在打开第二台虚拟机时遭遇所有权失败。
这种场景下你可能看到第一台虚拟机并没有运行，目录里却残留着 .vmdk.lck。清理前一定要想清楚：这个 vmdk 是不是也被其他虚拟机引用着？ 如果只是上一次非法退出留下的锁，清理后没问题；但如果你把同一块磁盘同时放在两台虚拟机里，下次打开另一台虚拟机可能还会生成新的 .vmdk.lck。
遇到这种“共享磁盘”的需求，正确操作不是删锁抢盘，而是使用独立的磁盘克隆，或者在同一台虚拟机里通过“添加硬盘”挂载副盘，避免同一磁盘文件被两个虚拟机实例同时打开。
4.3 挂起/休眠状态锁与 .vmem.lck
.vmem.lck 是很容易被忽略的一类锁。当虚拟机处于挂起（Suspend）状态时，VMware 会创建一个 .vmem 文件来保存内存内容，同时创建对应的 .vmem.lck 来防止它被误改。如果虚拟机在挂起恢复过程中出现异常，比如休眠后 VM 窗口卡死，强制关机重启后这个 .vmem.lck 就有可能残留下来。
此时 VMware Workstation 会认为虚拟机还处于“被挂起/正在恢复”的不稳定状态，于是你又看到了获得所有权失败。
处理方式和普通锁文件一样，删掉即可。但删掉 .vmem.lck 意味着 VMware 可能不再信任之前保存的内存状态。如果虚拟机里还有没保存的临时工作，建议先备份整个虚拟机文件夹（至少备份 .vmem 和 .vmss 文件），再删除锁文件启动。因为有些半损坏状态一旦被强制启动，Windows 客户机可能要花很长时间做磁盘检查。
提示：在虚拟机目录下用
dir *.lck或ls -la | grep lck全量列一遍，比只盯着某个锁文件更靠谱。锁文件可能分布在主配置目录、工作目录、快照子目录等多个位置，遗漏任何一个，启动流程都会在同一环节卡住。
5. 顽固情况：删除锁文件后仍然报错怎么办
5.1 从 VMware 主界面移除并重新添加虚拟机
删除锁文件后依然报错，说明问题大概率不在文件锁，而是在 VMware Workstation 自己维护的“虚拟机库记录”上。
VMware Workstation 主界面左侧的“库”列表，记录了你添加过哪些虚拟机。这些记录存放在 inventory.vmls 文件里。如果某个虚拟机在目录层面已经被移动、删除或手动编辑过配置，而库里的记录还指向旧路径，就可能出现状态不匹配，导致 VMware 在获得所有权时失败。
尝试以下顺序：
- 在 VMware Workstation 左侧库中，右键报错虚拟机，选择“从库中移除”。
- 如果虚拟机还在左侧栏中显示，就选择“移除”，这个操作只是删掉库中的快捷记录，不会删除实际虚拟机文件。
- 回到“文件”菜单，选择“打开虚拟机”，手动导航到刚才那个
.vmx文件位置重新添加。 - 重新双击启动，看看是否恢复正常。
这个方法有时候也能顺带解决“虚拟机名称变成灰色”“配置信息显示不正确”等问题。
5.2 inventory.vmls 索引异常与修复思路
如果移除再添加还不行，可以停掉 VMware Workstation，处理一下 inventory.vmls。
这个文件常见路径在：
text复制C:\ProgramData\VMware\VMware Workstation\inventory.vmls
它不是虚拟机的核心数据，而是 VMware Workstation 用来记录“库里有哪些虚拟机”的索引文件。默认路径下该文件的修改可能因为访问权限失败，尤其是某些系统盘目录权限被加固过的机器。但一般情况下不需要直接删除整个文件，先尝试备份后把它改名，让 VMware Workstation 重新生成一个全新的索引文件。
具体操作：
- 关闭 VMware Workstation。
- 打开
C:\ProgramData\VMware\VMware Workstation\，找到inventory.vmls。 - 把文件复制一份到桌面备份，然后把原文件改名成
inventory.vmls.bak。 - 重新启动 VMware Workstation，重新手动添加报错的虚拟机，再尝试启动。
这样做相当于让 Workstation 忘掉所有旧的库记录，从零开始创建一个新的列表。如果你的 VMware 库里有很多重要虚拟机，不建议一口气直接删文件，改名备份是最稳妥的方式，等确认一切都正常后，再把备份文件移走。
5.3 虚拟机目录的只读属性和迁移过程残留
还有一类顽固报错和“复制虚拟机”有关。用户把虚拟机从移动硬盘拷贝到本地时，目录可能带有“只读”属性。Windows 文件夹的只读属性不会直接阻止 VMware 打开虚拟机，但如果该属性影响到了虚拟机目录下所有文件的写入，VMware 就无法创建锁。
用文件资源管理器把目录只读属性去掉只是第一步，更可靠的方式还是用命令行递归去除：
cmd复制attrib -R "D:\Virtual Machines\Win10" /S /D
如果虚拟机是从其他电脑压缩包解压过来的，我建议在解压完成后再对整个虚拟机目录执行一次 attrib 命令，避免个别文件在拷贝时继承了源端的只读状态。
还有一种情况和杀毒软件有关。部分安全软件会后台扫描新建的 .vmdk 文件，甚至短暂锁定它。如果你发现虚拟机能正常打开，但每次运行几分钟后提示所有权失败，可以先暂时关掉杀毒软件的“实时防护”或“文件夹保护”，把虚拟机目录加入信任列表再打开。
5.4 重置 VMware Workstation 自身状态之后再重装
上面的手段如果都试完了，问题还是存在，那就要开始怀疑 VMware Workstation 自身的运行时状态异常了。
这时候我建议做一次相对彻底的清理重装，但这里的“清理重装”不是简单卸载后装新版，而是要把 Workstation 的缓存文件和残留服务一并处理干净。重点步骤如下：
- 关闭 VMware Workstation，退出托盘程序。
- 在 Windows 服务列表里检查 VMware 相关服务（例如 VMware Authorization Service），如果还在运行，先停止。
- 使用官方卸载程序或第三方卸载工具完整卸载 VMware Workstation。
- 检查 install 目录和用户目录下是否还残留 VMware 配置。
- 重新安装最新版 VMware Workstation，安装时以管理员身份运行。
重装并不能直接恢复虚拟机的启动，它修复的是 Workstation 主程序对锁文件、目录权限、进程服务的处理逻辑。如果问题出在 Workstation 程序本身，例如版本升级留下了异常权限，这种处理后基本都能恢复。
6. 处理完之后的验证方法以及我习惯的防呆操作
每次处理完这种报错后，我一般不会马上关掉窗口去干别的，而是会多验证一遍，防止问题刚解决又复发。
验证的步骤很简单：先正常关闭虚拟机，等虚拟机的电源状态完全变为“已关闭”后，再启动一次，观察是否还弹“获得所有权失败”。如果第二次启动也正常，说明之前残留的锁被清理干净了。然后我会再执行一次完整关机、冷启动，模拟最常见的日常操作，确保不是偶然恢复。
我还养成了一个比较“土”但有效的习惯：每次在虚拟机里准备关机前，会先留意 VMware Workstation 底部状态栏里有没有显示“正在关闭”或“正在挂起”，绝不在这个过程中强制退出主界面。很多时候我们以为是 VMware 卡死，其实它只是正在保存虚拟机状态，如果这时候去任务管理器结束进程，下一次就会留下各种 .lck 文件。
对于经常需要维护多台虚拟机的场景，我还有一个建议：在给虚拟机命名时，尽量把路径和名称固定下来，不要频繁移动或更改虚拟机文件夹的名字。因为 VMware Workstation 记录虚拟机路径的方式比较持久，移动目录后哪怕手动删了库记录，也可能在配置级锁上留下旧路径信息。路径稳定了，这类“所有权失败”问题出现的概率会小很多。
万一真遇到怎么删锁都没用的极端情况，也别慌，先备份整个虚拟机目录，尤其是 .vmdk 磁盘文件和 .vmx 配置文件。虚拟机本身的数据都在这两个文件里，备份后即使反复处理失败，也有退路。实际处理中，绝大部分所有权失败并没有损坏虚拟磁盘数据，只要能进目录删锁，问题基本都能在十分钟内解决。真正需要重装 VMware Workstation 的反而属于少数情况，不必一上来就走到那一步。