Fuse reported filesystem type is fuseblk, it should be fuse.ntfs

[meven]

cat /proc/mounts with fuse mounted ntfs will report the fs type of the block is fuseblk. This makes it hard to distinguish the fuse mounts from other kinds (fuse.nfs ...).

This causes issues downstream like https://bugs.kde.org/show_bug.cgi?id=451408

Please consider make the fuse ntfs driver report a more descriptive filesystem type, like fuse.ntfs or fuseblk.ntfs

https://github.com/tuxera/ntfs-3g/search?q=fuseblk

[jpandre]

This is a fuse issue, AFAIK ntfs-3g cannot do anything about it, unless fuse implements some interface for it. You should probably report to https://github.com/libfuse/libfuse/issues

[meven]

The issue seems to be that fsname option is not to fuse_mnt_add_mount but whatever mounts ntfs drive, I am not sure what daemon or system handles this, probably udisk2. In some cases, it works like the xdg-portal case.

[Vogtinator]

This is a fuse issue, AFAIK ntfs-3g cannot do anything about it, unless fuse implements some interface for it.

The libfuse interface for that is fuse_parse_cmdline, which sets the subtype= option (fsname on FreeBSD) to the basename of the program by default. If you can't use fuse_parse_cmdline, you can just hardcode subtype=ntfs-3g as mount option.

[jpandre]

you can just hardcode subtype=ntfs-3g as mount option.

Interesting, thanks. Just checked with libfuse3 and this works, but ntfs-3g usually uses fuse-lite which does not support this option.

Anyway, I am having this set up for a later version.

[Vogtinator]

you can just hardcode subtype=ntfs-3g as mount option.

Interesting, thanks. Just checked with libfuse3 and this works, but ntfs-3g usually uses fuse-lite which does not support this option.

Apparently it was explicitly removed: https://github.com/tuxera/ntfs-3g/commit/f56ee252c76b5466fb4ffe7a466c1c5a8e0b047a

Anyway, I am having this set up for a later version.

[unsound]

One concern: If we set the subtype option by default it might break existing scripts and setups which match mounts by the fstype 'fuse' or 'fuseblk' exactly (not by prefix). If we do consider making it a default option, not set by the mounter then we should also need to make sure that it can be disabled (having a nosubtype option maybe?).

[Vogtinator]

One concern: If we set the subtype option by default it might break existing scripts and setups which match mounts by the fstype 'fuse' or 'fuseblk' exactly (not by prefix).

That would be broken anyway. If the goal is to get ntfs3g mounts, it would also match non-ntfs3g fuse(blk) mounts. If the goal is to match all fuse(blk) mounts, then it would miss the majority of them.

[jpandre]

I am reopening the issue as more examination is needed.

For instance, what about an external disk plugged in and mounted automatically ?

[unsound]

@Vogtinator:

One concern: If we set the subtype option by default it might break existing scripts and setups which match mounts by the fstype 'fuse' or 'fuseblk' exactly (not by prefix).

That would be broken anyway. If the goal is to get ntfs3g mounts, it would also match non-ntfs3g fuse(blk) mounts. If the goal is to match all fuse(blk) mounts, then it would miss the majority of them.

Broken or not, such scripts may exist so it makes sense to have the option to revert the change in behaviour.

[ahmadsamir]

For an NTFS partition, mounted as fuseblk (as reported by stat / statfs / /proc/ self/mountinfo), if that partition is on a local disk, then can we assume that it'll use the sd driver, and will have a device node /dev/sdXY?

If so, then we can test for that, and it would at least partially solve the issue in KDE's KIO.

[sedimentation-fault]

As someone who has just finished writing a script that needed the type of a mounted NTFS partition, I can tell you that this situation is unbearable. Please correct it. I am sure you can. And I don't care if I would have to "correct" my own script, since the correction would remove the extra case I had to program for NTFS. Because instead of the simple (and fast!)

partition_fs_type="$(cat /proc/mounts | grep "$part" | awk -e '{print $3}')"

I now have to take the route through blkid -o full mounted-partition as in

mounted_dev="$(mount | grep "$part" | awk -e '{print $1}')"
partition_fs_type="$(blkid -o full "$mounted_dev" | sed -e 's/.* TYPE="\([^"]*\)".*/\1/')"

(Here part is the partition name, e.g. sdk1, while mounted_dev might be something like /dev/mapper/XXX)

BTW the blkid method is the only way I have found that will compute 'ntfs' as the filesystem type of a given NTFS-formatted partition.

See also the long, painful discussion for this should-be-painless issue at

NTFS partition reported as fuseblk

[ahmadsamir]

FWIW, the solution we found for KDE's C++ code was to use libudev: https://invent.kde.org/frameworks/kcoreaddons/-/commit/88e36daf68708aa84323ba8e79ac5c0b0a764ee4#aa91acce252f0cf4003f2b259845a744f5d96434_123_133

[sedimentation-fault]

@ahmadsamir In that commit it says

// Code originally copied from util-linux/misc-utils/lsblk.c

So you use code from lsblk. I use blkid to determine filesystem type (including 'ntfs') in the code I posted above. Both utilities are part of the same package: util-linux. So we are talking about the same method, you in the code, me on the command line. :-)

[ahmadsamir]

@ahmadsamir In that commit it says

// Code originally copied from util-linux/misc-utils/lsblk.c

So you use code from lsblk. I use blkid to determine filesystem type (including 'ntfs') in the code I posted above. Both utilities are part of the same package: util-linux. So we are talking about the same method, you in the code, me on the command line. :-)

Yep, I mainly posted that link for those who need a C++ solution of this issue :)

[unsound]

Posting a proposed patch for this issue, appending the subtype 'ntfs-3g' by default. Feedback appreciated. 0001-Append-subtype-option-to-ntfs-3g-default-options-on-.patch

[meven]

Posting a proposed patch for this issue, appending the subtype 'ntfs-3g' by default. Feedback appreciated. 0001-Append-subtype-option-to-ntfs-3g-default-options-on-.patch

Make it a PR ;), it is way easier to discuss that way.