MX Linux Forum

I assume MX-25 is in development so I thought I would write down a few potential issues that maybe could be fixed out of the box.

1. PipeWire (battery drain) - I made this adjustment and haven’t had any issues.
viewtopic.php?t=81627

2. NTFS3 (potential FS corruption) - I blacklisted it in case Liquorix uses it. Debian kernels aren’t compiled with it. Linux Mint had to disable it in their main Ubuntu edition.
Some info, but Google will reveal that this is a widespread problem:
https://www.heiko-sieger.info/does-the- ... rectories/

NTFS-3g has withstood the test of time so not much need to use anything else IMO. Some background: ntfs3 (not ntfs-3g) may refuse to mount a non-clean ntfs file-system. This might be seen as a good security feature, but ntfs-3g has never given me any problems with ntfs and I dual boot with Windows.

What happened is that starting with mainline (and Ubuntu/Arch/Manjaro etc.) kernel 6.8 a lot of ntfs disk corruption began to happen. It turns out the mount parameters/instructions changed and this doesn’t work well. This might not be a problem for MX Linux if neither Debian nor Liquorix kernels enable ntfs3 by default.

I think this bug can be seen as one of the biggest in the history of both Ubuntu and Linux Mint although it’s actually an upstream kernel bug.

3. PipeWire (logout volume reset) - I haven’t tried this, but it would be nice if volume remained at the same level.
viewtopic.php?p=809242

I have found on your #3 ... if you remove audio group from your user, then you no longer have this issue.

Also interestingly ... this issue doesnt happen for MANY of the machines that I have setup.. only a few - such as my new machine! I can use and manipulate audio just fine without being in the group too.

Regarding #2, NTFS3 (potential FS corruption). The ntfs3 driver came from Paragon who were selling it as part of their commercial offerings, but donated it to the Open Source Community. IIRC, they claimed it was faster and safer than ntfs-3G. I can attest to it being faster on the times when I used it for a while, but I discovered it comes with greater sensitivity to Windows permissions and conditional state of NFTS partitions. it's the latter that causes the so-called damage because it's aware of it, but unlike Windows NFTS support, it is not able to work through it.

Windows will put up with 5-7000 minor inconsistencies, Paragon NTFS can barely handle a few, therefore it tires to protect the drive contents by disabling the write feature at the user level. When scanned with a Windows host, there are only a handful of inconsistencies, which is nothing in comparison to the thousands windows puts up with.

CharlesV wrote: Wed Feb 26, 2025 1:07 pm I have found on your #3 ... if you remove audio group from your user, then you no longer have this issue.

Also interestingly ... this issue doesnt happen for MANY of the machines that I have setup.. only a few - such as my new machine! I can use and manipulate audio just fine without being in the group too.

Hi,

That fix may work for general Desktop Users but for Audio Recording work it's essential for the User to be in the audio group or latency will suffer and some Audio Recording programs (Ardour and Harrison Mixbus for sure) will complain about the audio group permissions. Just sayin', hopefully the PW devs will have a more tenable solution.. MX-25 should have a much improved PipeWire version by the time Trixie goes Stable.

That makes sense... I record using audacity and various movie recording apps, and have not seen anything that complains, but it makes sense getting into higher levels of sound would.

The machines I encountered and before I learned about the audio group, it was simple to setup a script that just reset the audio levels on login. Simple, done.

m_pav wrote: Wed Feb 26, 2025 2:41 pm The ntfs3 driver came from Paragon who were selling it as part of their commercial offerings, but donated it to the Open Source Community. IIRC, they claimed it was faster and safer than ntfs-3G.

A lot of this boils down to the fact that the NTFS specification has never been openly published. To my knowledge NTFS is, was, and remains today a proprietary file system. Any driver you're going to find from any provider or project other than Microsoft is a best-guess, "your actual mileage may vary", no-guarantees, "we are not responsible for lost or stolen property", "use at your own risk" endeavor. NTFS support on Linux and UNIX has grown tremendously in the last 20 years or so and is a valuable feature for people who still have some Windows disks laying around, but I bristle at the idea of any third-party NTFS driver becoming a dependency for folks or an indicator of a Linux distribution's quality.

Every Linux distro is an amalgam of a number of different projects: a kernel plus an init system plus userspace tools. Not every component is flawless and not every combination of components interact flawlessly. This is one of those examples where just because some NTFS support is now possible doesn't mean NTFS is a first-class citizen in the Linux world, nor can it be relied upon in the same way as other file systems whose technical specs are known and which are endorsed by a maintainer entity who provides definitive driver support.

+1 @DukeComposed VERY well said!

ntfs3 is a kernel module, ntfs-3g is a userspace driver, as such ntfs3 is supposed to be much faster and that's my experience too. I haven't had problems with it, but it's possible that some people had, that being said I don't want to let FUD without concrete proof dictate our choices.

I would like to add a few new observations. The ntfs3 driver seems to be (still) misconfigured in mainline and latest Ubuntu kernels. For example kernel 6.14 in Ubuntu 25.04.
This bug was introduced with kernel 6.8.

It might be that the Liquorix kernels have correctly configured the ntfs3 driver even in kernels after version 6.8. I haven't tried the newer Liquorix kernels with ntfs3.

The potential problem now is that Debian will switch to enable ntfs3 by default in Trixie kernels. Maybe Debian will be able to configure it correctly. Maybe they won't if mainline and Ubuntu don't really care.
https://old.reddit.com/r/debian/comment ... ?rdt=41833
https://bugs.debian.org/cgi-bin/bugrepo ... bug=998627

My takeaway is that even a correctly configured ntfs3 driver is more sensitive than the ntfs-3g driver. I always value stability above speed but other people may have different needs.

Just a heads-up for people using the NTFS file system in their daily workflow.