First message here.

I'm trying to set up my laptop for double booting Linux and Windows. I have two SSD, one SATA and one NVME.m2. Both are GPT formatted

I'm following the instructions from Arch Wiki to have both OS being able to hibernate independently. I basically have an EFI partition in each drive, one with the Windows bootloader and the other with GRUB for Linux and Windows. Both system partitions (windows C: and Linux /) are on the m2 drive, although the Linux EFI partition is on the SATA drive. I think this is 😎.

However, there's a shared data partition on the SATA drive that must be available for both systems. This is a NTFS partition, mounted on Linux using the NTFS-3g driver.

However, when Windows hibernate, this partition is locked. The Arch wiki recommends to set that partition as removable drive in Windows, and remove it before hibernate. Sounds cool, but I have no idea how to do that. Or something even more direct, like disable the locking of a partition during the windows hibernation.

Any help is appreciated

Sorry for not posting links to the documentation I'm using. I'll update this post later with more details if anyone is interested

Here's the link to Arch Linux documentation I referred before: https://wiki.archlinux.org/index.php/Dual_boot_with_Windows#Disable_Fast_Startup_and_enable_hibernation



I selected the exFAT option, but it is not straightforward in Archlinux. Fuse3 is required to run the user space tools to load it. The driver included in the kernel is not loading the partition. I created the partition from Windows, so there might be some incompatible features. But it's more or less working. Sometimes, wi does doesn't immediately see the changes made while it was hibernated. Test purposes, like creating empty files in Linux with 'touch' while Windows was asleep. Then waking Windows, and it's unable to see the files, after several refreshes. I would never edit on Linux a file that's already open in Windows. I'm any case, this partition is also sync with cloud backup, do in case of problems, I have that

Thanks for the help

2 Answers 2


I'm afraid you're misunderstanding that tip.

Note: You can avoid this issue for a drive by mounting a drive as an external drive in Windows and ejecting the drive in Windows before hibernating.

"Drive" here means a disk - a physical piece of hardware. A single partition (a volume) can't be removable.

You could have the shared partition on a USB drive or separate internal drive, if your SATA controller supports ejecting internal drives. But you can't make a single partition removable - it's a property of a device.

Alternatively you could unassign the drive letter before shutdown. I haven't tried it, but I think it will prevent Windows from marking that partition as hibernated (it would be pointless). It's not the most elegant solution, but it's something.

Another thing worth giving a try: use exFAT instead of NTFS. It's designed for external drives, so it may not have a hibernation flag.

  • I double down on the comment about using exFAT. Another reason for this is that Linux does not have great NTFS support (it cant) due to NTFS ACLs use windows permissions which Linux does not understand and probably never will. Fat32 would also be a good option IF your files aren't too big or partition sizes too large. Everything understands that file system. Sh*t simple but easy to break. Jan 28, 2021 at 0:14

Please consider the explanations from gronostaj.

In addition to that depending on the hibernation mode the partition maybe still in use as there are different hibernation modes in Windows10. That's why you are experiencing a lock.

If in such a case Linux would operate on the partition and Windows would restart again you could logically destroy your partition because windows is not aware of any changes and expected your partition as unchanged compared to the time when Windows fell asleep.

That's why you need to dismount this exchange partition under both operating systems to make sure they are a in a defined clean state.

In windows that would probably involve removing the drive letter for instance or deleting the mount point.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .