“Windows is hibernated, refused to mount” 表示 Windows 并没有真正关机。它把内存状态保存到了 C 盘的 hiberfil.sys,仍然认为该分区归自己所有,因此 Linux 不会向其写入。最安全的修复只需要在 Windows 中操作约 30 秒;网上流传的许多 Linux 快捷方案要么无效,要么会在 Windows 即将恢复的卷上悄悄写入数据。
为了避免靠猜测判断方案是否可靠,本文实际构造并复现了问题。实验环境是一台 Windows Server 2025 虚拟机,包含 C: 系统盘和 D: 数据盘;机器被休眠四次,每次都将磁盘挂载到 Ubuntu 26.04,逐一尝试常见修复方法,随后启动 Windows 检查最终状态。全部测试于 2026 年 10 月完成,使用内核 7.0 和 ntfs-3g 2022.10.3。
检查 Windows 是否处于休眠状态
首先找到 Windows 分区。典型安装包含一个小型 EFI 分区、一个没有文件系统的 16 MB 保留分区、较大的 C: 分区以及恢复分区;独立的第二块数据盘还会显示自己的 NTFS 分区:
lsblk -o NAME,SIZE,FSTYPE,LABEL /dev/sda /dev/sdb
实验机上的 C: 是 sda3,卷标为 Windows;D: 数据盘是 sdb2。如果 Windows 分区显示为 BitLocker 而不是 ntfs,说明卷已加密;在解锁之前,下文方法都不适用。
NAME SIZE FSTYPE LABEL
sda 64G
├─sda1 100M vfat EFI
├─sda2 16M
├─sda3 63.1G ntfs Windows
└─sda4 789M ntfs
sdb 8G
├─sdb1 16M
└─sdb2 8G ntfs DATA
尝试任何挂载前,先让 ntfs-3g 判断分区能否安全写入。这个探测工具只打开卷而不挂载,退出码可直接表明状态,不依赖解析提示文本:
sudo ntfs-3g.probe --readwrite /dev/sda3; echo "probe rc=$?"
sudo ntfs-3g.probe --readwrite /dev/sdb2; echo "probe rc=$?"
退出码 14 并显示休眠提示,说明分区仍由 Windows 控制;退出码 15 说明没有正常卸载。退出码 0 表示 ntfs-3g 可将其以读写方式挂载,但对数据盘而言,这个结果可能具有误导性;后文 D: 盘的实验会说明原因:
Windows is hibernated, refused to mount.
probe rc=14
probe rc=0
如果没有 ntfs-3g.probe,安装 ntfs-3g 软件包。Ubuntu 26.04 镜像默认已经包含;Debian、Fedora 和 Arch 的包名相同。Fedora 将下文使用的 ntfsfix 与 ntfsinfo 放在单独的 ntfsprogs 包中。
理解两种 NTFS 驱动的差异
Linux 有两种 NTFS 驱动,失败行为差异很大,这就是论坛答案经常互相矛盾的原因。在 Ubuntu 26.04 上,不带 -t 的普通 mount 会选择 ntfs-3g;它会打印所有警告,然后仍以只读方式挂载分区:
sudo mkdir -p /mnt/windows /mnt/data
sudo mount /dev/sda3 /mnt/windows
findmnt /mnt/windows
退出码是 0,因此只检查命令是否成功的脚本不会发现实际为只读挂载。真正需要注意的是 findmnt 输出中的 ro 标志。

