Arch Linux

jadren

Member

Registered: 2026-05-13

Posts: 3

[SOLVED] Remove hardcoded mount.ntfs symlink in ntfs-3g to unblock n

Subject: [Proposal] Remove mount.ntfs symlink from ntfs-3g for Linux 7.1+ native driver

Hi everyone,

With the release of Linux 7.1, the new native NTFS driver has been officially merged into the mainline kernel. It directly takes over the ntfs filesystem type (unlike the previous ntfs3).

The Problem:
Currently, the ntfs-3g package in the Arch repositories hardcodes a symlink in its PKGBUILD:
ln -s /usr/bin/ntfs-3g /usr/bin/mount.ntfs

Because of this symlink, any standard mount -t ntfs command is automatically hijacked and forced to use the user-space FUSE driver (ntfs-3g). This completely bypasses the new, high-performance in-tree kernel driver for anyone running Linux 7.1 or newer.

Proposed Solution:
Drop the symlink entirely from the ntfs-3g PKGBUILD. > This aligns with the KISS principle and allows the kernel to handle ntfs mounts natively. Users who still explicitly want or need FUSE can simply use mount -t ntfs-3g.

Note: I originally considered writing an adaptive wrapper script to parse uname -r and fallback to FUSE for LTS/older kernels, but I realized this goes against Arch's packaging philosophy and adds unnecessary maintenance overhead.
see here(last commit):
https://gitlab.archlinux.org/jadren/ntfs-3-g

Testing:
I've tested dropping the symlink locally via loop devices. It correctly routes to the native ntfs driver on 7.1.0-rc2-1-cachyos-rc, and standard ntfs-3g functionality remains unbroken for explicit FUSE mounts.

I'd love to hear the maintainers' thoughts on this. If dropping the symlink is the right way forward, I am ready to open an MR on GitLab.

Last edited by jadren (2026-05-13 16:27:49)

WorMzy

Administrator

From: Scotland

Registered: 2010-06-16

Posts: 13,631

Website

Re: [SOLVED] Remove hardcoded mount.ntfs symlink in ntfs-3g to unblock n

You'll need to open a feature request on the gitlab instance. Devs don't often peruse the support forums.

https://gitlab.archlinux.org/archlinux

Good luck.

---

Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

jadren

Member

Registered: 2026-05-13

Posts: 3

Re: [SOLVED] Remove hardcoded mount.ntfs symlink in ntfs-3g to unblock n

There has been an issue.
https://gitlab.archlinux.org/archlinux/ … rk_items/2
SSorry for my noise and the unnecessary trouble this has caused.

jadren

Member

Registered: 2026-05-13

Posts: 3

Re: [SOLVED] Remove hardcoded mount.ntfs symlink in ntfs-3g to unblock n

I have turned to GitLab for dev support. Thanks

Patrass

Member

Registered: 2026-08-10

Posts: 1

Re: [SOLVED] Remove hardcoded mount.ntfs symlink in ntfs-3g to unblock n

Hello,

I have encountered what appears to be a recurrence of the `$BadClus (-22)` ntfs3 issue previously reported in this thread:

https://bbs.archlinux.org/viewtopic.php?id=301270

There is also the recent 2026 discussion about the new native `ntfs` driver in Linux 7.1+ and the `mount.ntfs` symlink created by ntfs-3g:

https://bbs.archlinux.org/viewtopic.php?id=313530

My case is slightly different because I can now compare `ntfs3` and the new kernel `ntfs` driver on the **same physical NTFS volume**.

### System

* CachyOS
* kernel: `7.1.6-1-cachyos`
* x86_64
* Kingston KC3000 2 TB
* NTFS 3.1

User-identifying information, UUIDs, serial numbers, IP addresses and other private information have been removed.

### ntfs3 failure

Mounting with:

```text
sudo mount -t ntfs3 /dev/nvme1n1p1 /mnt/gry
```

fails.

Relevant `dmesg` output:

