SSD drive 'file system is read only' after upgrade to Mint 20.2 (Uma)

[Chromie]

Hardware: MSI laptop with i9, 32GB Ram, one 1TB SSD for system drive, two 2TB SSDs for development.
Both of the 2TB SSDs are formatted NTFS, for ease of access via Linux and Win7.
Software: Dual boot: Mint, Win7

The system was working perfectly under Mint 19.x. All drives were accessible for read or write. No errors flagged.
After upgrading to Mint 20.2 (Uma), BOTH of the 2TB SSD drives in this system are now flagged as 'file system is read only.'
In other words, the drives can be read, but not written to. So far, I have found no fix for this!

This is not caused by a hardware error. Both SSD drives are fairly new, and they pass all diagnostics. I have booted to Win7 to run extensive drive tests, including HD Sentinel's surface test (about as good as you can get for drive diagnostics). SMART parameters look perfect. And again, this occurred on both drives simultaneously, which points to a different cause.

Both drives can be written to when the system is booted to Mint 20.2 via USB flash drive, or to Win7 via flash drive or the dual boot partition. Again, diagnostics do not flag any hardware problems in either case. The 'file system is read only' message occurs only when booted directly to Mint 20.2 on the internal 1TB system drive.

The 1TB SSD drive used for the main system drive was unaffected, and can still be written to.

I have tried re-writing the drives' params within fstab. No change.
I've tried various remedies found via searching forums. Nothing worked.

Two significant clues seem to be the NTFS format on the two 2TB drives, and the upgrade to Mint 20.2. Does anyone know of possible cause or fixes for this?

[rene]

The vast majority for this issue is when dual-booting with Windows 8+ and it using Fast Startup. Windows 7 is rare, and things working fine when booting to (supposedly) a 20.2 Live/Installer system says it must be specific to your 20.2 install.

ntfs-3g is a dependency of the core packages so it'll not be matter of it not being installed. Does sudo apt-get install --reinstall ntfs-3g fix anything? If so something was damaged during install...

If that's not an immediate fix look through journalctl -b to possibly see an error message, or I guess, try and mount manually with e.g.

Code: Select all

sudo mount -t ntfs-3g /dev/sdz99 /mnt

in which of course /dev/sdz99 is a proper partition identifier for one of the two 2T SSDs to potentially see an error message [edit: after first unmounting the read-only instance with sudo umount /dev/sdz99). With it unmounted,

Code: Select all

sudo ntfsfix -n /dev/sdz99

