Sharing a games drive between Windows and Linux (Steam + dual-boot)

gaming linux steam proton dual-boot ntfs

If you dual-boot Windows and Linux and have a second drive for games, you have probably wondered whether both OSes can share it - ideally sharing the same Steam library so you do not have to re-download 100 GB titles on each side. The catch is filesystems. There is no format that is natively read/write on both OSes and fully compatible with Steam and Proton, so every route is a tradeoff. Here is what I learned the hard way.

The filesystem problem

Windows writes NTFS, exFAT, and FAT32. Linux writes ext4, btrfs, and xfs natively. Neither side natively and reliably writes the other’s native format.

The cross-platform candidates all lose in different ways:

  • exFAT - both OSes mount it, but it has no file permissions, no symlinks, and is case-insensitive. That is worse for Steam and Proton than NTFS.
  • FAT32 - 4 GB maximum file size. Dead on arrival for modern games.
  • NTFS - Windows-native, and Linux can read/write it through three different drivers (more on those below). The least-bad shared choice.

Going the other direction - formatting the drive ext4 or btrfs and using a third-party Windows driver like WinBtrfs or Ext2Fsd - sounds appealing but is unstable under heavy game I/O (I tried it; see my story below).

For a shared games drive: NTFS, with caveats.

The reliable setup. One physical NTFS drive, each OS installs into its own Steam library folder on it - for example a SteamLibraryWin folder and a SteamLibraryLinux folder. Games are installed twice (double space, double downloads), but nothing is shared or contended, so nothing breaks.

Why separate? Linux Steam runs Windows games through Proton and stores compatdata prefixes - virtual Windows environments full of symlinks and POSIX permission bits that neither NTFS nor Windows Steam understands. Separate libraries sidestep all of it.

To set this up on each OS: Steam -> Settings -> Storage -> Add Drive, and pick the mounted path (the Windows drive letter or the Linux mount point from the setup section below).

Option B: one shared library (and why it is fragile)

The dream: one steamapps folder both OSes use, so a 100 GB game downloads once. In principle this works because Proton runs the Windows build - the files are the same.

The reality: unsupported by Valve. NTFS is case-insensitive, lacks Linux permissions, and Proton’s compatdata prefixes and symlinks do not map cleanly. You will see periodic “missing file privileges” errors, failed launches, forced re-validations, and corruption risk.

Essential mitigation: keep the shared game files on NTFS but move Proton’s compatdata (and ideally shadercache) onto a native Linux filesystem and symlink them back - see Keep Proton prefixes off NTFS below. Without this the NTFS library corrupts repeatedly. Even with it, Option B is not bulletproof.

Honest verdict: OK for a handful of tolerant single-player titles. Not for a big mixed library. If you value reliability, use Option A.

My path: btrfs + WinBtrfs, then NTFS

My first idea was to let Linux be the main character: format the games drive btrfs and install WinBtrfs on Windows so both OSes could access it natively - well, “natively.”

What happened: Windows downloads and updates kept hanging. Steam would stall mid-download, the system would become unresponsive, and I would have to force-reboot. This is a known WinBtrfs I/O-deadlock under heavy write operations. WinBtrfs is a community-driven driver, not officially supported by Microsoft, and its implementation of sustained high-throughput writes just is not there yet. A fix has been sitting in that open PR since August 2025 and is still unmerged at the time of writing (August 2026) - the comment thread is full of people describing exactly the Steam-download freeze I hit.

So I switched to NTFS. Better, but my first NTFS attempt kept corrupting the filesystem. Steam would break, the library would go unreadable, and I was booting into Windows to repair the volume constantly. The cause turned out to be Proton’s compatdata and shadercache living on NTFS - those directories are full of symlinks and POSIX-permission-dependent files that NTFS cannot represent faithfully. Once I moved them onto a Linux-native drive and symlinked them back, the corruption stopped.

NTFS can still go dirty from the Windows side - that is the separate Fast Startup issue covered below - but the filesystem corruption from Proton prefixes was the bigger problem and the one that took me the longest to figure out.

Setup on Linux (CachyOS / Arch)

These instructions were written on CachyOS / Arch, but nothing here is Arch-specific - the only requirement is a 7.1+ kernel if you want the new in-kernel ntfs driver. On older kernels, substitute ntfs3 as the filesystem type below.

  1. Find the partition and its UUID:

    lsblk -f

    Look for the NTFS partition on your games drive. Note the UUID.

  2. Create a mount point:

    sudo mkdir -p /mnt/games

  3. Pick your NTFS driver. On Linux 7.1+ (released June 14, 2026) there is a new in-kernel ntfs driver - a modernized, read/write successor to the old legacy NTFS driver, developed by Namjae Jeon (who also wrote the Linux exFAT driver) and built on modern kernel storage infrastructure (iomap, folio). It is a new alternative to Paragon’s ntfs3 driver (both coexist in the kernel) and significantly faster than the long-standing FUSE-based ntfs-3g. It is still marked experimental in 7.1, but early results are promising. Mount it with filesystem type ntfs (i.e. -t ntfs).

    Driver Type Status
    ntfs In-kernel New 7.1+ native driver (experimental, but promising)
    ntfs3 In-kernel Older Paragon driver (still in the kernel)
    ntfs-3g FUSE (userspace) Traditional fallback - slower

  4. Add a persistent /etc/fstab entry. Get your uid/gid first with id -u and id -g (usually both 1000). Then add this line to /etc/fstab, replacing the UUID with yours:

    UUID=XXXXXXXX  /mnt/games  ntfs  rw,uid=1000,gid=1000,umask=022,nofail  0 0

    What each option does: uid/gid = your user owns the files; umask=022 = sane permissions; nofail = do not hang boot if the drive is absent.

  5. Apply and verify:

    sudo mount -a
