NTFS: Explanation & Insights

Windows' native filesystem, which a Linux admin meets on dual-boot disks, USB drives, and recovery jobs.

What It Is

NTFS — the New Technology File System — is the filesystem that Windows has used since the late 1990s. It is to Windows what ext4 is to Linux: the default structure that turns a raw partition into something with files, directories, permissions, and crash resistance. If you only ever run Linux servers, you might expect never to touch it. You will. NTFS shows up on the disk you pulled out of a dead Windows box to recover a client's files, on the external USB drive a colleague formatted on their laptop, on the Windows half of a dual-boot machine, and on the data partition of a NAS someone set up "to be compatible with everything." Sooner or later a Linux box has to read an NTFS volume, and the question stops being academic.

So this page is not "should you run NTFS on your Linux server" — the answer to that is a flat no, and we'll get to why. It's "NTFS is here, on this disk, in front of you, and you need to read it (or write to it) without making things worse." That turns out to have a surprising amount of depth, because Linux has had two completely different ways of speaking NTFS, and the one you end up using changes everything about speed and safety. Knowing which driver actually mounted your disk is the single most useful thing on this page, so we'll spend real time on it.

A filesystem's job, on any OS, breaks down into the same handful of responsibilities: naming (mapping a path to a physical location), metadata (who owns a file, when it changed, what it's allowed to do), allocation (deciding where bytes live and tracking free space), and integrity (surviving a power cut without turning to mush). NTFS does all four, and does them well — it was a genuinely modern design when it shipped, with journaling and access control built in from day one, at a time when the Windows consumer line was still limping along on FAT. The trouble was never NTFS itself. The trouble is that Microsoft never published the full specification, so every line of NTFS support on Linux had to be reverse-engineered.

Why It Matters

For a Linux admin, NTFS matters in exactly one direction: interoperability. You will not format a server volume with it, but you will constantly need to get data off it or onto it across the Windows/Linux boundary. Three scenarios cover almost everything:

Recovery. A Windows machine won't boot. You yank the disk, plug it into a Linux box (or boot a live USB), mount the NTFS partition, and copy the irreplaceable files off it before anyone tries anything drastic. This is the classic "Linux saves the day" job, and NTFS is the filesystem standing between you and the data.
Shared external drives. A big USB drive that has to be readable on Windows, macOS, and Linux is very often NTFS, because it's the one read-write format all three can handle for large files (FAT32 chokes at 4 GB per file; exFAT is the modern alternative but not always present).
Dual-boot. A workstation that boots both Windows and Linux usually has a shared NTFS data partition so both worlds see the same documents.

In all three, your goal is the same: read and write reliably, and above all don't corrupt the volume, because the person on the other side of that disk is going to boot Windows again and expect it intact. That single constraint — Windows owns this disk, you're a guest — drives every recommendation here.

Note

NTFS is for interop, not for a Linux server filesystem. If you're choosing a format for a Linux volume — a database, a web root, log storage — reach for ext4 or XFS. NTFS on Linux is a guest in someone else's house: support is good now, but it has no upside over the native filesystems and a long history of rough edges. Use it to talk to Windows, nothing more.

How NTFS Works

You don't need to understand NTFS as deeply as the filesystem you actually run, but a working mental model of three things — the MFT, the journal, and the permission/stream model — makes the difference between "I copied some files" and "I know what I'm looking at."

The Master File Table

The heart of NTFS is the MFT, the Master File Table. Where ext4 scatters inodes across the disk in fixed groups, NTFS keeps one big table where every file and directory on the volume is a record. The MFT is itself a file (NTFS is delightfully self-referential — the table that tracks all files is the very first entry in the table that tracks all files), and each record holds the file's name, timestamps, security descriptor, and pointers to where its data lives.

The clever bit: a small file doesn't get its data scattered across the disk at all. If the contents fit inside the MFT record itself — a few hundred bytes — NTFS just stores them inline, in the record. This is called a resident file, and it means tiny files cost essentially nothing beyond their table entry. Bigger files become non-resident: the record stops holding data and instead holds a map of runs (NTFS's version of extents — "this file occupies clusters 5000 through 5200"). A cluster is NTFS's allocation unit, the equivalent of an ext4 block: typically 4 KB, set when the volume is formatted.

