Unable to mount all NTFS partitions in Kernel 6.8.4

[wind77]

I updated the kernel to 6.8.4, and after rebooted, all NTFS partitions cannot be mounted.
In Dolphin, when i tried to mount, there was an “unknown error”.
In Gnome Disks, also “unknown error”.
My NTFS3 was disabled, so I’m using NTFS-3g.
After several attempts, it seems that reverting from kernel 6.8.4 to 6.7.12 would resolve the mounting problem.
Anyone facing same issue?

[Yochanan]

There was recent discussion in the latest Testing Updates topic and this info was added to the wiki post:

@philm

issues with auto-mount of ntfs filesystem using Kernel 6.8

The kernel changed default ntfs driver from FUSE one to ntfs3.
These two are not fully compatible, mainly as far as mount options go. If you have custom mount options in the fstab (or any other application, such as VeraCrypt) they need to be changed.

Symptoms:
Mount fails with: Device or resource busy
DMesg reports: Can't open blockdev

Solution:
Migrate your mount options. For me the changes were:

• allow_other → umask=000
• default_permissions → [drop]
• user_id=1000 → uid=1000
• group_id=1000 → gid=1000

[wind77]

@philm

Symptoms:
Mount fails with: Device or resource busy
DMesg reports: Can't open blockdev

well, my symptom is not any of this - just “unknown error when mounting”.

@philm

The kernel changed default ntfs driver from FUSE one to ntfs3.

And since my NTFS3 has been disabled, I presume upgrade to kernel 6.8 should not affect me?

I should also mention that: the kernel 6.8.4, is affecting both auto mount and manual mount of NTFS filesystem, not just auto mount (as reported in “Known Issue” on 2024.03.16).

[Aragorn]

@wind77

And since my NTFS3 has been disabled

Re-enable it then.

[Teo]

@wind77

since my NTFS3 has been disabled

…it will fail miserably when it tries to use it, which is probably what happens.

[wind77]

seriously?
After what u have told me?

Files missing during file transfer / renaming process

This could possibly be the culprit. That driver is still not very mature. Try mounting it manually with the ntfs-3g driver instead. sudo umount /dev/sda1 sudo mount -t ntfs-3g -o rw,nosuid,nodev,relatime,uid=1000,gid=1001,windows_names,iocharset=utf8 /dev/sda1 /run/media/wind77/R+SaSu

[Aragorn]

@wind77

seriously?
After what u have told me?

Apparently the driver has been deemed stable enough now in kernel 6.8, but you’ll have to make a choice: either you choose 6.7 (and earlier) with ntfs-3g, or you choose 6.8 with ntfs3. It’s not science.

If you stick with an LTS kernel — i.e. 6.1 or 6.6 — then you can stay with ntfs-3g.

[wind77]

@Aragorn

Apparently the driver has been deemed stable enough now in kernel 6.8

Is there any logs on the change in ntfs3?
I’ve not heard of the change since kernel 6.5, and wonder when / what changes have been implemented in ntfs3.

[Aragorn]

@wind77

Is there any logs on the change in ntfs3?

Here you go. But better take out some time on your agenda to read through that, because those are usually very technical reads…

@wind77

I’ve not heard of the change since kernel 6.5, and wonder when / what changes have been implemented in ntfs3.

Well, in order to know that, you’re going to have to read the kernel Changelogs for every major kernel version since 6.5, then.

And by the way, I haven’t said that there have been any changes to ntfs3 in 6.8 specifically — although there probably will be. What I said was that the kernel developers obviously now seem to think that ntfs3 would be stable enough for production use.

[wind77]

@Aragorn

What I said was that the kernel developers obviously now seem to think that ntfs3 would be stable enough for production use.

I understand that the previous approach to blacklist ntfs3 is a workaround, till ntfs3 becomes stable and no longer corrupting files.
So, in case I have missed the change log for ntfs3 since kernel 6.5, it would be good to learn that it has tackled the issue.
But if there is no change in ntfs3 since kernel 6.5, then I better take the conservative approach…

[Aragorn]

Then why use a bleeding-edge kernel? Just use an LTS kernel instead. 6.1 and 6.6 are still supported with updates up until December 2026.

[wind77]

@Aragorn

Just use an LTS kernel instead.

ntfs3 is present in all kernels, regardless of bleeding-edge or not - there is no way to avoid ntfs3.
But the issue here, is that kernel 6.8.4 broke ntfs-3g, and thus forcing me to revert to kernel 6.7.12.

[Teo]

@Aragorn

Here you go. But better take out some time on your agenda to read through that, because those are usually very technical reads

This is a bit more humanly, but still for people with much free time.
https://kernelnewbies.org/LinuxChanges
https://kernelnewbies.org/Linux_6.8

[wind77]

@Teo
Thank you!
Much appreciate your help!

[Aragorn]

@wind77

But the issue here, is that kernel 6.8.4 broke ntfs-3g, and thus forcing me to revert to kernel 6.7.12.

Well, if you stay with 6.1 or 6.6, then nobody’s forcing you into anything up until December 2026.

[wind77]

@Aragorn

What I said was that the kernel developers obviously now seem to think that ntfs3 would be stable enough for production use.

Just went through the logs provided by @Teo.

Previously, my files in NTFS filesystem were affected by ntfs3 in Kernel 6.4.
Since then, other than a label support feature in Kernel 6.5, there has been no update on ntfs3.
So i’m skeptical how the same ntfs3 driver, which has caused problem to my files previously, can be “stable” now.

So indeed, like what you suggested, if upcoming kernel doesn’t fix the broken ntfs-3g, then my only option would be to downgrade to a LTS kernel.

[Aragorn]

@wind77

So indeed, like what you suggested, if upcoming kernel doesn’t fix the broken ntfs-3g, then my only option would be to downgrade to a LTS kernel.

There’s no harm in that. 6.6 is the most recent LTS kernel, so unless you’ve got bleeding-edge hardware, it’ll do just fine.

I myself have always run LTS kernels in Manjaro, and I’m currently still running 6.1.

[wind77]

Bleeding-edge hardware… nah, i dun think latest HDD would count.
Anyway, my preference over bleeding-edge kernel is that I am hoping it would improve the performance of filesystem (both ext4 and ntfs), as well as the stability on some hardwares.
Compare to kernel 4.x era, definitely I have felt good improvement in these aspects.
Let’s hope this ntfs-3g issue can be fixed in upcoming kernel update.

@Aragorn Many thanks for your time and advice.

[psifi]

Manjaro-kernel is derived from arch-kernel, or am i wrong? So i do not understand why the actual arch-kernel 6.8 does not have this problem, with broken ntfs-3g as stated before [1]

[Aragorn]

@psifi

Manjaro-kernel is derived from arch-kernel, or am i wrong?

The kernel is one of the few things we do not literally take over from Arch. The Manjaro kernels are based upon the same sources as what Arch uses, but they do have some patches that are specific to Manjaro.