WSL2 + USB接続 ext4 HDD + Samba 検証記録

この記事は技術的要素もたぶんに含まれますが、読み物としての要素やマインドのお話が多くを占めています。
その点あしからずご承知おきください。
技術的レビューやご指摘はお気兼ねなくお知らせください。調査後に修正いたします。
(この記事の情報は 2025/11/23 時点での情報です。)

この記事の要点

USB 接続の HDD (ext4) を WSL2 にマウントする際の公式技術情報の紹介
沼にハマった (失敗した) きっかけは、コマンドに--partition引数をつけ忘れたこと
回り道をしたからこそ気付けた「仮想環境と実機環境で注意するべき違い」や、「検証と学習の目的が混ざる危険性」の共有
記事の趣旨はこういった事態を回避するためのマインドと、それに至るまでのお話

☝️新人エンジニアの方や、それに近しい性質の方向けの記事です。(私がそうなので)

📝 はじめに

本記事は、Windows Subsystem for Linux (以下、WSL2) 上に、「USB 接続された」ext4 ファイルシステムのHDDをマウントし、WSL2 を動かしているホストの Windows 11 から直接エクスプローラでファイルにアクセス出来るようにするための方法について検証を実施した記録です。

文字だと要件がゴチャゴチャしているので、図にするとこう。

USB HDD (ext4)
       │
       ▼
    WSL2 (OracleLinux_9_5)
    ┌─────────────────────────────┐
    │ /mnt/hdd (マウント)          │
    │ Samba or WSL2 標準機能       │
    │                             │
    └─────────────────────────────┘
       │ (localhost)　　　　　　 ▲
       ▼                        | Windows11 マシン内で起動
Windows 11                      |
┌────────────────────┐          |
│ エクスプローラで 　  │──────────
│ 直接読み書き　　　 　│
└────────────────────┘

※前提※

本記事は個人の検証環境で実施した内容です。
また、今回挙げる事例はエンタープライズ向けの商用環境では推奨されない構成です。
本件はコンシューマレベルの事例であり、技術を学ぶ上での視点の参考記事としてご覧ください。
技術部分において記載している内容は私個人が調査・検証したものであり、実際にご自身の大事な環境や職場などで同様の検証を行う際はご本人もしくは貴社の管理責任の下、あくまで検証用としてのみご活用ください。

🙏しかし、そうはならんかった。

今回、「技術検証のつもりが、気づけば自虐エッセイじみた話になった」内容を共有します。
技術としては一発で解決できたはずの内容ですが、私が迷走したことで逆に「検証時に人間がどう判断を誤るか」を可視化できた気がするので今回記事にしてみました。

この事例自体は個人的には笑い話ではありますが、実用的なナレッジもちゃんと含んでいます。
この事例から得た本質は「学習と検証の違い」で、言い換えれば「新人エンジニアが陥りがちな業務における落とし穴」です。
感情ベース一辺倒ではなく、同じ沼に落ちないための情報も散りばめていますので、真面目な心持ちの方も安心して読み進めてください。

想定している読み手は新人エンジニア、ならびに突然開発現場からインフラ現場に飛ばされて困り果てているタイプのエンジニアの皆さんです。
逆にベテランエンジニアの皆様におかれましては、既に何度も通ってきた道かと存じますので、私を通して存分に懐かしい気持ちを味わっていただければ幸いです。

(WSL2 に ext4 ファイルシステムの物理ディスクを読ませる方法がシンプルに知りたいだけの方は、この記事を読むよりは、Microsoft 社の公開情報を熟読することをお勧めいたします。)

🎯 そもそもの検証目的・背景

オンプレの Linux (RockyLinux 9.x) サーバ機で使用していたファイルサーバ用 HDD (ext4) を外付け化しつつ、そのまま Windows クライアント機のエクスプローラ上で扱いたいというニーズがありました
かつ、私は私で今回の件でしっかり学習をしたいので、なるべくサードパーティ製ツールに頼らず、Windows 標準機能での実現を目指し、以下を目的として今回の検証を実施しました。

