ntfs-3g fails to mount on kernel 6.8.1

[elandorr]

ntfs-3g 2022.10.3 integrated FUSE 28

Fails with can't open blockdev, and 'device or resource busy' (despite it being a clean boot).

It works until kernel 6.7.10.

I hope this is not related to plans of dropping ntfs-3g support, because ntfs-3g is stable, ntfs3 corrupts data.

[elandorr]

update: On kernel 6.8.2 it seems to work fine. So much for "stable".

I'll keep this open, because one of the ntfs-3g authors should probably be aware of complications in 6.8.x. I saw zero bugreports other than mine.

To make sure they did not force the god awful ntfs3, the process mount.ntfs-3g still has a bunch of ntfs-3g references in it, so all is fine. Unless they renamed everything just to mess with us rootkit style.

If anyone has not heard yet: do not use ntfs3. It will corrupt your data.

[philstephenson]

I'm on kernel 6.8.5 and still having the same issue. Everything was working fine on 6.7.

I can mount the disk if I use gnome disk utility or running mount -t ntfs /dev/sdb1 /mnt/storage however if I try to use fstab and mount via that I get the same error messages as @elandorr, "fuse: mount failed: Device or resource busy " and dmesg shows "/dev/sdb1: Can't open blockdev"

[unsound]

Some people are saying that 6.7 series breaks mounting with ntfs-3g, some say that it works on the 6.8 series and some say that it breaks on 6.8. I'm wondering if the kernel is really the factor that breaks things here... have you also updated other packages lately? Might there be a bug in some other package that retains a file handle to the device node when it shouldn't? If you reboot with an older kernel does it work? In general I wouldn't expect a kernel update to block device access for the ntfs-3g FUSE daemon, or any other userspace process unless there's some new security policy that I don't know about (this may also be distro-specific).

Can someone grep lsof output for the device that they're trying to mount to see if any process retains a reference to the device? Also the output from mount and dmesg might be relevant. Plus info about the distro and version.

[elandorr]

Mine was with a bootstrapped Debian, not easily comparable. It was reproducible: boot into 6.8.1, it broke, 6.8.2 or 6.7.x, it worked.

Some people may be mistakenly reporting it works by accidentally using ntfs3, which disturbingly comes prebuilt on some distros.

lsof was clean here. dmesg had nothing more than already posted.

Most important info for you maybe @unsound: there were no updates between booting into the different kernels. I even accidentally tested this multiple times because I failed to select the working one on boot :P. I even went on to custom build the 2 again with the same outcome.

Last I can report working here is 6.8.5. But I took the opportunity to actively avoid NTFS now. rsync's performance with ntfs-3g is EXTREMELY terrible for unknown reasons (even local disk-disk). ntfs-3g supports the windows-names flag which made cross platform pretty reliable, but all these issues were too much for me. ext4 works at non-ridiculous speeds just fine on the same drives.

[unsound]

I'm sure that if ntfs-3g still has breakage when Debian gets the 6.8 series into sid (latest one there is 6.7.9-2 at the time of writing) then more bug reports will start coming in but if it's already "fixed" in later 6.8 versions then I don't see a reason to continue investigating this as it then clearly isn't an issue with ntfs-3g itself.

Any performance issues can be reported in a separate issue (e.g. is performance equally poor in ntfs-3g and lowntfs-3g?).

[elandorr]

I thought it may be good to know to avoid the kernel guys doing whatever caused it again on accident. And @philstephenson's issue is uncertain. My kernel config is Debian's - modconfig + some specific non-FS things I want FYI.

Never even heard of lowntfs-3g, wow! That sure would've been interesting years ago. But why bother all the time because M$FT is hypocritical. For RE-ing, ntfs-3g is amazing. rclone managed a little better @1 thread (parallel is just seeking hell and slows it down even more, it's meant for "cloud"), but I want rsync because it's far lighter and handles linux-specific things. (rsync's blocksize was already maxed) This is documented on SO, not worth bothering you for a "fact of linux".

Have a good one

[elandorr]

lowntfs-3g has no ADS @ anyone finding this in the future.

