Skip to content

Instantly share code, notes, and snippets.

@aont

aont/0 Accessing a Windows Block Device from WSL2 using NBD nbdkit on Windows.md

Last active October 5, 2025 14:15
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save aont/59f7c05372d4063cc81719fc77495339 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save aont/59f7c05372d4063cc81719fc77495339 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
0 Accessing a Windows Block Device from WSL2 using NBD nbdkit on Windows.md

Access a Windows block device from WSL2 using NBD

If you have a directly attached SD-card reader (or other removable media that is not USB) and wsl --mount or usbip won’t work, exporting the raw Windows device over the network with nbd (via nbdkit) is a handy workaround. nbdkit can run on Windows and serve \\.\PHYSICALDRIVEx to your WSL2 instance, where you can attach it as /dev/nbd0. The nbdkit project and docs explain the server/plugin model nicely. (libguestfs.org)

Below is a short, practical recipe.

References / useful links (keep these): https://rwmj.wordpress.com/2024/01/24/nbdkit-binaries-for-windows/ (Richard WM Jones) https://koji.fedoraproject.org/koji/userinfo?userID=458 https://koji.fedoraproject.org/koji/buildinfo?buildID=2835676

Why this helps

wsl --mount needs block devices that WSL can see as supported (and usbip only helps with USB devices). For card readers that are PCI/embedded and exposed as Windows physical disks, exposing the device via an NBD server on the Windows side lets WSL2 connect and use it like a local block device. This is exactly what nbdkit is for: serve arbitrary block sources over NBD. (libguestfs.org)

Quick steps

  1. Get a Windows build of nbdkit. Richard W. M. Jones provides a guide and pointers to Fedora/Koji builds (look under noarch for mingw64-nbdkit-<version>). (Richard WM Jones)

  2. Download the mingw64 RPM (example: mingw64-nbdkit-1.45.9-1.fc44.noarch.rpm) from the Koji build you prefer (the Koji links above are where Rich’s builds live). Place the .rpm somewhere accessible on Windows (many people put extracted files under C:\). (You can extract an RPM with 7-Zip on Windows or from WSL: rpm2cpio file.rpm | cpio -idmv.)

  3. Install the small MSYS2 runtime deps on Windows (if you run nbdkit from an MSYS environment): install the packages mingw-w64-x86_64-dlfcn and mingw-w64-x86_64-gnutls in MSYS2’s MINGW64 environment. Those packages are available from the MSYS2 repositories. (packages.msys2.org)

    Example (in an MSYS2 MINGW64 shell):

    pacman -Syu
pacman -S mingw-w64-x86_64-dlfcn mingw-w64-x86_64-gnutls

  4. Adjust PATH (msys2 / mingw64) — add the nbdkit runtime dirs so the .exe and plugin DLLs are found. Example lines (put these in your MSYS2 shell profile or run before starting nbdkit):

    PATH="/c/usr/x86_64-w64-mingw32/sys-root/mingw/sbin:$PATH"
PATH="/c/usr/x86_64-w64-mingw32/sys-root/mingw/lib/nbdkit/filters:$PATH"
PATH="/c/usr/x86_64-w64-mingw32/sys-root/mingw/lib/nbdkit/plugins:$PATH"

  5. Run nbdkit on Windows to export the physical drive. Run from an elevated shell (admin) or an MSYS2 shell with appropriate privileges. The example below serves \\.\PHYSICALDRIVE0 read-only on port 10809. Note the sudo -E in case you need to preserve environment in MSYS2 (as you mentioned).

    sudo -E nbdkit -v -f file file='\\.\PHYSICALDRIVE0' --read-only -p 10809

    Make sure Windows Firewall allows inbound traffic to that port (or bind to an interface only accessible from the host).

  6. On WSL2, connect with nbd-client. In your WSL2 distro:

    sudo nbd-client <windows-ip> 10809 /dev/nbd0 -R

    -R requests a read-only export if the server supports it; omit if you deliberately want write access (be careful). After connecting, you can sudo fdisk -l /dev/nbd0 or mount partitions (e.g. sudo mount /dev/nbd0p1 /mnt/sd) as usual.

  7. Disconnect when done:

    sudo nbd-client -d /dev/nbd0

Short notes & cautions

  • Running a Windows process that serves \\.\PHYSICALDRIVE0 gives raw access to a whole disk — be sure to run read-only unless you explicitly want writable access, and ensure you target the correct PHYSICALDRIVEx.
  • Open only necessary ports and prefer binding to localhost or the host’s internal IP rather than exposing to the wider network.
  • If you prefer packaged Windows binaries, check the Fedora/Koji mingw64-nbdkit packages (the noarch sections contain the Windows artifacts) — that’s where the builds referenced by Richard are published. (packages.fedoraproject.org)
  • nbdkit is flexible: it supports many plugins/filters and the project docs are a good read for advanced use. (libguestfs.org)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment