One can comfortably use NTFS to read and write files on modern Linux distributions, but NTFS in general is not very suitable for running applications on or using for long-term usage between a dual-boot. Windows can and will often lock up NTFS partitions whenever it decides to hibernate rather than shutdown or sometimes suspend. NTFS while not being the greatest FS in general will also have worse performance on Linux than Windows. You can totally keep data stores on a Linux system, though you won't be able to make use of many of the advanced features some Linux/BSD-oriented filesystems offer. You can totally keep your drives as they are now, though if you intend to make a full switch you should consider migrating your drives' data over to more Linux-oriented filesystems (be it Btrfs, Xfs, or Ext4 is your choice depending on the features you want). In short, NTFS works but lacks a lot of features and performance that a more suitable filesystem would offer.
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Windows will also sometimes leave NTFS filesystems in a dirty state on shutdown and fixes them silently when it starts back up. But it you boot Linux in the meantime the filesystem will appear messed up and you'll have to use ntfsfix if you want to mount it.
I've done this (shared 3 NTFS partition in a dual boot setup) from 2017 to the end of 2023 without issues.
The trick was to disable "fast startup" and hibernation. Otherwise Windows happily shuts down with the file systems in an inconsistent state. It's just a question whether one can live with that in their Windows install.
Windows ext4 compatibility is awful. I have my steam library on an ext4 partition, and occasionally boot to windows for specific games that don't work in linux. I tried mounting my ext4 partition using WSL (which worked fine), adding the steam lib folder to steam (worked fine), but all the games wanted to be verified before being run, and then i finally started one and got a BSOD. I thought maybe steam might complain that some files were wrong, but I didn't expect that lol. But at least steam tried, Epic launcher just flat out refused.
I haven't tried btrfs in windows, I see WinBtrfs exists, I wonder how well it works.
Windows doesn't have ext4 compatibility. When you mount a Linux partition through WSL you aren't actually mounting the drive itself, you are booting a VM up and piping all I/O through that VM back to an emulated disk device on the host windows OS
You would be better off having your steam library on an NTFS partition - at least your Linux OS can read the drive natively
Yeah, but then I end up in all the threads about steam for linux having issues with NTFS.
It doesn't have issues. It just doesn't work. You need your library on ext3/4 for the games to run on linux.
For what it's worth I've never had an issue launching a game from a library on my NTFS partition
I never managed, I used Linux Mint, but I didn't bother to try others.
In general, Microsoft doesn't support many filesystem formats at all. In the same way you shouldn't attempt to cross-run a steam library from Windows on Linux, you really shouldn't do from Linux to Windows. It's in part due to how permissions, execution flags, filesystem case sensitivity, file metadata, is interpreted by Windows applications vs. Unix-like applications. There will be issues going either way when using foreign filesystems in complex tasks.
While it should be expected that the files will have the same contents where they are actually the same (i.e. a Proton game will be the same as a Windows game as it comes from the same steam depot), there is a good chance that translation of interpretation isn't to be 1:1 on either side. Furthermore with using Steam libraries, Steam includes additional data beyond just the game files, which is likely why they are invalidated. A significant portion of visible cross-os portability issues is due to many applications like Steam using OS-specific file structures. More than likely Steam is going to intentionally make the library metadata not fully compatible between Linux and Windows Steam and force validation before launch because there is a good chance the games aren't even compatible builds or otherwise have additional compatibility content dragged along (such as Proton WINE prefixes that are to be completely ignored when launching from actual Windows or having additional libraries, modded executable binaries that have platform-oriented patches).
If you seriously want to run a cross-share of a Steam Library between Linux and Windows, you should really utilize Steam Cloud save. If you want to "deduplicate" your games, your best bet would be if you can open the foreign fs and have a compatible copy of the game, to simply clone the game files to the current filesystem and remove from remote rather than attempt to force a multi-os single-partition shared library. You are less likely to destroy your Steam library if you treat the actual libraries separate, but move the games like they were downloaded externally. Barring being able to do that, just don't cross-share games. Simply reboot into the OS that has the game you want to play instead.
I accept that the powers-that-be don't want me to do it, I understand that the foolproof user experience is to just play a game made for windows on windows, but if that's how we lived, none of us would be gaming on linux in the first place.
Outside of the download/update of a game, the files should be read only. As long as the files have the right data in them for a given OS, and the OS has proper support to read the files, then I should be able to load them and execute them. Any little permissions or metadata quirk that prevents that from happening is a bug as far as I'm concerned.
I'm in the same boat. I've ended up using Paragon's commercial ext4 drivers ($20) and while they absolutely work, they're case sensitive and many Windows apps (especially Bethesda games) open their files with random upper/lowercase spellings that don't match the files.
NTFS-3G on Linux is very stable, and I'd recommend sticking to that, although I'd avoid the newer NTFS3 driver.
But if you really want to convert, and it's data that you don't mind loosing, ntfs2btrfs can convert NTFS partitions to BTRFS, and it's available in most distros' repositories.
Thats amazing... now what to try it on?
It worked fine last time I used it. For external drives, not the OS please
Also have a look at UDF and exFAT.
Please do not use exfat on anything critical. It is slow as hell, it does not have journal or CoW to ensure consistency on unintended shutdown, and is designed to be extremely simple to implement, not robust. Good for flash drives and sd cards, but not normal storage.
Now I want to try that though. As long as it's baked in to the kernel it should theoretically work..
http://en.wikipedia.org/wiki/NTFS#Linux
Lots of different drivers, basically all reverse engineered. Different actions supported, macOS doesnt give a f* and just supported read (at some time some user wrote that) and Linux had no support for some advanced functions that are unstable.
The latter scenario could lead to a filesystem being corrupted and thus not usable, as it has no full compatibility.
Like, it is probably possible but just no. You are using reverse engineered drivers and there are better alternatives that are more stable (nouveau, Asahi, always exceptions).
The new kernel driver is a mess and isn't really being maintained. The FUSE driver is the only one that's actually usable and even then, it can cause corruption in certain conditions. It's still best to mount read only whenever possible.
You guys are misunderstanding the purpose, I don't want to (necessarily) get a stable system out of it, I want to watch how it fails over time.
I have one SSD which I use as a data drive between both Linux and Windows. I used to run Steam games from it, but there were some small problems sometimes, so nowadays I just use it as a storage.
Generally it works just fine, but sometimes Windows does something weird with it especially when running updates, so that Linux can't mount it. During those times I just have to boot to Windows desktop and then come back to Linux and it usually mounts again. If you totally get rid of Windows, I don't think this will happen to you though.
Windows doesn't shutdown completely anymore, instead it's more similar to hibernate by default. For ntfs-3g (userspace/fuse ntfs driver) there's the remove_hiberfile option, which deletes the file and might delete some temporary data. I've personally never lost unsaved data because of this, but I closed apps before rebooting anyway. It's not recommend though and might not be available for the ntfs kernel driver.
Also, there are some things that supposedly don't work correctly when you have your Steam games on NTFS. So watch out for that. Google should know more.
I've used the old 'ntfs' driver that supposedly can't write to... write files ranging from 100,000+ small files in folders to individual 200+ GiB files on NTFS partitions. It works pretty well and I have used it for video editing (few huge files), software development (many tiny files), Unreal Engine + Unity, Linux Gaming w/Steam and more. Rock solid.
After hearing that the 'ntfs' driver is supposed to be read-only, I switched to 'ntfs3' instead of using 'ntfs3g' (~~same code, but compiled into the kernel instead of running outside via 'fuse'~~). From that point onwards, I've had major file system corruption nearly every day:
- Copying files into folders suddenly made 90% of other files in the folder disappear. Could be fixed by copying about 1000 random files into the folder and deleting them, then the missing files would come back into existence.
- Files that suddenly go bad. Can't be written to, moved or anything. Often happened in software development when compiling my project, suddenly the intermediate build directory was bust due to undeletable files.
- Folders that suddenly contain themselves or one of their parent folders as sub-folders.
- Folders that contain a specific file infinity times. This way, I found out that even a harmless file manager like KDE's Dolphin can become a behemoth that eats 100+ GiB of RAM and keeps trying to read the "list" of files in a directory without limit.
Personally, I'll never use 'ntfs3' for serious work again. But 'ntfs3g' is generally considered very stable, maybe my issues are specific to 'ntfs3' or my RAID setup (weird nested mdraid thanks to Intel) is to blame.
My final 'fix' was to move everything to ext4 and buy Paragon's $20 ext4 drivers for the dual boot Windows install. It's only seeing any use once every 2 months. Sadly, these drivers are case sensitive even on Windows, rendering Bethesda games unplayable when installed on those partitions, for example.
I switched to 'ntfs3g' or rather, it's 'ntfs3' variant (same code, but compiled into the kernel instead of running outside via 'fuse')
They are not the same code. They are completely independent code bases by different devs. ntfs-3g is developed by tuxera, ntfs3 by Paragon. The latter also maintain a proprietary ntfs driver for a long time.
In my experience ntfs3 is a little faster, but also more unstable. ntfs-3g gave me zero corruptions in years, ntfs3 on the other hand needs a chkdsk run every few days.
Oh my, thank you very much for pointing that out!
I might have to give it another chance, then, perhaps I'll shift my games partition back to NTFS once I can free up enough space.
I also recommend to stay away from NTFS3. I had some files that i couldn't empty from the recycle bin, they just keep reappearing.
After a while NTFS3 straight up give up, it couldn't mount the partition due to NTFS errors. At this point NTFS3g still worked, and i moved everything to an ext4 partition.
I've had good experiences but you milage could always very. Just follow good backup practices and you'll be fine.
In terms of plug and play, using KDE Plasma, trying to mount USB NTFS drives with Dolphin fails because udisks2 needs a new release with an NTFS patch so you'll need to mount those using the terminal (and possibly a umask argument that I can't remember off the top of my head if you want r/w access instead of read-only). Internal drives that are NTFS worked by clicking on them with no extra steps required surprisingly. This was with a newer kernel that has the ntfs3 driver and not using ntfs-3g fuse driver which also 'just works' but is slower.
My thought process was basically the same as yours, and what I did was to get a nvme ssd, a usb to nvme adapter (because my mobo only had 1 m2 slot and that was occupied), and install endeavour there. It fails sometimes at launch because being connected through USB is not so reliable, but whatever, restart once or twice and it works.
Anyway, I have all my drives mounted (the windows C drive, the extra ssd and the extra big hdd) without issues, all ntfs, games installed in the ntfs drive work flawlessly, no need to reinstall thanks to proton lol. I read, write, and interact with those drives without much though on the fact that they are ntfs.