Created attachment 1809731 [details] CBS.log warnings from windows repair attempts Description of problem: When attempting to mount ntfs volume on my dual boot laptop I get the following message, and mount is ro, not rw. # mount -t ntfs -o rw /dev/nvme0n1p3 /mnt Windows is hibernated, refused to mount. Falling back to read-only mount because the NTFS partition is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting.) I have always done a clean shutdown and never use hibernation or suspend. After receiving this message I have restarted and shutdown windows repeatedly but always get the same message when mounting the volume. Version-Release number of selected component (if applicable): # dnf list installed ntfs* Installed Packages ntfs-3g.x86_64 2:2017.3.23-14.fc33 @anaconda ntfs-3g-system-compression.x86_64 1.0-4.fc33 @anaconda ntfsprogs.x86_64 2:2017.3.23-14.fc33 @anaconda How reproducible: Attempt to mount ntfs volume in fedora Steps to Reproduce: 1. Boot, then do a clean shutdown of windows 2. Boot to fedora 33 kernel 5.13.5 (and any earlier kernel between 5.12.9 and 5.13.5) 3. Attempt to mount windows volume in fedora Actual results: volume is mounted read only with message above. Expected results: volume should be mounted read/write Additional info: $ uname -a Linux laptop.home.domain 5.13.5-100.fc33.x86_64 #1 SMP Sun Jul 25 16:24:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux # dnf upgrade --refresh Fedora 33 - x86_64 48 kB/s | 13 kB 00:00 Fedora 33 openh264 (From Cisco) - x86_64 5.4 kB/s | 989 B 00:00 Fedora 33 - x86_64 - Updates 39 kB/s | 11 kB 00:00 google-chrome 13 kB/s | 1.3 kB 00:00 RPM Fusion for Fedora 33 - Free 16 kB/s | 8.4 kB 00:00 RPM Fusion for Fedora 33 - Free - Updates 32 kB/s | 6.9 kB 00:00 RPM Fusion for Fedora 33 - Nonfree 37 kB/s | 8.1 kB 00:00 RPM Fusion for Fedora 33 - Nonfree - Updates 25 kB/s | 7.2 kB 00:00 Dependencies resolved. Nothing to do. Complete! Windows 10 version 21H1 updated 7/24/2021 In the windows powershell (admin) command window I ran "sfc /scannow" and it fixed a couple of link errors the first time I ran it, but continues to report several directories with dual ownership or security permissions. The attached log is from C:/WINDOWS/Logs/CBS/CBS.log and contains warnings from the most recent time I ran sfc. I also ran "chkdsk c: /F" and allowed it to check the disk at the next boot with no errors reported. On the windows boot I have run "chkdsk c: /F" so it performed the check on the next boot, and no errors were noted.
> Windows 10 version 21H1 updated 7/24/2021 Thanks for sharing what looks like a Microsoft attempt to kick us out of using ntfs. I do not have this version yet, and today I am only proposed to get cumulative updates to 20H2, so I cannot give definitive answers. Do not try to force rw mode : part of volume metadata is within the Windows cache and not reloaded when Windows boots again, so updates by Linux may be ignored and overwritten, possibly creating inconstancies. Then can you please extract the ntfs and log version used by 21H1. As root do (/dev/nvme0n1p3 being the name of your Windows 10 partition) : ntfsinfo -fm /dev/nvme0n1p3 | head and (replacing /win10 by your Windows 10 mount point, apparently /mnt/something, keeping the single quotes or escaping the $) od -t x1 '/win10/$LogFile' | head Also please try to leave Windows 10 for Linux by selecting "Restart" instead of "Shutdown". Note : the warnings you get from sfc look like a Windows-only issue which is unlikely to lead to mounting read-only.
Oh, and did you disable the fast restart mode anew ? powercfg /h off
The commands you requested: [root@laptop jvian]# ntfsinfo -fm /dev/nvme0n1p3 | head Volume Information Name of device: /dev/nvme0n1p3 Device state: 11 Volume Name: OS Volume State: 91 Volume Flags: 0x0000 Volume Version: 3.1 Sector Size: 512 Cluster Size: 4096 Index Block Size: 4096 [root@laptop jvian]# od -t x1 '/mnt/$LogFile' | head 0000000 52 53 54 52 1e 00 09 00 00 00 00 00 00 00 00 00 0000020 00 10 00 00 00 10 00 00 30 00 01 00 01 00 09 00 0000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000060 1e e9 18 16 07 00 00 00 01 00 ff ff 00 00 02 00 0000100 28 00 00 00 e0 00 40 00 00 00 00 04 00 00 00 00 0000120 70 00 00 00 30 00 40 00 80 92 ca 38 00 00 00 00 0000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000160 13 e9 18 16 07 00 00 00 1e e9 18 16 07 00 00 00 0000200 ff ff ff ff 00 00 00 00 00 00 00 00 08 00 00 00 0000220 4e 00 54 00 46 00 53 00 00 00 00 00 00 00 00 00 I don't recall that I had ever previously set the power settings in windows, but went into the control panel and made certain all the buttons, lid switch, etc were set to do nothing except the power switch is now set to shutdown, both on battery and on AC. Most were previously set to sleep. I ran the "powercfg /h off" command I also tried both shutdown and restart on the power for windows. Nothing has changed in the way it mounts in fedora.
This volume is clean and not marked for fast restarting. It probably has a hiberfile as a consequence of your earlier settings. You will not be able to delete it from Windows (or maybe by hibernating and wakening again), but you can mount with the option "remove_hiberfile" to delete it : mount -t ntfs -o rw,remove_hiberfile /dev/nvme0n1p3 /mnt The file will be creating again when restarting Windows, but hopefully it will not be marked for hibernating.
I used the mount command you provided above to mount and remove the hiberfile from the ntfs partition. Following an unmount I was then able to cleanly mount the partition in rw mode without the hiberfile option. I then booted back into windows and did a clean shutdown (using restart) before booting back into fedora. This time a mount of the partition without using the hiberfile option again gave me the message about windows being hibernated and refused to mount in rw mode again. It provided the same message as posted above in the description of the problem. It would appear that Microsoft has made a change in the way it marks the disk at shutdown so even with a clean shutdown ntfs-3g sees it as in an unsafe state. I would strongly recommend that anyone dual booting with windows 10 avoid the update to version 21H1 if they can. As you noted earlier I did not have this problem with version 20H2. A work around seems to be using the remove_hiberfile option for the mount but that could be hazardous if the system was actually hibernated.
It appears that at some point in the past my win10 system was actually hibernated without me realizing it. I went back over the suggested commands and realized that when I ran the "powercfg /h off" command I did not do so as admin in the powershell. After again running that command from the admin powershell the system will now cleanly shutdown (both Shutdown and Restart) without marking the hiberfile as hibernated. It now can be properly mounted in rw mode from linux so this issue seems resolved. Thanks to all for the help.
I had just upgraded to Windows 10 21H1, and I was trying to reproduce the issue, with no success so far. So thank you for your clarification, just a false alarm.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
closing due to EOL of F33