WSL2 にマウントした USB HDD (ext4) をホストの Windows からエクスプローラで読み書き可能にする
WSL2 と実機 Linux との挙動を比較する
仮想環境でのストレージの扱い・権限管理・ネットワーク構成を改めて理解する
その上で無理なら、サードパーティ製ツールを比較する

🧩 環境情報

項目	内容
ホスト OS	Windows 11 Pro
WSL バージョン	WSL2
WSL ディストリビューション	Oracle Linux 9.5 (Microsoft Store)
HDD（検証対象）	ext4、USB接続 (USB外付け化ケース利用)
元の使用環境	RockyLinux 9.x（x86機にSATA接続）+ Samba共有
(沼に気付く前の) 代替解決案	DiskInternals Linux Reader（サードパーティツール）

検証対象のディスクは、いくらビジネスではないとしても本番のものを使うわけにはいかないので、自前の余っている HDD に ext4 ファイルシステムのパーティションを切り、その中に確認用のファイルやディレクトリを用意しました。
(上記サードパーティツールは読み込み専用のツールです。実際にDLして利用し、ファイルの読み込みとホスト側へのコピー (保存) ができることまでは確認していますが、今回のお話の主題ではありませんので、今後触れることはありません)

🫠 沼の始まり

オチを先に書いちゃうんですが、今回の私の環境の場合、正しいコマンドはこれでした。

wsl --mount \\.\PhysicalDrive6 --partition 1 --type ext4

正しくコマンドを入力していれば、WSL2 が自動で以下のようにマウントしてくれます。

ディスクは '/mnt/wsl/PhysicalDrive6p1' として正常にマウントされました。
注: /etc/wsl.conf で automount.root 設定を変更した場合、場所は異なります。
ディスクのマウントを解除してデタッチするには、'wsl.exe --unmount \\.\PhysicalDrive6' を実行します。

勝手にマウント先を作成してマウントの実施までしてくれます。
以下の形にパスを整形してあげて、ホストのWindowsのエクスプローラのアドレスバーに入れてあげればそのままマウント先を参照できます。
\\wsl$\<WLSディストリビューション名>\<マウント先の絶対パス>
今回の私の場合は、以下の様に表記します。
\\wsl$\OracleLinux_9_5\mnt\wsl\PhysicalDrive6p1

今回の目的は本来これでクリアです。
これで終わっていれば、今頃私は優雅にお昼寝していたことでしょう。

🥲でも、そうはならんかったから今回の記事があります。

初手で私は以下のコマンドを実行しました。

wsl --mount \\.\PhysicalDrive6 --type ext4

はい、パーティション番号を指定していません。

間違いに気づかないままコマンドを実行し、結果の出力を私は素直に読みました。
(個人機での検証なのでそのままコマンドを流していますが、そもそも人が関わる環境に脳死でコマンドは流しちゃダメですよ！)

ディスクがアタッチされましたが、マウントできませんでした: Invalid argument。
詳細については、WSL2 内で 'dmesg' を実行してください。
ディスクをデタッチするには、'wsl.exe --unmount \\.\PhysicalDrive6' を実行します。

ふむ・・・
素直にエラーメッセージを読んだ私は、この順序で考えました。

アタッチは、物理マシンに物理的にディスクドライブを接続するイメージの操作 (裸のディスクを挿しただけ)
マウントはそのディスクドライブを OS で扱うために論理的に接続するイメージの操作 (そのディスクドライブを指定したパス配下に割り当てる行為)
そしてここに書かれている内容は、アタッチはできるけどマウントはできない。なるほど。

そして問題のソースとなる一次情報を探します。
すると、WSL2 の公開情報に USB 接続について書いてあるのを目にします。

=====抜粋ここから=======
外部ドライブを接続していて、これらのマウント手順で成功しない場合は、「USB デバイスを接続する」場合の手順を試してみてください。現在 wsl --mount コマンドは、USB、フラッシュドライブ、SD カードリーダーをサポートしていません
=====抜粋ここまで=======