(Used in e.g. Microsoft's incessant spyware-style metadata they dump on Every. Single. Download. Search term Zone.Identifier etc.)

[philstephenson]

I've got kernels 6.6, 6.7 and 6.8.5 installed. The first two are working as expected. 6.8 fails to boot with the error that it can't mount the drive. Removing the drive from fstab in 6.7 allows me to then boot into 6.8 but as described above I cant use fstab in any capacity. I'm struggling to find any other helpful messages other than the two I've previously posted from fuse and dmesg.

Also don't know why the command mount -t ntfs /dev/sdb1 /mnt/storage works and mount /dev/sdb1 /mnt/storage doesn't?

Running manjaro.

EDIT: I took the cowards way out and formatted the disk which I probably should have done years ago :D

[WheatleyFromPortal2]

Also having this issue with Manjaro-6.8.5-1 But it runs fine with 6.7.7-1 giving the error device or resource busy

[sunnybubblegum]

I just posted the following on Launchpad, which is where I came across the link to this GitHub issue.

I've been experiencing a similar issue since performing a fresh install of Ubuntu 24.04 LTS yesterday. While my external NTFS USB hard drive is recognized upon plugging it in, trying to mount it or access its contents gives me the 'wrong fs type, bad option, bad superblock' error.

I was able to get the external hard drive to mount via Terminal with the help of an article... https://linovox.com/how-to-fix-failed-to-mount-wrong-fs-type-bad-option-bad-superblock-on-linux/ ...however, its files are only accessible by navigating to my newly created /mnt/Media folder.

The drive is not visible in Nautilus, but I can see it in the Disks app (which is also how I unmount it). I get an error when trying to access its contents with the Steam app, specifically when I attempt to use the Restore Game Backup feature.

My external hard drive had been working fine with Ubuntu 22.04 a few hours earlier, and running a disk check said it was healthy.

[unsound]

I have now tested kernel 6.8.1 (or a downstream derivate, the Ubuntu 24.04 kernel) running in a VM and I cannot reproduce the issues reported here. I can mount devices using ntfs-3g with no issues as long as they aren't mounted by another filesystem driver (e.g. another ntfs-3g instance, the ntfs3 kernel driver, etc.). So I will close this issue until someone can provide a reproducible test case, but the notion that ntfs-3g doesn't work on 6.8 kernels is clearly wrong as this can be demonstrated easily. There's something else going on.

@sunnybubblegum What you're describing is not similar at all to the issue that we're discussing. From your description it looks like there's some sort of filesystem corruption. In this case Windows and chkdsk is (supposed to be) your friend.

[YHNdnzj]

As discussed in an Arch downstream issue, it appears that ntfs-3g is incompatible with the CONFIG_BLK_DEV_WRITE_MOUNTED=n kernel config introduced in 6.8. I suspect that this is how this issue came to be.

[elandorr]

@unsound Before closing just because you cannot reproduce an issue (after 1 attempt with an arbitrary downstream config) that I repeatedly reproduced, I'd suggest at least comparing our configs. Like I mentioned mine is pretty vanilla. New options are likely upstream defaults.

@YHNdnzj seems to have found the culprit, thank you!

The current config here indeed has CONFIG_BLK_DEV_WRITE_MOUNTED=y. (On 6.8.8 now, presumably this hasn't changed since my last successful attempt.)

With the plethora of new options in 6.8 it's possible I chose n after reading the description (sounds safer), don't recall. Usually I go with defaults. It certainly didn't occur to me that any could break ntfs-3g. Or they changed defaults.

I have no NTFS right now to test, but maybe someone else can confirm :-).

[unsound]

@YHNdnzj Thanks for the information, that very much sounds like the issue. Any FUSE filesystem that is backed by a block device is going to need its userspace daemon to be able to read/write a device that is mounted, as its mount is backed by that very userspace process. I think the maintainers of the FUSE subsystem need to ping the people that introduced this config option to figure out a solution. Either way I don't think that there's much that can be done from a userspace point of view when the kernel is configured this way. I might try to find time to test this for myself in practice.

[nsheff]

I'm also experiencing the same thing as @sunnybubblegum on a fresh install of ubuntu 24.04, trying to plug in an NTFS-formatted USB external drive that works fine in ubuntu 22. I'm using kernel 6.8.0-31

[sunnybubblegum]

Hi @nsheff thank you for speaking up about your NTFS external drive issue. If you're interested in chiming in, I've recently filed a bug report for the problem on Launchpad here. I ran the recommended bug-identifying tool and apparently the issue lies with the 'gvfs' package. Hopefully it will be addressed in the near future. Cheers!

[ZhoufangErqiangu]

i also got this issue on 6.8.0-35

[arxo]

think the maintainers of the FUSE subsystem need to ping the people that introduced this config option to figure out a solution. @unsound Would it make sense to file an issue at https://github.com/libfuse/libfuse/issues or is that the wrong place to raise awareness? Where should this be reported?