Hi!! I have a CentOS 4.o install on some machine in my job. I need setting the system for read/write partition NTFS. I know the kernel-2.6.x this support is part of the kernel, but in CentOS this support is unaviable. How can aviable this support whit out recompiler kernel?? Some rpm packege for do that??
Regards, David
_________________________________________ Tec. David Gonzalez Romero Network/System Administrator CNAP- Centro Nacional Áreas Protegidas Linux counter: 242534 _________________________________________
On Tuesday 31 May 2005 13:52, David González Romero wrote:
Hi!! I have a CentOS 4.o install on some machine in my job. I need setting the system for read/write partition NTFS. I know the kernel-2.6.x this support is part of the kernel, but in CentOS this support is unaviable. How can aviable this support whit out recompiler kernel?? Some rpm packege for do that??
Maybe the RPMs at http://linux-ntfs.sourceforge.net/rpm/rhel4.html would work. Otherwise, you can easily build your own: http://linux-ntfs.sourceforge.net/rpm/build.html.
On Tue, 2005-05-31 at 14:01 -0400, Simon Perreault wrote:
Maybe the RPMs at http://linux-ntfs.sourceforge.net/rpm/rhel4.html would work.
Once again, see the "Release Notes" (linked to on that page): http://linux-ntfs.sourceforge.net/rpm/rel26.html#limitations
Otherwise, you can easily build your own: http://linux-ntfs.sourceforge.net/rpm/build.html.
There are issues with writing to NTFS volumes from anything but the same NT installation that created it. I encourage not only Linux users, but even MCSEs, to be aware of the severe limitations to NTFS' design.
This is not really a Linux issue, although Linux is trying to solve it as best as it can. Captive is pretty nice for older NTFSv4 volumes from NT4 installations, because Microsoft's "Dynamic Disc" option only works for NT5+ (and it still lets you trash ACEs and other meta-data).
Unless you like running head on against traffic, don't even think about writing NTFS files from Linux. Never let anything but Windows do the writes.
On my dual boot systems, I alwas include a small FAT32 partition for transfer of files between the two. Both OS can write safely to FAT32, and then you can transfer the files wherever needed.
But, in any case, on CentOS you need the unsupported kernel, because RedHat couldn't be bothered to include NTFS in the standard kernel.
Just my $.02
On Tue, 2005-05-31 at 19:39 -0600, Collins Richey wrote:
But, in any case, on CentOS you need the unsupported kernel, because RedHat couldn't be bothered to include NTFS in the standard kernel.
Well technically it would be illegal for them to because of the patent issues involved IIRC. It's not like they are lazy or something.
Paul
On Tue, 2005-05-31 at 19:39 -0600, Collins Richey wrote:
Unless you like running head on against traffic, don't even think about writing NTFS files from Linux. Never let anything but Windows do the writes.
Again, are you sure about that "Never let anything but Windows do the writes" (given my prior commentary)? @-ppp
Understand I'm not trying to "single you out." There's just a huge pool of MCSEs and other Windows administrators who have open skulls due to my "encounters" with them after they've roasted NTFS volumes because they either flopped disks around non-DCs, or promoted a system with lots of localized SAM meta-data on its NTFS volume to a DC.
In reality, there are two _really_good_ things about Linux when it comes to NTFS support:
1) You have a read-only driver option 2) Captive works fairly well (although slow) for what it was intended
With regards to #1, I can "safely" mount a NTFS volume read-only in Linux. In NT -- especially NT4.0 with a NTFSv4 -- it can get toasted because there's really no way to designate read-only. Furthermore, while NT5.1/XP is good about not allowing a NTFS volume created by another NT5.1/XP instance on a Basic Disc (legacy BIOS/DOS Disk Label aka Partition Table) to be mounted, that's not very helpful if you just want to read and get stuff off of it. ;->
Regarding #2, Captive allows fairly safe NTFSv4 writing -- something that NT4 can't do. And depending on how well Captive is running, it can even read the local SAM of an NT installation, providing better preservation of ACEs meta-data when you mount and modify than even NT5 on a Dynamic Disc.
The problem is NTFS itself, even on NT, not Linux at all.
<Tangent> NTFS has some serious issues with even NT -- and the work-arounds since the original NT3.1 are half-backed. This was supposed to have been addressed in NT4.0 "Cario" -- and then by the spin-off and promised "CairoFS Technology" once it was separated from NT4.0's release to make the date. Now we're seeing it yet again with NT6.0 "Longhorn" now renamed "WinFS Technology" (as part of other "WinFX Technologies" -- like some parts of the Indigo ".NET Services Sandbox" and Avalon 2.0 with MacOS X-like QuartzExtreme functionality have now been pushed out of NT6.0 "Longhorn"). </Tagent>
On my dual boot systems, I alwas include a small FAT32 partition for transfer of files between the two. Both OS can write safely to FAT32, and then you can transfer the files wherever needed.
But an additional problem can be geometry. NT4SP4 does not specify a standard geometry approach above 1024/63/255 Cylinder/Sectors/Heads = 8.4GB (8GiB) on the legacy BIOS/DOS Disk Label (i.e., the "Basic Disc" partition table format. I.e., it's not guaranteed to safe to dual-boot a system where FAT32/NTFS volumes are beyond the first 8.4GB of the disk.
Worse yet, NT5+ (2000+) doesn't either, as Microsoft assumes you would use a Logical Disk Manager (LDM) Disk Label (i.e., "Dynamic Disk"). Now using LDM solves these problems -- because not only can other NT5+ installations read the exact geometry assumed by another NT+ installation, but so can the Linux kernel (as of early 2.4.x, thanx to the Linux NTFS-LDM project).
Now until more recent NT5.1 service packs -- e.g., SP2 for XP, among many pre/post-hotfixes, I never ran into this under 137GB (128GiB). But as of SP2 as well as different hot-fixes, some even conflicting (just ask NetCell about those details, their ATA RAID cards have run into them ;-), I _never_ dual-boot NT/Linux where any FAT32/NTFS volume crosses 33.GB (32GiB).
Unfortunately, the user-space tools for partitioning (Parted) and booting (GRUB) aren't there to boot Linux on a LDM Disk Label. Sigh, so catch-22 on using LDM Disk Labels as standard. Hopefully LDM Disk Label support will be more commonplace in the near future. I'm fairly certain NT6.0 "Longhorn" will require LDM Disk Labels and drop the legacy BIOS/DOS Disk Label altogether (except for the fact that programs assuming such will see the former as the latter with a single, type 42h partition).
But, in any case, on CentOS you need the unsupported kernel, because RedHat couldn't be bothered to include NTFS in the standard kernel.
Wow! I actually responded above _before_ even reading this. I hope everyone, as well as yourself, can understand the "benefit" of understanding why something like this isn't enabled by Red Hat.
Which goes back to my whole thing of "explaining why" instead of making such statements like "couldn't be bothered."
Lack of write support actually has more to do with _real_ technical issues than anything else. Although I'm sure the reason why at least a read-only driver is not included as standard is probably legal-related. Barring the legal issues, I _do_ think the read-only driver should be included as standard.
Just my $.02
Well, I try to offer the knowledge I have. I'll leave it to others to either verify I am indeed correct, or assume that I pull it out of my rectum. Apparently my rectum seems to be a popular assumption. @-ppp
I _never_ dual-boot NT/Linux where any FAT32/NTFS volume crosses 33.GB (32GiB)
HUH? FAT32 problem??? My system has two 120GB disks and a 160 GB disk. The 120s have a 1GB DOS, a 24+GB NTFS, and a 84+GB FAT32 partition. I keep (almost) all of my data in the FAT32 partition. The first 120 is (fairly) regularly cloned onto the second. Since I upgraded my BIOS, I have never had any trouble accessing anything in either of the big FAT32 partitions from either the XP installation or any one of the various Linux installations (CentOS, WBEL, SUSE, Fedora core 3, or Yoper) on the 160GB disk.
At various times I have installed the NTFS code in a Linux installation, but when the NTFS crew's website says "read, but don't write" I believed them.
-mj-
Bryan J. Smith wrote:
On Tue, 2005-05-31 at 19:39 -0600, Collins Richey wrote:
Unless you like running head on against traffic, don't even think about writing NTFS files from Linux. Never let anything but Windows do the writes.
Again, are you sure about that "Never let anything but Windows do the writes" (given my prior commentary)? @-ppp
Understand I'm not trying to "single you out." There's just a huge pool of MCSEs and other Windows administrators who have open skulls due to my "encounters" with them after they've roasted NTFS volumes because they either flopped disks around non-DCs, or promoted a system with lots of localized SAM meta-data on its NTFS volume to a DC.
In reality, there are two _really_good_ things about Linux when it comes to NTFS support:
- You have a read-only driver option
- Captive works fairly well (although slow) for what it was intended
With regards to #1, I can "safely" mount a NTFS volume read-only in Linux. In NT -- especially NT4.0 with a NTFSv4 -- it can get toasted because there's really no way to designate read-only. Furthermore, while NT5.1/XP is good about not allowing a NTFS volume created by another NT5.1/XP instance on a Basic Disc (legacy BIOS/DOS Disk Label aka Partition Table) to be mounted, that's not very helpful if you just want to read and get stuff off of it. ;->
Regarding #2, Captive allows fairly safe NTFSv4 writing -- something that NT4 can't do. And depending on how well Captive is running, it can even read the local SAM of an NT installation, providing better preservation of ACEs meta-data when you mount and modify than even NT5 on a Dynamic Disc.
The problem is NTFS itself, even on NT, not Linux at all.
<Tangent> NTFS has some serious issues with even NT -- and the work-arounds since the original NT3.1 are half-backed. This was supposed to have been addressed in NT4.0 "Cario" -- and then by the spin-off and promised "CairoFS Technology" once it was separated from NT4.0's release to make the date. Now we're seeing it yet again with NT6.0 "Longhorn" now renamed "WinFS Technology" (as part of other "WinFX Technologies" -- like some parts of the Indigo ".NET Services Sandbox" and Avalon 2.0 with MacOS X-like QuartzExtreme functionality have now been pushed out of NT6.0 "Longhorn"). </Tagent>
On my dual boot systems, I alwas include a small FAT32 partition for transfer of files between the two. Both OS can write safely to FAT32, and then you can transfer the files wherever needed.
But an additional problem can be geometry. NT4SP4 does not specify a standard geometry approach above 1024/63/255 Cylinder/Sectors/Heads = 8.4GB (8GiB) on the legacy BIOS/DOS Disk Label (i.e., the "Basic Disc" partition table format. I.e., it's not guaranteed to safe to dual-boot a system where FAT32/NTFS volumes are beyond the first 8.4GB of the disk.
Worse yet, NT5+ (2000+) doesn't either, as Microsoft assumes you would use a Logical Disk Manager (LDM) Disk Label (i.e., "Dynamic Disk"). Now using LDM solves these problems -- because not only can other NT5+ installations read the exact geometry assumed by another NT+ installation, but so can the Linux kernel (as of early 2.4.x, thanx to the Linux NTFS-LDM project).
Now until more recent NT5.1 service packs -- e.g., SP2 for XP, among many pre/post-hotfixes, I never ran into this under 137GB (128GiB). But as of SP2 as well as different hot-fixes, some even conflicting (just ask NetCell about those details, their ATA RAID cards have run into them ;-), I _never_ dual-boot NT/Linux where any FAT32/NTFS volume crosses 33.GB (32GiB).
Unfortunately, the user-space tools for partitioning (Parted) and booting (GRUB) aren't there to boot Linux on a LDM Disk Label. Sigh, so catch-22 on using LDM Disk Labels as standard. Hopefully LDM Disk Label support will be more commonplace in the near future. I'm fairly certain NT6.0 "Longhorn" will require LDM Disk Labels and drop the legacy BIOS/DOS Disk Label altogether (except for the fact that programs assuming such will see the former as the latter with a single, type 42h partition).
But, in any case, on CentOS you need the unsupported kernel, because RedHat couldn't be bothered to include NTFS in the standard kernel.
Wow! I actually responded above _before_ even reading this. I hope everyone, as well as yourself, can understand the "benefit" of understanding why something like this isn't enabled by Red Hat.
Which goes back to my whole thing of "explaining why" instead of making such statements like "couldn't be bothered."
Lack of write support actually has more to do with _real_ technical issues than anything else. Although I'm sure the reason why at least a read-only driver is not included as standard is probably legal-related. Barring the legal issues, I _do_ think the read-only driver should be included as standard.
Just my $.02
Well, I try to offer the knowledge I have. I'll leave it to others to either verify I am indeed correct, or assume that I pull it out of my rectum. Apparently my rectum seems to be a popular assumption. @-ppp
Hi!! I have a CentOS 4.o install on some machine in my job. I need setting the system for read/write partition NTFS. I know the kernel-2.6.x this support is part of the kernel, but in CentOS this support is unaviable. How can aviable this support whit out recompiler kernel?? Some rpm packege for do that??
what about the centosplus repository unsupported kernel rpm?
Cheers, MaZe.
On Tue, 2005-05-31 at 13:52 -0400, David González Romero wrote:
Hi!! I have a CentOS 4.o install on some machine in my job. I need setting the system for read/write partition NTFS. I know the kernel-2.6.x this support is part of the kernel, but in CentOS this support is unaviable. How can aviable this support whit out recompiler kernel?? Some rpm packege for do that??
First off, read the Release Notes for the 2.6 RPM: http://linux-ntfs.sourceforge.net/rpm/rel26.html
Secondly, if you are looking for a "safer" way to write NTFS filesystems (especially for NT3/4), check out Captive: http://www.jankratochvil.net/project/captive/
One thing I find that not only Linux people are unaware of, but even MCSEs, is that modifying the meta-data (change in size, ACEs, etc...) of a NTFS volume is _dangerous_unless_ it's done by the same NT installation that created it. You normally shouldn't, even with the same version (but different installation) of NT!
Long story short, various meta-data in the NTFS volume rely on meta-data in the System Accounts Manager (SAM) part of the registry that created the NTFS volume. These are system-specific, except in the case of using domain objects. A domain (the controller portion) is essentially a "network-wide" SAM (even in ADS, although Kerberos is used for authentication, and the network-wide SAM is stored as part of the LDAP tree). This is why domain controllers (even in ADS) don't have local accounts -- and when you create a domain the first time, the local SAM of that first PDC (or DC in ADS) becomes the new "domain" SAM.
If you touch part of a NTFS filesystem that relies on SAM meta-data that is not a domain object (i.e., network-side SAM), then you can _trash_ the volume. This is not like UNIX where if you do not have a passwd/group/etc... entry you just get the "Raw" UID/GID/etc... And it's not just that Access Control Entries (ACEs) are lost. You can touch sensitive areas of the NTFS volume. Part of the reason for this "design" was to increase security, but in reality, it's really a "false security" and a major bug in NTFS' design.
Prior to NT5 (2000 on-ward), Microsoft blindly allowed different NT versions to mount NTFS volumes created by other . I've seen many people trash NTFS volumes moving them between systems. I've also seen the case where promoting a system with local SAMs to BDC or DC (ADS) status has cause it to trash it's own NTFS volumes (although the ADS-DC logic does more checking for this).
Starting with NT5, Microsoft does more sanity checking. E.g., install NT5.1 (XP) on two different hard drives (basic disc) with NTFS and they try to read each others. Disk Manager won't let you mount them from the other install -- not even read-only (even Linux allows this!). This is to protect you from trashing the other NTFS volume, because each NTFS volume relies on local SAM meta-data. The exception would be a member system/server trying to mount a DC's NTFS volume, the SAM is network- wide so all entries should be domain objects (unless it was promoted to a DC, and some old, local-only meta-data was around). That's why PDC/BDC and DCs (ADS) can move volumes between servers.
NT5 also introduces "Dynamic Discs" -- Logical Disk Manager (LDM) Disk Label (aka Partition Table format) -- another work around where basic SAM information is stored in hidden areas (along with other information, like geometry, volume sets/software RAID info, a journal of changes, etc... that a "Basic Disc" -- legacy BIOS/DOS disk label, LDM disk labels look like a single type 42h partition from DOS/NT3/4). Now it doesn't guarantee you won't trash the meta-data (like ACEs) on files when you mount a NTFS volume you didn't create with that NT5+ installation. But it _will_ prevent you from touching "sensitive" meta- data like critical FAT and other meta-data areas of the NTFS volume itself.
"Captive" under Linux is a combination of things. One is a ReactOS (NTkernel/NT clone) stub with WINE and wrapper for various NT components -- including a registry viewer/editor! That means you can far more safely read the local registry of a foreign NT installation so you can more safely read the NTFS volumes of that NT installation -- even on pre-NT5 NT installations. Of course, it's far from perfect, and it is user-space and _very_slow_. But it is a nice option to have.
In a nutshell, NTFS was _never_designed_ to be read by another NT instance than the one that created it. This is an inherit limitation to NTFS through version 5 (will NT6.0/Longhorn solve it? probably not). The workarounds include the network-wide SAM (domain) and, as of NT5+, the Dynamic Disc which can store key NTFS volume meta-data information in hidden areas of the disk label (partition table). Hopefully the NTFS-LDM project will reverse engineer this soon so we can have a faster, kernel driver.
But until then, Captive is actually safer than it, and works for NT4. But it's much, much slower.
-
Bryan J. Smith -
Collins Richey -
David González Romero -
Maciej Żenczykowski -
Mark Jarvis -
Paul -
Simon Perreault