```text
ntfs3(nvme1n1p1): Mark volume as dirty due to NTFS errors
ntfs3(nvme1n1p1): Failed to load $BadClus (-22)
```

### Windows verification

The same partition was checked under Windows 11 Pro 25H2 using:

```text
chkdsk D: /f
```

Windows reported:

```text
Windows has scanned the file system and found no problems.
No further action is required.
```

There were no reported bad file records, unindexed files or bad sectors.

CrystalDiskInfo also reports the SSD health as 100%, with no critical or uncorrectable errors.

### ntfsfix

On Linux:

```text
sudo ntfsfix -n /dev/nvme1n1p1
```

returned successfully:

```text
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition ... was processed successfully.
```

No repair was performed because `-n` was used.

### ntfs-3g

The same volume mounts successfully using:

```text
sudo mount -t ntfs-3g /dev/nvme1n1p1 /mnt/gry
```

and is fully accessible.

`ntfs-3g.probe --readwrite` also returns exit status 0.

### Native kernel ntfs driver

After discovering the `mount.ntfs -> ntfs-3g` helper, I explicitly tested the new kernel driver.

After:

```text
sudo modprobe ntfs
```

I used:

```text
sudo mount -i -t ntfs /dev/nvme1n1p1 /mnt/gry
```

This successfully mounted the same volume.

`findmnt` reports:

```text
FSTYPE ntfs
```

rather than `fuseblk`.

The complete filesystem is accessible.

### Read/write test

After configuring appropriate mount ownership options, normal read/write operations work with the native kernel driver:

```text
touch /mnt/gry/test_ntfs.txt
ls -l /mnt/gry/test_ntfs.txt
rm /mnt/gry/test_ntfs.txt
```

All three operations succeed.

### fstab and reboot

I also configured the native kernel `ntfs` driver through `/etc/fstab`.

The UUID and user-specific values are redacted here:

```text
UUID=<REDACTED> /mnt/gry ntfs rw,uid=<REDACTED>,gid=<REDACTED>,umask=0002,iocharset=utf8,errors=continue 0 0
```

After:

```text
sudo systemctl daemon-reload
sudo umount /mnt/gry
sudo mount -a
```

the volume mounted as:

```text
FSTYPE ntfs
```

I then rebooted the system.

After reboot, without manually mounting the partition:

```text
findmnt /mnt/gry
```

confirmed that the volume was automatically mounted through `fstab`.

The read/write/delete test also succeeded after reboot.

### Summary

The results on the same physical NTFS volume are:

```text
Windows 11 / chkdsk       -> OK
CrystalDiskInfo           -> SSD health 100%
ntfsfix -n                -> OK

ntfs3                     -> FAIL
                             Failed to load $BadClus (-22)

ntfs-3g                   -> OK

native kernel ntfs        -> OK
native ntfs + fstab       -> OK
native ntfs after reboot  -> OK
read/write/delete         -> OK
```

So the interesting part of this case is not the `mount.ntfs` symlink issue discussed in the 2026 thread. That part is already understood.

The interesting observation is that **the same NTFS volume which `ntfs3` rejects because of `$BadClus (-22)` is successfully mounted and used read/write by the new native kernel `ntfs` driver on Linux 7.1.6.**

This also seems related to the older 2024 report mentioned above, where `ntfs3` produced the same `$BadClus (-22)` error while Windows and `ntfsfix` did not report a filesystem problem.

### Questions

Could this indicate that `ntfs3` is handling the `$BadClus` metadata differently from the new native `ntfs` driver?

Is there any additional diagnostic information that would be useful for determining why `ntfs3` returns `-22` for this volume?

Would this be worth reporting as an ntfs3/kernel bug?

I am currently using the native kernel `ntfs` driver as a workaround. It works correctly, including automatic mounting through `fstab` after reboot.

The troubleshooting was performed interactively with the assistance of ChatGPT, while all commands and results reported above were obtained from the actual system.

Thank you.