mount | grep games

    Confirm the output shows type ntfs (kernel driver) - or type ntfs3 if you used the older driver. If it shows fuseblk, that means ntfs-3g grabbed it. Many distros ship a mount.ntfs helper symlink that points at ntfs-3g and hijacks the mount -t ntfs call. Check with ls -l /usr/bin/mount.ntfs (older distros: /usr/sbin/mount.ntfs) - if it points at ntfs-3g, delete the symlink so mount falls through to the kernel driver. It is owned by the ntfs-3g package (pacman -Qo /usr/bin/mount.ntfs or dpkg -S mount.ntfs confirms), so a package update can bring it back - re-check after updating.

  6. Add the mounted path as a Steam library: Steam -> Settings -> Storage -> Add Drive -> pick /mnt/games (or wherever you mounted it).

Keep Proton prefixes off NTFS (compatdata and shadercache)

This is the fix that made NTFS usable for me, and it applies to any Steam library on NTFS under Linux - Option A’s Linux library included, not just the shared Option B.

Steam on Linux stores each game’s Proton prefix under steamapps/compatdata/<appid>/ and shader caches under steamapps/shadercache/. Those trees are full of symlinks and POSIX-permission-dependent files that NTFS cannot represent faithfully. Leaving them on NTFS is what corrupted my drive again and again.

The fix: move them onto a native Linux filesystem (ext4, btrfs - anything that is not NTFS) and symlink them back into the library. Fully quit Steam first.

# LIB = your Steam library folder on the NTFS mount (the one containing steamapps/)
LIB="/mnt/games/SteamLibrary"

# create a native-filesystem home for Proton state
mkdir -p ~/steam-native

# move existing data off NTFS
mv "$LIB/steamapps/compatdata"  ~/steam-native/compatdata
mv "$LIB/steamapps/shadercache" ~/steam-native/shadercache

# symlink them back so Steam finds them where it expects
ln -s ~/steam-native/compatdata  "$LIB/steamapps/compatdata"
ln -s ~/steam-native/shadercache "$LIB/steamapps/shadercache"

If this is a fresh library where compatdata and shadercache do not exist yet, skip the mv lines. Just mkdir -p ~/steam-native/compatdata ~/steam-native/shadercache and create the two symlinks. Steam will write prefixes and caches straight to the Linux drive from the start.

Important: ~/steam-native must live on an ext4/btrfs partition, not another NTFS mount, or the fix does nothing.

compatdata is the essential move - it is the Proton prefix and the thing that corrupts. shadercache is a strong “ideally” - moving it too keeps all the symlink-heavy Proton state off NTFS and avoids shader compilation churn on the slower FUSE path.

Disable Windows Fast Startup (or the drive breaks)

The other big dual-boot NTFS gotcha. Windows Fast Startup does not fully shut down - it hibernates the kernel session and leaves the NTFS volume in a dirty state. Linux then either mounts it read-only (to protect data) or refuses to mount it at all. Real hibernation does the same thing.

To disable it in Windows:

  1. Open Control Panel -> Hardware and Sound -> Power Options -> Choose what the power buttons do.
  2. Click Change settings that are currently unavailable (requires admin).
  3. Uncheck Turn on fast startup (recommended).
  4. Click Save changes.
  5. Shut down normally (not sleep, not hibernate).

Belt-and-suspenders: disable hibernation entirely from an admin PowerShell or Command Prompt:

powercfg /h off

If you cannot change the setting (corporate policy, shared machine), hold Shift while clicking Shut down for a one-off full shutdown before switching to Linux.

When the drive “breaks”: fixing a dirty NTFS volume

Symptom: after using Windows, Linux mounts the drive read-only or not at all. Steam reports the library as missing or broken.

Boot into Windows and run chkdsk /f X: (replace X: with the drive letter) from an admin Command Prompt. Then do a full shutdown (Fast Startup off, or Shift+Shut down). Never try to repair an NTFS volume from Linux - tools like ntfsfix can clear the dirty bit and reset the journal, but they are not a substitute for a real chkdsk and can mask underlying problems. Do not force-mount a dirty volume with -o force either; that risks real corruption.

FAQ

Can Windows and Linux share the exact same installed games?

Technically yes - Proton runs the Windows build, so the files match. But it is unsupported by Valve and breaks periodically on NTFS due to case-sensitivity, permission, and symlink issues. The reliable answer: share the drive, keep a separate library per OS (Option A).

Why not just format the drive ext4 or btrfs?

Then Windows cannot read it without an unofficial driver (WinBtrfs, Ext2Fsd), which is unstable under heavy game I/O. That is exactly what pushed me off btrfs.

exFAT instead of NTFS?

Worse for games: no permissions, no symlinks, case-insensitive, and flaky for Steam. NTFS is the lesser evil.

ntfs, ntfs3, or ntfs-3g - which driver?

On Linux 7.1+, the new in-kernel ntfs driver (Namjae Jeon’s rewrite). ntfs3 (Paragon) is the prior in-kernel one and still in the kernel tree. ntfs-3g (FUSE, userspace) is the old reliable fallback but slower than either kernel driver.

My drive keeps going read-only.

Fast Startup is still on, or Windows hibernated. Disable Fast Startup and do a full shutdown before booting into Linux.

My NTFS Steam library keeps corrupting even though Fast Startup is off.

Proton’s compatdata and shadercache living on NTFS is the usual culprit. Move them to a Linux-native drive and symlink them back - see Keep Proton prefixes off NTFS.