i just installed Rocky , it looks fine , but i noted that NTFS support is not available by default , the NTFS packages are not installed and not available on the default Repositories :
Rocky Linux 8 - AppStream
Rocky Linux 8 - BaseOS
Rocky Linux 8 - Extras
i had to manually add ELrepo to install the required packages , and i am wondering why ? i mean what is the reason that those packages are not considered part of the common Extras - for example ?
because of that , the grub installer does not consider adding the Windows installation coexisting on the host to the Grub menu , thus disallowing the user to boot into his Windows box ! thus he will have to add NTFS support with the below packages :
then use os-prober to confirm that it can see the Windows OS on NTFS partition , then follow it by
[root@Galagar ~]# grub2-mkconfig --output=/boot/grub2/grub.cfg
Generating grub configuration file …
Found Windows 10 on /dev/sda1
done
[root@Galagar ~]#
now reboot and check the new grub menu , confirm that you can boot into your Windows OS
Second, the grub.cfg is in /boot/grub2/ only if you still use legacy mode for booting. EFI mode has bootloaders in FAT32; in the EFI System Partition. I was confused when I had to install (CentOS 7) dual boot on legacy system, precisely due to the NTFS issue. The confusion must have been due to not having encountered the same issue in EFI systems. (In EFI system you don’t need entry in Grub menu at all; you can select bootloader in EFI.)
Thank you for the correction and for the comment
yes , i am running in legacy mode
i was just comparing that to other releases that have NTFS support included as a default , possibly because of their Desktop nature , thank you for the article as well
I have a 1TB ntsf volume containing data files that I want to access from both linux and windows systems on my local network. I don’t need or want dual boot.
I do need and want a way to mount this ntfs volume.
Yes, but that’s slightly different, and the wording isn’t clear enough. e.g. “access over the network” implies having a shared drive with multiple computers accessing it at the same time, one trying to write a file, at the same time the other is trying to read it - not good.
I understand the complexity of network fileshares – that problem has been more or less solved for a very long time.
The first step towards using any of those solutions is to mount a volume so that the RL system can read and write it.
I already have an existing volume with about 1TB of files that other computers want to access. Many of these are media files that will be read by something something like VLC media player on some local machine. Those local machines will want to store newly downloaded media files onto the same volume.
My point remains that my purpose for mounting this ntfs volume is NOT for dual-booting anything. I want to instead mount it so that I can then (separately) make it available to machines on my local network.
Understood. I encountered this topic while researching how to add ntfs support in my situation. I just wanted to clarify that the issue with ntfs support extends beyond the need you addressed in your excellent answer.
Heh – and “back then” (March of 2022) still seems relevant.
OK, so let’s say you are able to mount it, how are you then going to “make it available” to the other machines, and at the same time prevent Rocky from accessing it directly and corrupting it? Either way, NTFS is not a good choice for this.
The other “simple” use case is where you just want to access an existing NTFS volume from Rocky locally, without making it available to anything, so you can get everthing off it as quickly as possible, and onto an open standards file system.
In this case (as mentioned above), you can install the ntfs driver from epel.
Example:
dnf --enablerepo "epel" install ntfs-3g.x86_64
then to mount (assuming GUI and standard user)
gio mount -d /dev/sdb3
Mounted /dev/sdb3 at /run/media/<user>/Media
it will appear in nautilus
unmount later, either just log off, or
I’ve been locally sharing a ntfs partition with a windows VM for ten years on a Fedora machine w/o any evidence of corruption. VM runs quicken which will only save to a ntfs formatted or fat formatted drive. No app on Fedora opens the quicken files and no app on the VM opens any of the other files stored there so there is some inherent usage pattern that provides some isolation. I have not seen any issues regarding ntfs on the fedora forum and from other posts there folks seem to be using the ntfs modules to mount their Win10 files in dual boot arrangements.
FWIW, on a different thread I described the apparently still outstanding issue with ntfs-3g on RL v8.6 – at least on my hardware. Specifically, it breaks the SATA controller on my (old) hardware.
I therefore already know that that specific package is not an option for me.