尝试其他操作前先卸载它,后文的命令都要求 /mnt/windows 不被占用:
sudo umount /mnt/windows
从这里开始,对休眠分区只应执行只读挂载。
如果已经尝试过 mount -t ntfs3
内核自带的 ntfs3 是另一种常见建议,也是本文最不建议用于休眠分区的驱动。以读写方式请求挂载时,内核 7.0 只会打印通用挂载错误,日志中甚至没有提到休眠:
mount: /mnt/windows: wrong fs type, bad option, bad superblock on /dev/sda3, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
[ 210.009569] ntfs3(sda3): Mark volume as dirty due to NTFS errors
[ 210.062878] ntfs3(sda3): volume is dirty and "force" flag is not set!
但拒绝发生的时机已经太晚。内核 fs/ntfs3 源码表明,读写挂载会在到达失败检查之前重放并重置 NTFS 日志,同时向卷写入 dirty 标志。两次尝试后 Windows 都能从休眠恢复,但 dirty 标志一直存在,ntfs3 直到再执行一次 Windows 冷启动后才接受 C:。
更糟的是,第一次尝试后休眠检查本身也失效了。对于仍处于休眠状态的 C:,ntfs-3g.probe 返回 0,读取 hiberfil.sys 出现输入/输出错误,普通 mount 甚至以读写方式挂载:
rc=0
TARGET SOURCE FSTYPE OPTIONS
/mnt/windows /dev/sda3 fuseblk rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096
因此,如果曾在休眠分区上执行读写 ntfs3 挂载,就不要再相信探测结果或“挂载成功”。在 Windows 恢复并完全关机之前,都应按休眠分区处理,只执行只读挂载。
使用只读挂载复制文件
如果只需要取一两份文档,使用任意一种驱动进行只读挂载都安全。只读 ntfs3 会跳过日志重放;以这种方式挂载再卸载 C: 后,探测工具仍返回退出码 14:
sudo mount -t ntfs3 -o ro /dev/sda3 /mnt/windows
ls /mnt/windows | head
cat /mnt/windows/Users/Public/before-hibernate.txt
Windows 在休眠前已写入磁盘的数据都可以读取,包括一分钟前写入 C: 的测试文件。下面的目录列表由 head 截取前 10 项:
$Recycle.Bin
Documents and Settings
DumpStack.log.tmp
PerfLogs
Program Files
Program Files (x86)
ProgramData
Recovery
System Volume Information
Users
written on C: before hibernation
把需要的文件复制到 Linux 主目录,然后执行 sudo umount /mnt/windows。任何仍打开但尚未保存的 Windows 内容只存在于休眠镜像中,在文件系统里找不到。
在 Windows 中正确修复
真正的修复是让 Windows 停止休眠,而且必须在 Windows 中完成。完整流程有四步:
- 启动 Windows,让其恢复。
- 在管理员权限的命令提示符中关闭休眠。
- 使用
shutdown /s /t 0完全关机。 - 回到 Linux,用
ntfs-3g.probe检查分区。
先恢复 Windows 很重要,因为这样它才能把内存中保留的所有内容写回磁盘。随后打开管理员权限的 Command Prompt 或 PowerShell。Microsoft 的休眠指南也使用相同命令:
powercfg /hibernate off
powercfg /a
关闭休眠会删除 hiberfil.sys,同时禁用快速启动,因为快速启动会把内核会话保存到同一个文件。Windows 10 和 11 中最常见的问题来源正是快速启动:启用它时,普通的“关机”操作仍属于部分休眠。查看输出最后两项,可以看到混合睡眠和快速启动都报告休眠不可用:
The following sleep states are not available on this system:
Standby (S1)
The system firmware does not support this standby state.
An internal system component has disabled this standby state.
Graphics
Standby (S2)
The system firmware does not support this standby state.
An internal system component has disabled this standby state.
Graphics
Standby (S3)
The system firmware does not support this standby state.
An internal system component has disabled this standby state.
Graphics
Hibernate
Hibernation has not been enabled.
Standby (S0 Low Power Idle)
The system firmware does not support this standby state.
Hybrid Sleep
Standby (S3) is not available.
Hibernation is not available.
Fast Startup
Hibernation is not available.
随后 PowerShell 中的 Test-Path C:\hiberfil.sys 返回 False,说明文件已经消失。如果笔记本需要在电池供电时保留休眠,可以只关闭快速启动:在 Windows 10/11 中进入“控制面板 → 硬件和声音 → 电源选项 → 选择电源按钮的功能 → 更改当前不可用的设置”,取消勾选“启用快速启动”并保存。该复选框只在休眠启用时出现。Windows Server 默认通过策略关闭快速启动,因此实验中使用了完整休眠;它对磁盘产生的锁定效果相同。
现在完全关闭 Windows。无论快速启动设置如何,下面的命令都会执行完整关机:
shutdown /s /t 0
返回 Linux 后,C: 的探测结果返回退出码 0。如果 Linux 从未向休眠分区写入数据,此时可以直接进行后文的读写挂载。
出现 “volume is dirty and "force" flag is not set!”
如果此前有内容写入过该卷,即使 Windows 已经完全关机,ntfs3 仍可能拒绝挂载并显示该消息。实验中出现过两次,原因各不相同。在失败的 ntfs3 尝试后,Windows 的 fsutil dirty query C: 显示卷是干净的,再执行一次冷启动和 shutdown /s /t 0 就解决了。执行 ntfsfix(见下文)后,Windows 认可卷有 dirty 标志,ntfs-3g 的 ntfsinfo 也报告同样结果。可在 Linux 中检查:
sudo ntfsinfo -m /dev/sda3 2>&1 | head -3
设置了标志的卷会打印一段更长警告的前三行:
Volume is scheduled for check.
Please boot into Windows TWICE, or use the 'force' option.
NOTE: If you had not scheduled check and last time accessed this volume
这次单次冷启动没有清除该标志。先在 Windows 中用 fsutil dirty query C: 检查;如果显示 Dirty,就在管理员提示符中安排磁盘检查,回答 Y 然后重启:
chkdsk C: /f
shutdown /r /t 0
重启期间磁盘检查运行(Wininit 事件 1001),随后 fsutil 显示卷不再 dirty,再一次 shutdown /s /t 0 后,Linux 显示的卷标志为 0x0000,并可读写挂载 C::
rc=0
/dev/sda3 ntfs3 rw,relatime,uid=0,gid=0,acl,iocharset=utf8,prealloc
不要使用提示中建议的 force 挂载选项。内核文档本身不推荐它,而启动 Windows 检查一次只需要两分钟。如果 Windows 随后无法检查磁盘,可另行处理 chkdsk 的 “cannot open volume for direct access” 错误。
不要在休眠分区上使用 ntfsfix
较早的教程,包括本文旧版本,可能建议使用 ntfsfix 清除休眠标志。它并不会这样做。其试运行模式甚至检测不到休眠,会把休眠的 C: 报告为健康:
sudo ntfsfix -n /dev/sda3
对于一个刚被探测工具拒绝的分区,每一行却都显示 OK:
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda3 was processed successfully.
真正执行更危险。它会设置 dirty 标志、清空 NTFS 日志,然后因休眠而以退出码 1 失败,同时保留休眠锁。日志中包含 Windows 尚未完成写入的元数据变更,而恢复过程恰好需要这些信息:
Mounting volume... FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Windows is hibernated, refused to mount.
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Windows is hibernated, refused to mount.
Remount failed: Operation not permitted
ntfsfix 只适合它原本设计的场景:Windows 不可用、又需要修复一个未正常卸载的 NTFS 卷。它会重置日志,并标记卷在下次 Windows 启动时接受检查;它绝不是休眠修复工具。唯一例外是下文最后的救援方案,那里的目标本来就是销毁日志。
只有在最后手段下才删除休眠文件
ntfs-3g 提供 remove_hiberfile 挂载选项,可在挂载时删除休眠镜像。单独使用时它会被拒绝,因为休眠卷的日志也不干净。失败后探测仍返回 14;Windows 随后以启动类型 0x2 恢复,Notepad 窗口依然打开:
sudo mount -t ntfs-3g -o remove_hiberfile /dev/sda3 /mnt/windows
ntfs-3g 的提示指向日志,而不是休眠文件:
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Failed to mount '/dev/sda3': Operation not permitted
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.
第三次实验之所以成功,只是因为 ntfsfix 已经清空日志。因此 Linux 端的救援需要两个破坏性步骤:先 ntfsfix,再 remove_hiberfile;仅在 Windows 已无法启动且现在必须获得写权限时使用。按顺序执行并检查结果:
sudo ntfsfix /dev/sda3
sudo mount -t ntfs-3g -o remove_hiberfile /dev/sda3 /mnt/windows
findmnt -n -o FSTYPE,OPTIONS /mnt/windows
挂载以读写方式成功,hiberfil.sys 已消失:
fuseblk rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096
随后从 Linux 向 C: 写入文件,卸载并启动 Windows。下一次启动给出了很多信息:
- 启动类型为 0x0(冷启动),不是 0x2(恢复)。
- Kernel-Power 事件 41:系统未正常关机便重新启动。
- 原先打开的 Notepad 会话消失。
- C: 被标记为 dirty,之后通过
chkdsk C: /f清除。 - 休眠前保存的文件以及 Linux 写入的文件都保持完整。
对于正在救援的机器,这个代价可以接受。对于刚休眠且还有未保存工作的笔记本,应恢复 Windows,再使用上文的正确修复。
数据盘也必须按休眠状态处理
Windows 休眠时,所有已挂载的 NTFS 卷都属于保存的会话,但只有系统盘包含 hiberfil.sys。Linux 无法判断这一点,因此两种驱动都把实验中的 D: 数据盘以读写方式挂载,而且没有给出任何警告:
sudo mount -t ntfs-3g /dev/sdb2 /mnt/data
echo 'written from Linux while Windows was hibernated' | sudo tee /mnt/data/from-linux.txt
sudo umount /mnt/data
然后恢复 Windows。它按预期从休眠恢复,但看到的 D: 仍是休眠时保存的旧视图,没有 Linux 写入的文件:
Name Length LastWriteTime
---- ------ -------------
notes-from-windows.txt 39 10/18/2026 2:03:56 PM
round2.txt 48 10/18/2026 2:16:24 PM
对 D: 执行在线扫描后发现并修复了错误。Linux 写入的 48 字节文件后来重新出现在磁盘上,但 Windows 曾基于卷的陈旧视图运行,向繁忙目录写入可能造成损坏。只要 Windows 处于休眠或启用了快速启动,它所使用的所有 NTFS 盘都应只读挂载,不仅是 C:。
如果已经在 Windows 休眠时写入数据盘,应在 Windows 恢复后立即扫描,之后再做其他写入。以下 PowerShell 命令需以管理员身份执行:
Repair-Volume -DriveLetter D -Scan
实验中的 D: 返回 ScanErrorsFoundAndFixedOnline,系统日志记录了事件 130:“The file system structure on volume D: has now been repaired”。
在启动时读写挂载 NTFS
Windows 完全关机后,可以长期使用内核 ntfs3 驱动挂载。以 root 身份挂载时,所有文件都归 root 所有,因此要传入当前用户的 UID/GID,并加入 windows_names,防止 Linux 创建 Windows 无法打开的文件:
id -u; id -g
sudo blkid -s UUID -o value /dev/sda3
实验用户的 UID 和 GID 都是 1000,C: 的 UUID 如下:
8A9AA8079AA7EDBF
打开 /etc/fstab,使用自己的 UUID 添加一行。nofail 很重要;没有它,Windows 磁盘缺失或被拒绝挂载可能导致 Linux 启动进入紧急模式:
sudo vi /etc/fstab
实验使用的行如下:
UUID=8A9AA8079AA7EDBF /mnt/windows ntfs3 uid=1000,gid=1000,windows_names,nofail 0 0
只有关闭休眠和快速启动后才能添加这一行。每次启动都会尝试读写 ntfs3 挂载;如果 Windows 再次休眠,这次尝试就是前文所述的日志重置写入。nofail 只能防止启动卡住,不能阻止写入。先在不重启的情况下挂载,检查选项和剩余空间:
sudo systemctl daemon-reload
sudo mount -a
findmnt -n -o SOURCE,FSTYPE,OPTIONS /mnt/windows
df -h /mnt/windows
输出会包含你的 UID/GID 和 windows_names,重启后同一配置也会自动恢复:
/dev/sda3 ntfs3 rw,relatime,uid=1000,gid=1000,windows_names,acl,iocharset=utf8,prealloc
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 64G 13G 51G 20% /mnt/windows
挂载后有两个值得注意的现象。Users\Public 即使对所有者也是 dr-xr-xr-x,因此写入会返回 “Permission denied”。ntfs3 会移除带 Windows 只读属性的对象的写权限,而 Windows 会给若干用户配置目录设置该属性;在磁盘根目录新建文件夹则正常。windows_names 也发挥了作用:touch 'bad:name.txt' 返回 “Invalid input”,避免创建 Windows 无法读取的文件。
根据可承受的损失选择方案
所有测试方案要么牺牲休眠会话,要么给卷带来风险,应按实际情况选择:
| 场景 | 操作 | 代价 |
|---|---|---|
| 只需要取出几个文件 | mount -t ntfs3 -o ro |
无代价;Windows 可正常恢复 |
| 每天频繁双系统切换 | powercfg /hibernate off,再执行 shutdown /s /t 0 |
失去 Windows 休眠与快速启动 |
| 笔记本需要保留休眠 | 只关闭快速启动,启动 Linux 前完全关机 | Windows 冷启动变慢 |
| Windows 无法启动且必须写入 | ntfsfix,再执行 mount -t ntfs-3g -o remove_hiberfile |
丢失当前会话,之后还需 chkdsk C: /f |
| Linux 已写入休眠卷 | 恢复 Windows,然后执行 Repair-Volume -Scan 或 chkdsk /f |
可能丢失 Linux 写入的文件 |
想用读写 mount -t ntfs3、ntfsfix 或 -o force |
Windows 休眠期间不要这样做 | 可能破坏恢复所需的 NTFS 日志 |
如果每天都要在 Windows 和 Linux 之间共享数据,单独使用 exFAT 分区可以避免上述全部问题,因为 Linux 不会在其上看到 Windows 日志。创建双系统的过程可参考 Fedora 与 Windows 11 双启动指南;Red Hat 系列上的同类 NTFS 挂载选项也与本文一致。










