Red Hat Bugzilla – Bug 65749
NTFS now cosidered acceptable and can should be enabled in Fedora's kernel
Last modified: 2015-01-28 11:27:20 EST
Description of Problem:
there is no ntfs module included with rh7.3, very annoying
Version-Release number of selected component (if applicable):
Steps to Reproduce:
is it still redhat's position that ntfs-readonly is broken as of kernel
so dear redhat do you plan to hear your customers or not?
do you want we all switch to another distribution? fix this!
I agree that ntfs-readonly support should be included by default at least as a
module in redhat installations. I know that myself and a couple of my
associates would find this extremely useful. NTFS support will become a larger
necessity as more people are using Windows XP, which by default uses NTFS. I
am sure many users would find built-in NTFS support extremely helpful.
oh believe me I would LOVE to enable ntfs... but it must be legally possible /
sensible to do so ;(
has redhat evaluated readonly-ntfs as of kernel 2.4.19? does it still cause data
corruption as claimed?
as far as I know it does no longer corrupt data read only
So, from what I gather, it is not legally possible to include NTFS support in
the default kernel provided with redhat? I was just wondering since it is
included in the kernel source.
I have been enabling it by compiling the kernel myself, but I was just
wondering why redhat didn't provide it since other distributions (mandrake) do
and I know of may people who find it useful. If there is a legal problem, then
Check out this page for a nice HOWTO to enable ntfs in redhat linux:
Arjan, what is the status of this request? If NTFS read-only is indeed safe, it
would be very nice if we could have this by default.
arjan please elaborate on the specific legal objections redhat has to including
Please check with lawyers about this. Inclusion of ntfs.o read-only would be
very useful in a future release.
*** Bug 61768 has been marked as a duplicate of this bug. ***
*** Bug 70571 has been marked as a duplicate of this bug. ***
*** Bug 77143 has been marked as a duplicate of this bug. ***
*** Bug 73793 has been marked as a duplicate of this bug. ***
*** Bug 84119 has been marked as a duplicate of this bug. ***
RHL9 includes rdekstop, which was built with reverse engineering of a MS
protocol; how is NTFS different?
redhat bundles samba which was also reverse engineered. omitting ntfs but
bundling samba+rdesktop seems odd.
can someone from redhat please state the exact legal objection redhat has to
ntfs, or give the exact contact information for the legal counsel at redhat that
is responsible for this conclusion? we are approaching 1 year since the question
was posed to redhat, and there is still no answer.
further: mandrake, gentoo, suse, lycoris all bundle read-only ntfs...
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/
*** Bug 135741 has been marked as a duplicate of this bug. ***
Reopening against Fedora Core 3, since closing this RFE as a "product
doesn't exist" is a huge copout.
The HOWTO mentioned doesn't exist. I get a 404 error on
You can get everything you want from
That includes full RW access to NTFS partitions (for the brave) or RO
access for mortals.
*** Bug 147318 has been marked as a duplicate of this bug. ***
After discussion with counsel, we deem the inclusion of NTFS in the Fedora project to be
too risky. Patent encumbrance.
*** Bug 154754 has been marked as a duplicate of this bug. ***
*** Bug 156253 has been marked as a duplicate of this bug. ***
*** Bug 157772 has been marked as a duplicate of this bug. ***
*** Bug 165632 has been marked as a duplicate of this bug. ***
*** Bug 166165 has been marked as a duplicate of this bug. ***
It seams that NTFS is no more in ForbiddenItems list →
Other ntfs related packages are allowed to be in Extras repo:
Can you enable now ntfs module, please? ntfs-3g is sometimes not an option (iso
images on ntfs partition and you want to perform installation from disk drive).
ntfs-3g supports loop mounts (mounting iso image on ntfs partition), moreover
you can also statically link it with dietlibc or uClibc and put into an initrd.
You can even use NTFS as your root filesystem (only in "single user" mode at
present). These are continuously tested and in use by several distros already.
(Moving this from FC3.)
Changing summary from "NTFS cannot be enabled in Fedora" to "NTFS now cosidered
acceptable and can should be enabled in Fedora's kernel" due to #30
Re-assigning to firstname.lastname@example.org
I'd like to see the ntfs driver enabled in the kernel-package now, too. I talked
to one ntfs driver developer and he said:
>If you want to loop-mount a file on NTFS, the kernel driver would be a
>Examples are putting using a swap file on "C:" (only the latest
>ntfs-3g support it, and it may dead-lock, although Szaka won't admit
>it). Another example that is not relevant for Fedora is saving the
>user settings of a live-cd.
>There is no doubt that the kernel driver is more stable. It only had
>bug fixes for some time. ntfs-3g is still under development. The
>kernel driver is also faster.
If the kernel-developers in Fedora don't want to enable it I'll propose a kmod
for Extras that contains the driver. This will look stupid, but it's known as
"forcing the issue" (quoting spot from the ntfs driver submission for Extras)
Swap on loopback on top of NTFS may deadlock. This is exactly the reason why
direct swap file support on NTFS was implemented recently (i.e. no need for
loopback to swap).
The read functionality of the kernel is stable, the limited write may have
serious problems, for example when truncating runlists. The two drivers share
quite many code, except ntfs-3g kept fixing bugs, added new features, and is
kept being extensively quality tested: http://www.ntfs-3g.org/quality.html
I'm not aware of any stability problem.
In my tests on different hardwares, the kernel driver is usually 20-40% faster
because ntfs-3g is not optimized yet.
In my opinion, the best would be, if the kernel driver were available too, so
anybody could decide himself which driver to trust and use.
(In reply to comment #34)
> In my opinion, the best would be, if the kernel driver were available too, so
> anybody could decide himself which driver to trust and use.
IMHO the very best would be if the 3G stuff would merge back into the kernel
driver, so everyone would have full r/w support at full speed...
(In reply to comment #35)
> IMHO the very best would be if the 3G stuff would merge back into the kernel
> driver, so everyone would have full r/w support at full speed...
Something like that is the long term plan of the upstream developers afaik, but
it will take some time to get done.
> Something like that is the long term plan of the upstream developers
> afaik, but it will take some time to get done.
At present there are three developers and they are working on their own
1. Anton Almaparmakov works closed source and plans the release a kernel
driver not earlier than spring of 2008.
2. Yura Pakhuchiy works on ntfsmount, merging some of the ntfs-3g code and
as he said "I implement things just for fun, no because anybody beside me
3. Szabolcs Szakacsits implemented recently full write support (he works on
Linux NTFS support for almost 5 years), and being unsatisfied with the
nature, quality and progress of the other two approaches, he established
recently the NTFS-3G project and doesn't plan to port it to the kernel
because of http://www.ntfs-3g.org/support.html#kernel
Running a lot of complex code unpriviledged in user space with close to
native kernel speed has some advantages. For example the recent NTFS kernel
driver denial of service exploit at
http://projects.info-pull.com/mokb/MOKB-19-11-2006.html doesn't work with
ntfs-3g at all, and given that it worked, then it would have been a less
serious, unpriviledged security compromise.
Fedora 7 test 4 still doens't have any ntfs support by default! And any ntfs
partitions go unrecognised during anaconda install process!
This is very sad when all other major linux distros have ntfs support resolved
long time ago...
I believe ntfs-3g is available in default repos (Extras for fc =< 6).
If it is not on by default then it doesn't even count.
What are you going to tell to your neighbor when she/he downloads this great
thing called Fedora 7 that she/he heard about and when on installation it
doesn't show data from his old system (ntfs)?
Are you going to say to she/he: "I believe ntfs-3g is available in default repos
(Extras for fc =< 6)." ?!?
How many ms will she/hr think after you say that to her/him and convert Fedora
CD/DVD to something much useful - like coaster :)
Nope, until anaconda doesn't detect and support ntfs partitions by default this
is a major issue Fedora has!
Please look at Linux Mint and how they dealt with ntfs. It works automatically!
And this is what most users need/want.
I asked for anaconda RFE so it mirrors ntfs support in fedora:
ntfs-3g gets installed by default both in Fedora 8 and Fedora development. Look into
In both cases ntfs-3g is enabled by default in "Base" group.
Clicking on "Computer" in my GNOME desktop shows Windows Vista ntfs partitions.
Can you reproduce this bug in a default installation of Fedora 8?
It works ok in both Fedora 8 and Rawhide.
Seems to be a bug in the current update of Fed20. when I install it I get a nonsense message that the update conflicts with itself, so it continues to attempt the update whenever I log on.
Test Transaction Errors: file /usr/bin/ntfs-3g conflicts between attempted installs of ntfs-3g-2:2014.2.15-8.el6.x86_64 and ntfs-3g-2:2014.2.15-8.el6.x86_64
file /usr/bin/ntfsmount conflicts between attempted installs of ntfs-3g-2:2014.2.15-8.el6.x86_64 and ntfs-3g-2:2014.2.15-8.el6.x86_64
(In reply to olinart from comment #44)
> Seems to be a bug in the current update of Fed20. when I install it I get a
> nonsense message that the update conflicts with itself, so it continues to
> attempt the update whenever I log on.
> Test Transaction Errors: file /usr/bin/ntfs-3g conflicts between attempted
> installs of ntfs-3g-2:2014.2.15-8.el6.x86_64 and
> file /usr/bin/ntfsmount conflicts between attempted installs of
> ntfs-3g-2:2014.2.15-8.el6.x86_64 and ntfs-3g-2:2014.2.15-8.el6.x86_64
Man, I don't want to know why you're trying to install packages built for RHEL/Centos 6 (.el6) on Fedora 20, but I'm a little bit glad yum isn't letting you do that. I think you're doing something very wrong here, and you should take a very hard look at how you have that Fedora 20 system configured.