New Linux NTFS Driver Gains Native Windows Symbolic Link Support

The new NTFS kernel driver merged for Linux 7.1 has been one of the more interesting storage stories of this cycle, and it just picked up work on a feature that matters a lot if you run mixed Windows and Linux storage in a homelab. Open-source developer Hyunchul Lee posted a patch series adding support for Windows native symbolic links, closing one of the driver's notable early gaps.

{{IMAGE:2}}

What Changed

The new driver arrived in good shape and already showed advantages over the existing open-source NTFS options, but it shipped without proper handling for Windows native symbolic links. That is the piece now being addressed. The patches add parsing and following of native symlinks, plus two new mount options that give you control over behavior on both the read and write side.

• native_symlink=raw|rel controls how the link target gets resolved when you follow an existing Windows symlink.
• symlink=wsl|native controls which on-disk format the driver writes when you create a symlink from Linux.

The series also folds in additional bug fixes and documentation updates for the driver. You can read the full patch series on the kernel mailing list if you want to follow the review.

Native Symlinks Versus .lnk Shortcuts

This is worth separating clearly, because Windows has two completely different things that people loosely call shortcuts. The common .lnk shortcut is a regular file the shell interprets. It is application-level metadata, and the file system itself has no idea it points anywhere. Native symbolic links are different. They are resolved at the file-system layer through NTFS reparse points, which makes them behave much closer to the symlinks you already know from ext4, XFS, or Btrfs: transparent redirection that the kernel follows without any userspace shell involvement.

The reason the two mount options exist comes down to a format mismatch. WSL stores symlinks one way to stay compatible with the Linux semantics it emulates, while Windows itself uses the native reparse-point representation. The symlink=wsl|native option lets you decide which dialect Linux speaks when creating links, so you can match whatever the rest of your environment expects. The native_symlink=raw|rel option then handles the messier read side, where Windows targets can carry absolute drive-letter paths that have no meaning under a Linux mount point.

Why Homelab Builders Should Care

If you have a data drive that gets shucked between a Windows box and a Linux NAS, symlink handling is exactly the kind of thing that silently corrupts your assumptions. A dataset full of native symlinks that the driver cannot follow turns into dead entries or, worse, files you accidentally treat as plain data. Getting this resolved at the kernel level means dual-boot machines and removable NTFS volumes behave predictably no matter which side mounts them.

The new driver has been positioned as a cleaner long-term replacement for the paroh-era NTFS3 code, and feature parity like this is what determines whether people actually trust it for read-write workloads instead of falling back to the FUSE-based NTFS-3G for anything beyond casual reads. Reparse-point symlink support is a meaningful step toward that parity.

Timing

Do not expect this in the immediate next release. Given when the patches landed, it is unlikely to make the Linux 7.2 merge window and will probably slip to a later cycle depending on how review goes. That is normal for a feature touching on-disk format interpretation, where reviewers tend to be cautious. For the broader context on the driver itself, Phoronix has been tracking the new NTFS work through the 7.1 cycle.

For now the takeaway is straightforward. The new NTFS driver keeps maturing, and one of the more annoying interoperability gaps for anyone moving NTFS volumes between Windows and Linux is on its way to being closed.