If the MFT itself gets corrupted, the volume is in deep trouble, so NTFS keeps a partial backup (the MFT mirror, $MFTMirr) holding copies of the first few critical records. It's the same instinct as a filesystem superblock backup — lose the index and the data might as well not exist, so you guard the index hardest.

Journaling

Like every modern filesystem, NTFS is journaled. Before it changes the important on-disk structures, it writes a description of the intended change to a dedicated log ($LogFile). If the power dies mid-write, Windows replays the log on the next boot, finishing the half-done transactions and discarding the incomplete ones — so recovery takes seconds, not the hours an old full-disk scan (chkdsk, the Windows cousin of fsck) would take. This is exactly the mechanism described in detail on the filesystem and journaling pages; NTFS just got there years before ext3 brought journaling to the Linux mainstream.

One sharp consequence for us: the journal is the reason a Linux NTFS driver is fussy about an unclean volume. If Windows didn't close the filesystem properly, there are pending entries in $LogFile that only Windows knows how to replay correctly. A Linux driver finding a dirty journal will refuse to write to the volume rather than guess — and that's the right call, as we'll see in the Fast Startup warning below.

ACLs and Alternate Data Streams

Two NTFS features have no clean equivalent on Linux, and they're worth naming so they don't surprise you.

NTFS permissions are ACLs (Access Control Lists) — rich, per-user-and-group rules tied to Windows Security Identifiers (SIDs), far more granular than the Unix owner/group/other permission bits. When you mount NTFS on Linux, those Windows ACLs simply don't translate; the Linux driver papers over them by presenting everything with a uniform owner and mode that you set at mount time (uid=, gid=, umask=). You're seeing a Linux-shaped shadow of the real Windows permissions, not the permissions themselves.

NTFS also supports alternate data streams (ADS) — a file can carry extra named streams of data hidden behind its main contents (report.txt:secret is a second stream attached to report.txt). Windows uses this benignly (the "downloaded from the internet" zone marker is an ADS), and malware has historically used it to hide payloads. The Linux drivers expose streams through extended attributes, but for ordinary recovery work you can mostly ignore them — just know they exist, so "the file is 2 KB but the disk usage doesn't add up" has an explanation.

The Two Linux Drivers — The Thing to Get Right

Here's the part that trips up everyone, and the reason this page exists. Linux has had two different drivers for NTFS, and which one mounted your disk changes its speed by an order of magnitude and its safety profile entirely. Get this clear once and you'll never be confused by an NTFS mount again.

ntfs-3g — The Old Faithful (FUSE, Userspace)

For well over a decade, the only way to write to NTFS on Linux was ntfs-3g, a driver built on FUSE (Filesystem in Userspace). FUSE is a clever trick: instead of living inside the kernel, the filesystem logic runs as an ordinary userspace program, and the kernel forwards every read and write out to it. This is how ntfs-3g could be a fully reverse-engineered, GPL-friendly NTFS implementation without touching kernel code — and it's why, for years, it was the safe, trusted, boring choice. It worked. It rarely ate data. Distros installed it by default and it just handled your USB drive.

The price is speed. Every file operation has to cross from kernel to userspace and back — a context switch on each I/O — so ntfs-3g is slow, sometimes dramatically so on large copies. For occasionally pulling files off a recovery disk, you'll never notice. For copying a few hundred gigabytes, you'll go make coffee, and then make more coffee.

ntfs3 — The New In-Kernel Driver (Paragon)

In 2021, with Linux 5.15, a proper in-kernel NTFS driver landed: ntfs3, contributed by Paragon Software, who had been maintaining a commercial NTFS driver for years and finally upstreamed it. Because it runs inside the kernel — no FUSE round-trip — it's much faster, often several times the throughput of ntfs-3g on big transfers, and it's now the driver you get with mount -t ntfs3. On any reasonably current distribution, ntfs3 is the modern default and the one you want for real work.

(A historical footnote to avoid confusion: there was an original in-kernel ntfs driver, ancient and read-only-for-all-practical-purposes. ntfs3 is its modern replacement, not that old thing. If a mount -t ntfs falls back to the legacy read-only driver, you do not want it for writing.)

