You are not logged in.
I ran into an issue with mounting NTFS partitions lately and so far have no clue what's up. Could it be a ntfs3 bug?
Context:
- I have two NTFS partitions on two separate SSDs that I occasionally mount on Linux.
- Never had any issue until recently.
- Both refuse to mount with a similar error:
[ 103.623473] ntfs3: Enabled Linux POSIX ACLs support
[ 103.623476] ntfs3: Read-only LZX/Xpress compression included
[ 103.959148] ntfs3(sdb1): Mark volume as dirty due to NTFS errors
[ 103.959183] ntfs3(sdb1): Failed to load $BadClus (-22).
- I first tried running 'ntfsfix -d', but it didn't change a thing.
- I then booted Windows (which I do very rarely these days) to try and fix this. Upon booting, it did automatically run chkdsk (which takes quite a while) and eventually found... no error.
- Accessing both partitions from Windows worked fine.
- Rebooted Linux (currently kernel 6.12.1 but it appeared with (I think, I don't mount those partitions very often) kernel 6.10 or 6.11.
- Still the same error when trying to mount the NTFS partitions.
If that can give any hint, here are the options I have set in fstab for both NTFS partitions:
ntfs3 noauto,relatime,uid=1000,gid=1001,dmask=022,fmask=133,windows_names 0 0
Any idea? Thanks!
Edit: after rebooting to Linux, I had only re-tested one of the two partitions. Turns out the other one does now mount properly. There's still one with this "Failed to load $BadClus (-22)" error, while it works on Windows.
I have looked it up and found very little on this error. It just appears when the driver is unable, to, you guessed it, read the $BadClus metadata in the NTFS partition. No clue what could have happened to this metadata block. Maybe Windows just doesn't care about it if it's unreadable? (Knowing that it's a SSD and AFAIK, "bad clusters" in SSDs should already be taken care of transparently by the drive itself, so this NTFS metadata probably serves no purpose on a SSD? Maybe the reason Windows would ignore it?)
I had let chkdsk run with its default options. The $BadClus metadata contains a list of bad clusters. Looking at chkdsk options, it has a /b option which seems to rebuild the list of bad clusters - so I'm assuming it rebuilds this metadata as a byproduct and that could solve my issue? (Haven't tried yet - if anyone has ever run into this issue before...)
Last edited by OpusOne (2024-11-25 03:22:27)
Offline
I recommend running chkdsk from windows with the options /F /X /R /B set
caution: depending on drive size and how much is stored on it this can take a really long time
Online
Well it has already been run with all but the /B option. So I'll try the /B option next. Yes it was very long the first time so, I'll do that later...
I'm still wondering what the purpose of the $BadClus metadata is for SSDs and how it is handled exactly by Windows (and Linux). Since Windows didn't complain and chkdsk found absolutely no error, I suspect that either there's a bug in ntfs3, or the metadata is really corrupted and Windows doesn't care about it (possible, as I said, since it's a SSD). Question is, it's probably too detailed a question to find any answer since we have no access to Windows source code.
The odd thing is that, again, chkdsk didn't find any error. I also tried ntfsfix on Linux, and it also found absolutely zero issue. So either there's a bug in ntfs3 in checking this particular metadata block, or it's just never checked except by the ntfs3 driver when mounting the drive. I don't know.
Either way, there's no way to bypass this check. The force option for mounting doesn't bypass it (I think it only bypasses checking the dirty flag).
Offline
I then booted Windows (which I do very rarely these days) to try and fix this.
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Offline
Hi, I see others have issues lately with ntfs3.
Thanks for the link. I for one have Win 7 as dual boot, so it doesn't even have "fast boot" (but it's good to know nonetheless). So pretty sure it's not the issue here. Besides, I very rarely boot Windows these days and am 100% positive I hadn't booted it between the time I could normally access this NTFS partition with ntfs3 and the time it stopped working (with the error shown above).
As I understand, for now the solution would be to use ntfs-3g instead of ntfs3? Which may indeed have introduced some new issues? Since I had heard ntfs-3g was not recommended these days, that's something I hadn't considered. But apparently some people use it and never had problems.
Offline
well - a more proper way would actually be: don't use ntfs on linux at all - but rather use exfat to exchange data between windows and linux (but still use os-proper FS for actual use - as in: ntfs on windows and any posix FS on linux)
Online
As I understand, for now the solution would be to use ntfs-3g instead of ntfs3? Which may indeed have introduced some new issues? Since I had heard ntfs-3g was not recommended these days, that's something I hadn't considered. But apparently some people use it and never had problems.
ntfs-3g has been the defacto standard for ages, but it's more lenient towards the dirty flag, the downside of that is pot. data loss.
Check the journal of the previous boot, whether the drive cleanly unmounted before the shutdown
sudo journalctl -b -1
and in case you suspect an ntfs3 regression, consider trying the LTS kernel.
Offline