👁️「技術情報は、頭からケツまで読んで初めて情報たりえる」

「抜粋情報だけを参照することが一番恐ろしい。」
IT の現場を離れて久しい私は、エンジニアが持っていなければならない基本マインドをどこかに落としてしまっていたようです。

ここから前提を履き違えた、一人歩きの検証が始まります。
自戒の意と誰かの参考になればの意を込めて、しっかり書きます。

📚 検証の流れ（時系列）

1️⃣ 接続する HDD の DiskID 特定

Get-CimInstance -Query "SELECT * from Win32_DiskDrive"

[結果] *私用機なのでディスクの乱雑さには目をつぶってください。

DeviceID           Caption                               Partitions Size          Model
--------           -------                               ---------- ----          -----
\\.\PHYSICALDRIVE3 WDC WDS100T2B0C-00PXH0                3          1000202273280 WDC WDS100T2B0C-00PXH0
\\.\PHYSICALDRIVE4 ADATA SX8200PNP                       1          1024203640320 ADATA SX8200PNP
\\.\PHYSICALDRIVE5 USB DISK 2.0 USB Device               1          15521103360   USB DISK 2.0 USB Device
\\.\PHYSICALDRIVE2 HP SSD S700 500GB                     1          500105249280  HP SSD S700 500GB
\\.\PHYSICALDRIVE1 WDC WD10EZEX-22MFCA0                  1          1000202273280 WDC WD10EZEX-22MFCA0
\\.\PHYSICALDRIVE0 WDC WD20EZAZ-00GGJB0                  1          2000396321280 WDC WD20EZAZ-00GGJB0
\\.\PHYSICALDRIVE6 ATA WDC WD10JPVX-08J SCSI Disk Device 1          1000202273280 ATA WDC WD10JPVX-08J SCSI Disk Device

今回のターゲットは一番下の\\.\PHYSICALDRIVE6 です。

2️⃣ `PowerShell` で HDD を `WSL2` にアタッチ（`--bare`）

WSL2 のPowerShell コマンドでファイルシステムを指定してマウントまで持っていこうとするも、先に書いたとおり正しくマウントされませんでした。

よって、マウントまでは実施せず、アタッチのみ行う引数 --bare にて HDD (ext4) を WSL2 にとりあえず接続します。

wsl --mount <DiskID> --bare

この後、PowerShell で WSL2 がマウントしてくれないなら、WSL2内のOracleLinux9.5(以下、WSL2内) の bash で、実機のようにマウントを試みればいいのでは？と考えて実行に移します。

3️⃣`bash` で HDD を `WSL2` 内にマウント

WSL2 内でのディスク情報を確認します。

[user@host-PC ~]$ lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 388.4M  1 disk
sdb      8:16   0   186M  1 disk
sdc      8:32   0     4G  0 disk [SWAP]
sdd      8:48   0 931.5G  0 disk
└─sdd1   8:49   0 931.5G  0 part
sde      8:64   0     1T  0 disk /mnt/wslg/distro
                                 /

[user@host-PC ~]$ sudo fdisk -l

~抜粋~
Disk /dev/sdd: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10JPVX-08J
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xd237d693

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdd1        2048 1953525167 1953523120 931.5G 83 Linux
~抜粋~

[user@host-PC ~]$ sudo blkid

/dev/sdd1: UUID="<ディスクのUUID>" TYPE="ext4" PARTUUID="<パーティションのUUID>"
/dev/sdb: TYPE="ext4"
/dev/sde: UUID="<ディスクのUUID>" TYPE="ext4"
/dev/sdc: UUID="<ディスクのUUID>" TYPE="swap"
/dev/sda: TYPE="ext4"

上記の結果から、今回マウントしたいディスクのデバイスファイル名はsdd、パーティション番号は1と分かります。
(今思えば、ここでパーティション番号の指定忘れに気付けばよかったものを・・・)

この時の私は気付けず、そのままマウントを実施します。

[user@host-PC ~]$ sudo mkdir -p /mnt/hdd

