Bug 1988745

Summary: Unable to mount ntfs file system in rw mode.
Product: [Fedora] Fedora Reporter: Jeff <sandhillsinvestment>
Component: ntfs-3gAssignee: Tom "spot" Callaway <spotrh>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 33CC: jean-pierre.andre, sandhillsinvestment, spotrh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-23 02:01:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
CBS.log warnings from windows repair attempts none

Description Jeff 2021-07-31 17:59:59 UTC
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.

Comment 1 Jean-Pierre André 2021-08-01 09:40:23 UTC
> 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.

Comment 2 Jean-Pierre André 2021-08-01 10:48:14 UTC
Oh, and did you disable the fast restart mode anew ?

powercfg /h off

Comment 3 Jeff 2021-08-06 18:42:26 UTC
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.

Comment 4 Jean-Pierre André 2021-08-07 06:40:55 UTC
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.

Comment 5 Jeff 2021-08-07 14:34:16 UTC
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.

Comment 6 Jeff 2021-08-13 16:37:09 UTC
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.

Comment 7 Jean-Pierre André 2021-08-13 17:48:03 UTC
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.

Comment 8 Ben Cotton 2021-11-04 13:47:49 UTC
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.

Comment 9 Ben Cotton 2021-11-04 14:17:17 UTC
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.

Comment 10 Ben Cotton 2021-11-04 15:14:57 UTC
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.

Comment 11 Jeff 2021-11-23 02:01:16 UTC
closing due to EOL of F33