Which One Mounted? How to Tell

This is the muddy thing, made crisp. After you mount an NTFS volume, find out which driver is actually serving it — don't assume:

mount | grep -i ntfs

/dev/sdb1 on /mnt/win type fuseblk (rw,...)     # ← fuseblk = ntfs-3g (FUSE/userspace)
/dev/sdb1 on /mnt/win type ntfs3 (rw,uid=0,...) # ← ntfs3   = in-kernel (the fast one)

The tell is the type column. If it says fuseblk, you're on ntfs-3g — userspace, safe, slow. If it says ntfs3, you're on the in-kernel driver — fast. (findmnt /mnt/win shows the same thing more cleanly.) You can also see which driver is loaded with lsmod | grep ntfs3 and check process listings for an ntfs-3g process serving the FUSE mount.

To choose the driver, name it explicitly at mount time:

mount -t ntfs3 /dev/sdb1 /mnt/win    # force the fast in-kernel driver
mount -t ntfs-3g /dev/sdb1 /mnt/win  # force the userspace FUSE driver

Pro Tip

On a current kernel (5.15+), prefer mount -t ntfs3 for anything involving real data volume — it's several times faster than the userspace FUSE driver and it's the actively-maintained future of NTFS on Linux. Keep ntfs-3g in your back pocket for an older box that doesn't have ntfs3, or as a second opinion if a stubborn volume won't behave with one driver. Two implementations of the same filesystem is a luxury; use whichever one mounts the disk cleanly.

Why does it matter beyond bragging rights? Performance, obviously, on big copies. But also reliability and behaviour: the two drivers were written by entirely different people from entirely different reverse-engineering efforts, so they handle edge cases — odd ACL layouts, compression, the dirty-volume question below — slightly differently. When one driver refuses a volume, the other sometimes has a different opinion. Knowing which one you're on tells you which manual to read and which knobs (uid=, gid=, umask=, windows_names) actually apply.

The Big Foot-Gun: Fast Startup and Hibernation

Now the one that will cost you an afternoon and possibly a client's data if you don't know it. This is the most important warning on the page.

Warning

A Windows disk that was last "shut down" with Fast Startup enabled — or one that's hibernated — is not actually shut down. It's in a hybrid state, and NTFS on it is flagged dirty with an unfinished journal. Linux will mount it read-only (the safe drivers refuse to write to it), and if you force a read-write mount and start writing, you risk corrupting the volume — because the moment Windows resumes, it'll restore the stale on-disk state it saved and stomp on whatever you changed. Never force-write a hibernated NTFS volume.

Here's the full story, because understanding it is what keeps you out of trouble. Windows 8 introduced Fast Startup (and left it on by default). When you click "Shut down," Windows doesn't fully shut down — it logs off your session but then hibernates the kernel, dumping the system state to hiberfil.sys so the next boot is lightning fast. From NTFS's point of view, the filesystem was never cleanly closed: there's pending journal state, and a flag on the volume that says "I'm dirty, don't let anyone else touch me." This is the dirty bit, and it's the same flag set by a real crash or a yanked USB drive mid-write.

A well-behaved Linux driver respects that flag. ntfs3 and ntfs-3g will both mount the volume read-only rather than risk writing into a filesystem whose owner thinks it has exclusive, mid-transaction access. That's not a bug — it's the driver protecting you. Reading is always safe; you can copy your files off a read-only mount all day long. The danger is forcing it writable.

What to do, in order of preference:

If you control the Windows box: shut it down properly. Hold Shift while clicking "Shut down," or run shutdown /s /f /t 0, or disable Fast Startup outright (Control Panel → Power Options → "Choose what the power buttons do" → uncheck "Turn on fast startup"). A genuine full shutdown closes the journal and clears the dirty bit. This is the clean fix.
If you only need to read: just mount it read-only and copy your data off. Done. No risk.
If you must write and can't reboot Windows: clear the dirty state from Linux first with ntfsfix (below). Understand that this can discard the hibernation state, so Windows will do a fresh boot next time and lose its hibernated session — acceptable for a recovery disk, not for a machine someone left mid-work.