[user@host-PC ~]$ sudo mount -t ext4 /dev/sdd1 /mnt/hdd

マウントが成功します。
結果を確認するために、マウント先を参照します。

[user@host-PC ~]$ ls -l /mnt/hdd

~以下、ファイルとディレクトリ一覧~

この段階で、確認用に入れておいたファイルやディレクトリが確認できました。

4️⃣仮説立て

現時点での状態をまとめると、

USB 接続の HDD だからかどうかは不明だが、現状 PowerShell でアタッチはできてもマウントはできない(と思い込んでいた)。
WLS2 内でマウントすれば、とりあえずWLS2内で確認用に入れておいたファイルやディレクトリは参照できた。

繰り返しにはなりますが、こんな回り道をせず、WLS2 用の PowerShell コマンドでちゃんとパーティション番号を指定し、上手くマウント出来ていれば、今回の事例では以下のパスを Windows のエクスプローラーに入力することで直接 HDD の内容を参照できます。

\\wsl$\OracleLinux_9_5\mnt\wsl\PhysicalDrive6p1

勿論この時の私は気付けていないので、~~方針が更に迷走します~~ 以下の思考順序で仮説を立て始めます。

WSL2 用の PowerShell からマウントができていないため、WSL2 の機能を用いて Windows のエクスプローラから HDD (ext4) の中身を参照することはできない。(これは合っています。)
しかし、WSL2 内からマウントしたところ、WSL2 内ではその中身を参照することができた。
つまり、実機 Linux のように Samba を用いて、そのマウントポイント配下をファイルサーバ化すれば、Windows のエクスプローラ上で参照ができるのではないか。

一見間違っていませんし、実際これ自体は技術的には可能なように思えます。
故にここから沼り方が複雑化し、考えることや視点がブレ始めます。

そのお陰で再認識できることや新しい知見を得ることができたので、学習としてはよかった側面が大きいです。
ただし、検証としては回り道が多くなり時間を多くかけた挙句、自身の頭のリソースや体力もかなり割かれてしまいました。
これが仮に業務であればただでさえ短い納期が更に短くなり、エンジニア側は自信の首を絞める形で追い詰められてしまいます。

👾閑話休題

ここからは、技術情報云々というよりは、一人の迷走するエンジニアもどきの、思考の過程として参考にしていただけますと幸いです。

※ここから先の内容は、失敗の思考過程＝読み物要素がより強いパートです。技術的要素だけを知りたい方は下部の「技術的補足」まで飛ばすことをお勧めいたします。

読んでくださっている皆様がどう考えるかは私には分かりませんが、業務ではこの沼り方では済まないこともあるので、敢えて詳細を書き残しています。
新人エンジニアも中堅エンジニアも、時にはベテランの方も技術的要素の沼と納期のせめぎ合いによって体調を崩したり、業務形態 (開発、運用、サポートetc...) や立場によって顧客と現場の板挟みになって、どうしても頭のリソースの余裕がなくなったりしがちな職種です。
私は現場を離れているとはいえ、別に新人と名乗れる歴でもないので、逆に「うるさいくせに使えないな・・・」と思う先輩や上司がいたらこんな思考のこじれ方をしてるのかもしれない、と優しい気持ちになってみてください。あなた自身もちょっとラクになると思います。
日々プレッシャーと忙しない業務で心が疲弊しているであろう新人の皆さんには、変に感情面にまで責任感やら何やらが及んで潰れてしまったり、逆に他人に厳しい「だけ」のエンジニア(笑)になったりしないことを祈ります。
ただでさえ頭をめっちゃ使う仕事なので、せめて感情のリソースにはゆとり、持とうね！

😇その後の検証

※以下は間違った方向に進んだ検証です。内容自体は正しいですが、今回のケースではここまでやる必要はありませんでした。(学びとしては有益でした)

ファイルサーバ (`Samba`) 導入

[user@host-PC ~]$ sudo dnf install samba samba-client samba-common -y