might also be instructive (note, the -n means it won't in fact do anything).

[AndyMH]

I have tried re-writing the drives' params within fstab. No change.

Show us the relevant fstab entries.

The system was working perfectly under Mint 19.x.

You did an upgrade from LM19 to LM20, not a fresh install?

[Chromie]

I have tried re-writing the drives' params within fstab. No change.

Show us the relevant fstab entries.

The system was working perfectly under Mint 19.x.

You did an upgrade from LM19 to LM20, not a fresh install?

I'll post the fstab entries when I get a chance. If I recall, the first entries ended "0 2"
which seem to be the more relevant parameters. The drives worked fine with those
parameters when Mint 19.x was running.

But I still wanted to rule out fstab as a source of problems, so I commented those
entries out, and used the 'disks' program to generate new entries. I'll post both
later. I didn't think that this was the likely cause of problems, but I haven't used
Mint as much as the pro's here.

Upgrade to v20: I did the upgrade 'in place' since I did not want to reinstall
programs, drivers, etc. It seemed to go smoothly, and the boot drive is fine.
Are in-place upgrades a known cause of this type of problem?

[AndyMH]

Are in-place upgrades a known cause of this type of problem?

No, but it can cause problems, I tried an upgrade for the first time LM19.3 to LM20.0, had issues (can't remember what), so reverted to what I've always done - a fresh install on a major version change. Other people have had no problems.

[Chromie]

Code: Select all

sudo ntfsfix -n /dev/sdz99

might also be instructive (note, the -n means it won't in fact do anything).

@Rene, All of your suggestions are appreciated, and I'm following up with the others.
But the command above may be the one to provide the best clues. Here's the output:

---
m@Tachyon:~$ sudo -n ntfsfix /dev/nvme0n1
Mounting volume... NTFS signature is missing.
FAILED
Attempting to correct errors... NTFS signature is missing.
FAILED
Failed to startup volume: Invalid argument
NTFS signature is missing.
Trying the alternate boot sector
Unrecoverable error
Volume is corrupt. You should run chkdsk.
---

I tried booting to Mint 20.2 on a USB flash drive, and running the same command.
The result is the same, unfortunately.

The SSD drives themselves are fine and SMART parameters indicate no problems.
Drives are accessible within Win7. No problems with file system integrity under
Win7.

Not sure about the message to run chkdsk. As far as I know, that's a Windows
program only, so it's odd to see this as a Linux error message. Still, I did boot
Win7 and ran chkdsk on both drives. No problems spotted.

So this seems to be some problem with file system integrity that may have occurred
during the upgrade to Mint 20.x. Weird.

Given the nature of the error message above, I'm not sure if this is directly fixable.
I could try to wipe both of the 2TB SSD drives, then reformat, and restore all the
data, but I'm concerned that the problem would occur again.

Anything come to mind, given the newest error messages?

[Chromie]

The vast majority for this issue is when dual-booting with Windows 8+ and it using Fast Startup. Windows 7 is rare, and things working fine when booting to (supposedly) a 20.2 Live/Installer system says it must be specific to your 20.2 install.

I realized that the Fast Startup (called Fast Boot sometimes) relates to Windows' Hibernate function.
If so, then that would affect Win7 as well. Is that what you were referring to?

It's hard to imagine how Windows hibernate would affect non-system drives, but perhaps that is the case.
You'd also think that any problem caused by Hibernate would be easy to fix, but evidently not.

I've also found that your suggested file system check -does- flag the same errors even when booted from USB Flash drive.
So that may mean that this is some alteration of the NTFS file system that is visible to Mint, but not to Windows.
That would also be odd.

[Chromie]

Are in-place upgrades a known cause of this type of problem?

No, but it can cause problems, I tried an upgrade for the first time LM19.3 to LM20.0, had issues (can't remember what), so reverted to what I've always done - a fresh install on a major version change. Other people have had no problems.

If this could be caused by Windows' Hibernate or Fast Boot functions, then it will only occur again later, even if I take the time to reinstall Mint 20.x.

Here are the fstab entries that you requested:

# 2TB NVMe Work drive
# UUID=EC72327E72324D98 /Work ntfs defaults 0 2

# 2TB SSD Misc drive
# UUID=58322CAD322C91D4 /Misc ntfs defaults 0 2
/dev/disk/by-uuid/EC72327E72324D98 /Work auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/58322CAD322C91D4 /Misc auto nosuid,nodev,nofail,x-gvfs-show 0 0

The two that are commented out -did- originally work with Mint 19.x. I don't remember the significance of the "0 2" at the end.
The latter two entries were generated via the 'disks' utility. There is an option to create the fstab entries. I did notice that they end in "0 0"

Do you see anything that could cause problems here?

[rene]

Yes, if the system was in fact hibernated from Windows rather than shut down, that would explain all. However... does that make sense? Would you even get the option to boot into Linux when waking the system up from hibernation as initiated from Windows? In fact --- you probably do. Yes, if you hibernated Windows rather than shut it down then that's the problem.

If not...

/dev/nvme0n1 is not a partition identifier but a complete drive, your first NVMe drive. You want something like /dev/nvme0n1p1 and /dev/nvme1n1p1 for the first partitions of the first and second NVMe drive. I had assumed that the 2T SSD drives in question would be SATA in which case those first partitions would be e.g. /dev/sda1 and /dev/sdb1. As is it's not strange that ntfsfix found the filesystems corrupted: it couldn't in fact find them. If you need help identifying the proper partition identifiers to have ntfsfix look at please post the output of sudo fdisk -l (inside of [code]...[/code] tags, please) but you might be able to identify them from said output yourself as well.

Also: NOTE. Not sudo -n ntfsfix /dev/whatever but sudo ntfsfix -n /dev/whatever. Although Windows CHKDSK (which is indeed what NTFS-3G referred you to...) finding all fine is in fact probably enough to assume that ntfsfix on Linux would not find anything wrong either, still run it on both partitions I guess. With the -n to make it not in fact do anything and just report.

Please also try the sudo apt-get install --reinstall ntfs-3g. It's a harmless command; thing is that Linux has two NTFS drivers; a userspace one through NTFS-3G which is what is normally used and a read-only kernelspace driver which would be fallen back unto if e.g. /sbin/mount.ntfs wasn't repointed at NTFS-3G as a matter of package damage. It's a little far-fetched maybe, but it came to mind anyway.

But, yes, if Windows was hibernated that's it: it in that case does not cleanly "unmount" filesystems whence NTFS-3G Linux-sides refuses to mount them r/w due to fear of damaging them: it has no access to filesystem information potentially present in the Windows hibernation-file alone.

[RIH]

If this could be caused by Windows' Hibernate or Fast Boot functions, then it will only occur again later, even if I take the time to reinstall Mint 20.x.

Yes, so you need to disable it in Windows & close down the system & the disk should be (& remain) free from Windows interference.
I have never disabled it in Windows 7 (but have in Windows 10) so I have not tried this..
https://www.computerhope.com/issues/ch001762.htm

[rene]

"Disabling hibernation" in Windows 7 is a simple matter of not hibernating Windows; it doesn't have a Fast Startup setting as 8+ do. Hence my original reply.

(although powercfg /h off from an admin-level CMD-prompt still disables even the option to hibernate).

[Chromie]

Please also try the sudo apt-get install --reinstall ntfs-3g. It's a harmless command; thing is that Linux has two NTFS drivers; a userspace one through NTFS-3G which is what is normally used and a read-only kernelspace driver which would be fallen back unto if e.g. /sbin/mount.ntfs wasn't repointed at NTFS-3G as a matter of package damage. It's a little far-fetched maybe, but it came to mind anyway.

But, yes, if Windows was hibernated that's it: it in that case does not cleanly "unmount" filesystems whence NTFS-3G Linux-sides refuses to mount them r/w due to fear of damaging them: it has no access to filesystem information potentially present in the Windows hibernation-file alone.

Hi Rene,
I had already followed up on all of your suggestions, including reinstalling ntfs-3g. Got some opaque message about setting an environment variable, but that looked innocuous. I intended to look into it further later. The other error seemed more serious.

In fact, I did not know that I was supposed to give a partition (rather than drive designation) to ntfsfix. I'll try that and get back. (The ntfsfix error message could have been more lucid re the drive-vs-partition thing)

I find the whole scenario with Hibernate to be bizarre, but what do I know. I'm primarily a Windows programmer. I really need to get up to speed on the subtleties of Linux file systems and such. Most of my recent projects (neural nets) require Linux.

How did you find all the info that you've conveyed here? Much appreciated, by the way, in case that was not obvious.
I did buy quite a few 'top level' Linux books, but I obviously need to find references that get into more detail.

[rene]

Just a longtime user. Note though that the hibernate issue is not bizarre and has not to do with "linux filesystems" (in fact we're talking about an NTFS filesystem here which certainly can not be called a Linux filesystem).

If you're a programmer you will have an appreciation for the fact that at any given point in time changes to a filesystem data structure may exist only in memory; that said data structure may have not been or may have not been fully synchronized to backing store yet; that the on-disk filesystem is as such at that moment in an inconsistent state. If with the filesystem under Windows in that state Windows hibernates, i.e., saves the entirety of memory including that/those unsynchronized filesystem data structure(s) to the Windows hibernation file and shuts down, the on-disk filesystem remains in inconsistent state and could only be made consistent by having access to the details of the memory dump in that Windows hibernation file --- something which a Linux (or Mac or, heck, another Windows install on the machine) certainly has not; it's fully specific to the copy of Windows that it is an hibernation image of.

As such and as said the Linux NTFS-3G driver refuses to mount the filesystem read-write so as to avoid potentially damaging data on that inconsistent filesystem. You can override it and it'll in practice often in fact be safe but you shouldn't; we're talking about a very fundamental issue here: whatever OS writes to a filesystem needs to make sure it has in fact completed all of it before a different OS tries to interpret that filesystem. All quite irrespective of Linux as such (and I expect that a Mac and/or other Windows copy would refuse to mount it even read-only in fact)

Anycase. You did not confirm/deny having hibernated Windows 7. As said, if you did that's the issue, and you should make sure that Windows is cleanly shut down before you boot into another OS that wants access to the same NTFS filesystem(s). If not --- it's not.

[AndyMH]

change

Code: Select all

# 2TB NVMe Work drive
# UUID=EC72327E72324D98 /Work ntfs defaults 0 2

# 2TB SSD Misc drive
# UUID=58322CAD322C91D4 /Misc ntfs defaults 0 2
/dev/disk/by-uuid/EC72327E72324D98 /Work auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/58322CAD322C91D4 /Misc auto nosuid,nodev,nofail,x-gvfs-show 0 0

to

Code: Select all

# 2TB NVMe Work drive
UUID=EC72327E72324D98 /Work ntfs uid=1000,gid=1000,defaults,nofail 0 2

# 2TB SSD Misc drive
UUID=58322CAD322C91D4 /Misc ntfs uid=1000,gid=1000,defaults,nofail 0 2

ntfs does not support permissions so linux has to spoof it. uid=1000,gid=1000 is telling linux who the owner is and what group, 1000 is the first UID allocated when you create a user = you. It can be replaced with your username, e.g. uid=fred. Failing to do this is a common reason for ntfs partitions to be read-only. If you still find it is read-only, make sure you own the mount point:

Code: Select all

sudo chown -R $USER:$USER /Work

Personally, I wouldn't use /Work and /Misc, from the descriptions I'd probably mount them in home, e.g. /home/you/Work, or /media/Work.

Bit more on fstab here:
https://help.ubuntu.com/community/Fstab
tells you what the 2 at the end means.

[rene]

Andy; note; poster already in his original post specified the error to be reported as "file system is read only". This points away from simple UNIX-permissions issues; points to, well, the file system being read-only rather than just some given location not being writeable as a permission issue. As mentioned, in the case of NTFS and at least in combination with Windows 8+ the by far most expected reason for this is Windows-sides hibernation/fast-startup; another one can be hardware or file-system problem. The fact that all works fine on Windows and said Windows is 7 is what makes this interesting.

His own /dev/disk/by-uuid is moreover only one level down the exact same and that "2" at the end is in the case of NTFS completely non-functional due to no NTFS-checker being installed in the first place. Admittedly if the "file system is read only" was specified too loosely and this turns out to in fact be the normal rights issue, fair enough, but I otherwise feel this is leading the thread astray.

[AndyMH]

Could be wrong (and happy to admit that ), but in my experience read-only ntfs partitions are usually:

• fast start - did google win8 on this, couldn't find a definitive answer if it supported it, or

• permissions

The only thing that makes me hesitant is that it 'worked under LM19'. A corrupt file system? ntfsfix didn't work, does the OP have a win system they can plug the drives into?

[rene]

Windows 8 has but Windows 7 has not and latter is what he is using. Permissions as said would not have the system tell him that "the file system is read-only" as he reported. Again, if that was too loosely reported, fine, my bad, but for now it seems not. Also, and also as said, the ntfsfix results we have seen were not useful due to poster specifying the device rather than partition, i.e., had it check for an NTFS filesystem in a spot there was not one.

That's the point a bit; would for now like to not confuse / draw out a support thread with things that were said, shown or considered already...

[Chromie]

Personally, I wouldn't use /Work and /Misc, from the descriptions I'd probably mount them in home, e.g. /home/you/Work, or /media/Work.

Bit more on fstab here:
https://help.ubuntu.com/community/Fstab
tells you what the 2 at the end means.

That's all helpful information, Andy. Just wanted to thank you again. I think the problem is/was
related to hibernate, though I haven't sorted out all the details. I have several dual boot systems,
and I don't recall seeing anything like this before. I'll be more aware of implications when hibernating
Win7 systems, and I've disabled fast startup on the ones running Win10.

Re the mount points: /Misc and /Work off root: I did that originally as sort of a parallel to Windows,
where they are automatically mounted as root (well, separate drive letters).

Please let me know if you are aware of any references that cover recommendations about this.
I could switch them to home or media on the Linux machines if there's any advantage to be had.

I'll try to elaborate more on the initial 'read only' problem later.

[Chromie]

... points to, well, the file system being read-only rather than just some given location not being writeable as a permission issue. As mentioned,

Hi Rene,

I would not have been up to speed on the finer points of that error message. For all I knew, it could have been permissions. So it's good to have more experienced, long-term linux users here.

Anyway, I have used hibernate under Win7 in the past, mostly to save state of a lot of browser windows. I didn't think I had done that this time, but after a few back-and-forth hard reboots, the drives/file systems are again writable.

The NTFS state thing is still a mystery to me. I didn't realize that running hibernate when nothing was accessing the SSD drives would still flag those drives as 'in use.' But perhaps the moral of the story is simply "Be careful using hibernate." Odd thing that I don't recall this occurring on my other systems, including those running Win10 + Mint. And I hadn't noticed it before on this particular Win7-Mint system. But I've revisited the Power options for the Win10 machines as well, and disabled quick start on those machines (it also hadn't occurred to me that that entailed use of hibernation).

In any case, I wanted to thank you for your help and insights. This was one that I would never have guessed. I keep learning little bits about Linux gradually, so in 75 more years, perhaps all of the nuance will be clear.

[rene]

The NTFS state thing is still a mystery to me. I didn't realize that running hibernate when nothing was accessing the SSD drives would still flag those drives as 'in use.'

Well, what hibernate is is "freeze current state and shut off" so if the state of a filesystem is 'in use' then that state remains so; as said above the on-disk state may / will generally be inconsistent while in use so that can't be helped; 'in use' is not just a matter of something accessing it at that very moment...

Any case good to know that the issue's solved