The ntfs3 driver also accepts mount options for this situation — force to mount a dirty volume read-write anyway (don't, unless you've accepted the risk) — but the cleaner path is ntfsfix, which is built for exactly this.

How I Inspect and Repair It

A short toolkit covers everything you'll do with NTFS on Linux. None of these is exotic; they're the same family of tools you use for ext4, pointed at a foreign filesystem.

blkid — Confirm It's Actually NTFS

Before you mount anything unfamiliar, ask what it is. blkid reads the partition's superblock and reports the type and UUID:

blkid /dev/sdb1

/dev/sdb1: LABEL="Backup" UUID="A1B2C3D4E5F6A7B8" TYPE="ntfs"

TYPE="ntfs" confirms it. Note the NTFS "UUID" is a 64-bit volume serial, shorter than the long UUIDs you see on Linux filesystems — that's normal, not a truncation. lsblk -f gives you the same type-and-label info laid out as a tree, which is handy when you're staring at an unfamiliar disk trying to work out which partition is the data one.

ntfsfix — Clear the Dirty Bit, Not a Full Repair

ntfsfix (from the ntfs-3g/ntfsprogs package) is the tool you reach for when a volume won't mount read-write because it's flagged dirty. Despite the name, it is not a chkdsk equivalent — it doesn't deeply repair a damaged filesystem. What it does is fix a few common inconsistencies, clear the dirty flag, and schedule Windows to run its own chkdsk on next boot:

ntfsfix /dev/sdb1

The honest framing: ntfsfix makes a dirty volume mountable again on Linux; it does not make a broken volume healthy. For genuine corruption, the real repair tool is Windows' own chkdsk /f, because Microsoft never fully documented the on-disk format and only their tooling truly understands every structure. So the pattern is: ntfsfix to get unstuck on Linux, then chkdsk on Windows when you can, to do the real check.

Danger

Don't reach for ntfsfix (or a forced read-write mount) on the only copy of irreplaceable data while the volume is acting strange. If the disk might be physically failing or the filesystem is genuinely damaged, image it first — dd or ddrescue the whole partition to a file — and work on the copy. NTFS repair tooling on Linux is limited by Microsoft's closed format; the safe move when data is precious is to preserve a byte-for-byte image before touching anything.

Mounting It Properly