ここで別観点の課題にぶち当たります。
実機や私がこれまで触れてきた仮想環境 (VirtualBoxなど) とは違い、WLS2 内に作成するLinuxディストリビューション (少なくとも OracleLinux) はデフォルトでは Systemctl コマンド (Systemdサービスマネージャー) が使用できません。
詳しい解説は Microsoft 社の公開情報に書いてありますので、実際に WSL2 を活用される方は読んでみてください。

この時の私は、ひとまずSystemctl コマンドを使えるようにするための対応を実施しました。

OracleLinux9.5 の場合の例ですので、ご自身が選択したディストリビューションに合わせて適宜読みかえてください。

[user@host-PC ~]$ sudo vim /etc/wsl.conf

wsl.conf

[boot]
systemd=true

その後、WLS2 を一旦シャットダウンし、再度立ち上げます。

wsl --shutdown         # WSL2 を完全停止

ディスクのアタッチ、マウントが外れているので再度 PowerShell でアタッチ、WLS2 内の Bash でマウントします。

wsl --mount \\.\PhysicalDrive6 --type ext4

sudo mount -t ext4 /dev/sdd1 /mnt/hdd

Sambaへのアクセス自体はホストの Windows マシンから出来る状態になりました。
しかし、この状態だと HDD (ext4) の中身は見えませんでした。

パーミッション (権限) の変更

これはパーミッション(権限)の問題だろうと考え、ひとまず検証環境なので誰でも何でもできる権限をHDD (ext4) 内部のファイル全体に付与しなおします。

sudo chmod -R 777 /mnt/hdd

※ここで指定しているchmodコマンドの引数777は「検証だから実施できる例」です。
実運用や外部ネットワークとの接点がある環境では推奨されない（非常に危険な）設定です。
検証のために必要な場合でも、設定する際は携わっている案件の上長や責任者に確認を取ってから実施しましょう。

・・・それでも Windows マシン側からは何も見えない。
ファイルやディレクトリの権限がフルオープンの状態なら、見えないなんてことはないだろうと私は考え、これは権限の問題ではないと区切りを付けました。

Samba の UID/GID についての仕様

次に、Samba の仕様について改めて調査しなおしました。
すると、以下のような情報がありました。

以下、Samba における UID／GID と Windows 側認証のマッピング（ID Mapping）に関する公式ドキュメントのソースです。

“In the SMB protocol, users, groups, and machines are represented by their security identifiers (SIDs). On POSIX system Samba processes need to run under corresponding POSIX user identities and with supplemental POSIX groups to allow access to the files owned by those users and groups. The process of mapping SIDs to POSIX users and groups is called IDENTITY MAPPING or, in short, ID MAPPING.”
Samba.conf (Samba公式)

“Samba is instance of mapping between Windows SIDs and UNIX UIDs and GIDs.”
3.4. Samba ID マッピングの理解および設定 (RHEL Docs)

“Whenever Samba performs an operation on the Unix filesystem on behalf of the Windows client, the user must have a valid UID and GID on the local Unix system.”
Chapter 9. Users and Security (Samba公式)

つまり、

UID/GID は Linux ファイルシステム (今回の場合ext4) と Samba ユーザー認証の橋渡し役
Samba でアクセスできない場合は権限だけでなく UID/GID のマッピングも確認する必要がある
別のシステムで用いていた HDD (ext4) の場合、元の Linux 環境での UID/GID がそのまま残るので、WLS2 内で新規作成したユーザーのもつUID/GID とは必然的にズレる

なるほどな、普通に知りませんでした・・・お恥ずかしい・・・

ですが、私はこのあたりで気付き始めるのです。
「これ、どう考えても正攻法ではないし、絶対他にいい方法がある・・・」

ここで私は手順を引き返して最初から見直すか、次の仮設を立てて検証を次のステップに進めるかの選択をすることになります。
今回の場合、私は引き返したことで正解を引くことになりますが、この先に進んでいたら更なる知識的な学びを得られることと引き換えに、おそらく無限の時間と頭のリソースを使うことが容易に想像できます。

