Bug 2535834

Summary:	[7.2.6 regression] Please restore NTFS3
Product:	[Fedora] Fedora	Reporter:	Artem S. Tashkinov <aros>
Component:	kernel	Assignee:	Justin M. Forbes <jforbes>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	44	CC:	acaringi, adscvr, agurenko, airlied, belegdol, hans, hpa, jforbes, kernel-maint, linville, masami256, mchehab, nickolasjcarr, ptalbert, steved, suraj.ghimire7
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-09-19 07:07:33 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Artem S. Tashkinov 2026-09-17 07:28:10 UTC

I am extremely upset that the NTFS3 module appears to have been dropped without any meaningful discussion, vote, consensus, or clear migration plan.

NTFS3 is not some abandoned or experimental driver:

* It is still supported and maintained.
* It is a known quantity with substantial real-world use.
* Existing systems, including users' `/etc/fstab` configurations, may explicitly depend on it.

After booting into kernel 7.2.6, every one of my NTFS partitions failed to mount. That is a serious regression.

The revived NTFS driver is not an equivalent drop-in replacement at this point:

* Write support was only added relatively recently, and there is not yet enough real-world experience to have the same confidence in its data integrity.
* Kernel stability is also a concern; filesystem-driver bugs can result in crashes or panics, not merely failed mounts.
* It simply has not been battle-tested to the same degree as NTFS3.

Removing a _mature_, actively maintained filesystem driver and effectively forcing users onto a less-proven replacement is an _extraordinarily aggressive change_, especially when it can _break existing installations_ immediately at boot.

I am frankly appalled that a change with this kind of compatibility and data-integrity impact was allowed to land this way.

Please restore NTFS3, or at the very least provide a clear technical justification for its removal, the process by which this decision was made, and a documented migration path for existing users.

Comment 1 Artem S. Tashkinov 2026-09-18 06:38:13 UTC

Both filesystems can be enabled simultaneously as modules. There's nothing in the kernel preventing this:

    
 .config - Linux/x86 7.2.6 Kernel Configuration
 → File systems → DOS/FAT/EXFAT/NT Filesystems ──────────────────────────────────────────
  ┌────────────────────────── DOS/FAT/EXFAT/NT Filesystems ───────────────────────────┐
  │  Arrow keys navigate the menu.  <Enter> selects submenus ---> (or empty submenus  │  
  │  ----).  Highlighted letters are hotkeys.  Pressing <Y> includes, <N> excludes,   │  
  │  <M> modularizes features.  Press <Esc><Esc> to exit, <?> for Help, </> for       │  
  │  Search.  Legend: [*] built-in  [ ] excluded  <M> module  < > module capable      │  
  │ ┌───────────────────────────────────────────────────────────────────────────────┐ │  
  │ │    <M> MSDOS fs support                                                       │ │  
  │ │    <*> VFAT (Windows-95) fs support                                           │ │  
  │ │    (866) Default codepage for FAT                                             │ │  
  │ │    (utf8) Default iocharset for FAT                                           │ │  
  │ │    [*] Enable FAT UTF-8 option by default                                     │ │  
  │ │    <M> exFAT filesystem support                                               │ │  
  │ │    (utf8) Default iocharset for exFAT                                         │ │  
  │ │    <M> NTFS file system support                                               │ │  
  │ │    [*]   NTFS debugging support                                               │ │  
  │ │    [*]   NTFS POSIX Access Control Lists                                      │ │  
  │ │    <M>   NTFS Read-Write file system support                                  │ │  
  │ │    [ ]     64 bits per NTFS clusters                                          │ │  
  │ │    [*]     activate support of external compressions lzx/xpress               │ │  
  │ │    [*]     NTFS POSIX Access Control Lists                                    │ │  
  │ │                                                                               │ │  
  │ │                                                                               │ │  
  │ │                                                                               │ │  
  │ │                                                                               │ │  
  │ │                                                                               │ │  
  │ └───────────────────────────────────────────────────────────────────────────────┘ │  
  ├───────────────────────────────────────────────────────────────────────────────────┤  
  │             <Select>    < Exit >    < Help >    < Save >    < Load >              │  
  └───────────────────────────────────────────────────────────────────────────────────┘

Comment 2 Artem S. Tashkinov 2026-09-18 06:40:15 UTC

I've sent a follow-up email to Justin asking about this but he hasn't replied.

Comment 3 Julian Sikorski 2026-09-18 20:46:14 UTC

Looks like the fix is incoming: https://gitlab.com/cki-project/kernel-ark/-/commit/972da12cd3519373902f7c6e6e2bcaf8570dc15b

Comment 4 Artem S. Tashkinov 2026-09-19 07:07:33 UTC

(In reply to Julian Sikorski from comment #3)

Thanks!

And thank you Justin! Really appreciate the revert.