The everyday operation. Pick the driver, point it at a directory, and set who owns the files (since the Windows ACLs don't carry over):

mount -t ntfs3 /dev/sdb1 /mnt/win                    # fast, read-write, owned by root
mount -t ntfs3 -o uid=1000,gid=1000,umask=022 /dev/sdb1 /mnt/win   # owned by a normal user
mount -t ntfs3 -o ro /dev/sdb1 /mnt/win              # read-only, the safe recovery default

The uid/gid/umask options decide how the volume's files appear to Linux's permission model — without them everything belongs to root and a normal user can't write. For a recovery job, mounting read-only (-o ro) is the disciplined default: you almost never need to write to a disk you're rescuing, and read-only makes "oops" impossible. See the mounting page for the full mechanics of attaching a filesystem to the tree.

Creating an NTFS Filesystem

You'll rarely format a fresh NTFS volume from Linux, but when you do — say, prepping an external drive for a Windows user — mkfs.ntfs (also available as mkntfs) does it:

mkfs.ntfs -Q -L Backup /dev/sdb1

The -Q ("quick") flag skips the full zeroing and bad-block scan, which is what you want on a healthy modern drive; without it, mkntfs writes every sector and takes ages on a large disk. -L sets the volume label. The result is a clean NTFS volume Windows will mount happily.

Cheat Sheet

# --- Identify ---
blkid /dev/sdb1                      # is it really NTFS? type + volume serial
lsblk -f                             # tree of partitions, types, labels, mountpoints
mount | grep -i ntfs                 # which driver mounted it? fuseblk=ntfs-3g, ntfs3=in-kernel
findmnt /mnt/win                     # same, cleaner output

# --- Mount (choose your driver) ---
mount -t ntfs3 /dev/sdb1 /mnt/win                  # fast in-kernel driver (5.15+)
mount -t ntfs-3g /dev/sdb1 /mnt/win                # userspace FUSE driver (older/fallback)
mount -t ntfs3 -o ro /dev/sdb1 /mnt/win            # read-only — the safe recovery default
mount -t ntfs3 -o uid=1000,gid=1000,umask=022 /dev/sdb1 /mnt/win   # owned by a normal user

# --- Unstick a dirty volume (Fast Startup / hibernation / crash) ---
ntfsfix /dev/sdb1                    # clear the dirty flag so Linux can mount rw; NOT a full repair
# better fix: boot Windows, full shutdown (Shift+Shutdown), or `shutdown /s /f /t 0`

# --- Create / format ---
mkfs.ntfs -Q -L Backup /dev/sdb1     # quick format with a label (mkntfs is the same tool)

# --- Recover safely ---
ddrescue /dev/sdb1 /tmp/win.img /tmp/win.log   # image a flaky disk, then work on the copy

# --- Unmount when done ---
umount /mnt/win

Gotchas

The traps, roughly in order of how often they bite:

The volume mounts read-only and you don't know why. Nine times out of ten it's Fast Startup or hibernation — the dirty bit is set and the driver is protecting you. Don't force it; do a real Windows shutdown, or ntfsfix if you must, then mount again.
Everything is owned by root and a normal user can't write. NTFS has no Unix ownership, so the driver invents one at mount time. Pass uid=, gid=, and umask= to make the files belong to the right user. There's no chown-on-NTFS that survives — ownership is a mount-time illusion.
mount -t ntfs quietly gives you the wrong driver. On some kernels the bare ntfs type maps to the ancient read-only driver, not ntfs3. If writes mysteriously fail, check the mount output's type column and re-mount with -t ntfs3 explicitly.
ntfsfix is not chkdsk. It clears the dirty flag and patches trivial inconsistencies; it does not repair real corruption. For that you need Windows' chkdsk. Treating ntfsfix as a full repair tool is how a limping volume becomes a dead one.
Filenames Windows forbids. NTFS bans characters Linux allows (:, ?, *, trailing dots and spaces). Write such a name from Linux and Windows may not see the file. The windows_names mount option enforces Windows' rules so you don't create files Windows can't open.
Don't put a Linux server's data on it. Worth repeating: NTFS is for talking to Windows. For a database, a web root, or log storage on Linux, use ext4 or XFS. Running production Linux workloads on NTFS buys you reverse-engineered quirks and zero benefit.

History and Philosophy

NTFS arrived with Windows NT 3.1 in 1993, designed largely by Tom Miller and a team that included Gary Kimura, with input from a former VMS filesystem engineer — and the lineage shows, because NTFS borrowed the serious-OS ideas (journaling, ACLs, recoverability) that the consumer Windows line, still shackled to FAT and its descendant vfat, wouldn't get for years. When Windows XP finally unified the consumer and NT lines in 2001, NTFS became the filesystem on hundreds of millions of desktops, and it has carried Windows ever since with remarkably few on-disk format changes. It was, for its time, a properly modern filesystem.

The Linux side of the story is the interesting one, and it's a small monument to reverse engineering. Microsoft never published a complete NTFS specification, so Linux support had to be deduced from watching the bytes Windows wrote. For a long time Linux could only read NTFS, and writing was a terrifying prospect — the original kernel driver shipped with write support disabled by default precisely because nobody was confident it wouldn't scramble your data. The breakthrough was the ntfs-3g project (Szabolcs Szakacsits, mid-2000s), which used FUSE to deliver the first genuinely safe read-write NTFS on Linux. It was slow, but it worked, and for fifteen years it was simply how you did NTFS on Linux.

Then, in 2021, came the plot twist. Paragon Software, a company that had sold a proprietary NTFS driver commercially for years, decided to upstream it into the Linux kernel. After a famously bumpy review process — the code arrived as one enormous patch, and kernel maintainers don't love enormous patches — ntfs3 merged into Linux 5.15. So today, after two decades of treating NTFS as a barely-tolerated foreigner, Linux has a fast, in-kernel, maintained driver for it, contributed by the very people who'd been charging money for the privilege. The reverse-engineering era didn't end so much as get adopted. It's a quietly satisfying ending to a long story: the filesystem Linux could once only squint at, it now mounts at full speed — and the old FUSE workhorse is still there in the stable, ready for the disk the new driver won't take.