🥶 やらかしの流れ

wsl --mount \\.\PhysicalDrive6 --type ext4 (パーティション番号の入れ忘れ)
エラーメッセージを素直に読んでしまう → 「--bare でアタッチだけやってWLS2内でマウントすればいいのでは」
そのまま先に進み、ファイル権限・Samba の仕様について実機とWLS2の差や本来の仕様を調べ始める
謎の試行錯誤を延々と続ける・・・
手順を最初に引き返して、--partition 1 を入れたら一発で解決
　💀「え？もう見えるんだけど…？」

技術的補足

読み物の要素が多い記事になってしまいましたが、Qiita の趣旨から外れてはいけませんので、最低限ではありますが、技術的内容の補足をいたします。

ディスクがパーティション分割されていない場合は、--partition オプションは省略できます。
今回私が用いたHDD (ext4) は既にパーティションを切ってある (既にデータが入っている) 状態であったため、番号の明示が必要だったものと推察しております。
これも冒頭にリンクを貼ったMicrosoft 社の公開情報に記載があります。
=====抜粋ここから=======
ディスク全体を 1 つのボリュームとしてマウントする場合 (ディスクがパーティション分割されていない場合) は、--partition を省略できます。
=====抜粋ここまで=======

今回のケースでは --partition 1 を指定することで正しく WSL2 によるマウントが可能となりましたが、複数パーティションが存在するディスクを接続する場合、明示的にパーティション番号を指定しないと WSL 側で認識されない（または誤認識する）場合があります。

USB デバイスはサポートされていない旨の記載部分を抜粋しましたが、あくまでwsl --mount コマンドにおける記述の抜粋です。 今回は標準機能のみでの実装を主目的としておりましたので、エピソード内では触れてはおりませんが、実際は拡張機能としてオープンソースの紹介をしている Microsoft 社の公開情報が別途存在しており、技術的要素でお困りの方はこちらが参考になるかも知れません。
(Microsoft 社が他社や他団体のツールそのもののサポートを提供しているかどうかは私には分かりません。個人的にはあくまで紹介記事であると考えて読むことをお勧めいたします。)

要するに、今回の件は、USB 接続だから失敗したのではなく、単純に --partition オプションの指定ミスであり、USB 接続であっても、WSL2 側からディスクドライブとして認識できており、かつ正しくパーティションを指定すれば基本的には問題ないはずです。ただし、外付け化ケースや内臓させるディスクドライブなどのハードウェア起因で予期できない動作が発生する可能性はあります。

補足にはなりましたが、改めて情報は頭から最後まで通して読まなくてはならない、という教訓を痛感する出来事であることを補強する内容だと考えております。

😭私が学んだこと

学び	内容
複雑な原因を疑う前に基本を確認	情報は頭からケツまで読んで初めて情報たりえる
CLI オプションはちゃんと読む	慣れたコマンドこそ毎回ドキュメントを読もう
仮説は時々リセットする	“もっと単純では？”と考える
極端に疑い出したら一旦寝ろ	たまに本当に寝た方が早い

✨まとめ

今回の問題は環境の差や、USB接続による動作云々ではなく、単純に私という人間の入力ミスによって発生していました。
次に似たような検証をする機会があれば、以下のようなプロセスで実施したいと考えています。

一次情報（公式）を最初に熟読する
小さく再現 → ログ確認 → 仮説修正の順に事実ベースで行う
“USBだから無理”などの断定は最後の砦に使うに留める

|| 🧠 技術的な問題の多くは「人間の思い込み」から始まる

この経験を共有することで、誰かが同じような沼に落ち、その経験を重ね過ぎることで、皆さんが潰れてしまったり、逆に苦労を他人に押し付けるようなマインドを持つことを防げたら幸いです。

おまけ

# 例：検証用ターミナルに入れたい alias

alias never_forget_partition="echo 'Check --partition 🔥'"
echo 'alias never_forget_partition='"'"'echo Check --partition 🔥'"'"'' >> ~/.bashrc