シナリオ
外付けドライブを接続したり、新しいディスクを追加したり、再起動後にパーティションをマウントしようとしたりすると、次のエラーが表示されます：
mount: /mnt/data: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or helper program, or other error
ディスクは lsblk で正常に表示されているのに、マウントに失敗します。このエラーには5つの異なる原因があり、修正方法はどの原因に該当するかによって異なります。
まず診断する
何かを触る前に、ここから始めましょう。パーティションに実際にどのファイルシステムがあるかを確認します：
sudo blkid /dev/sdb1
典型的な出力：
/dev/sdb1: UUID="a1b2c3d4-..." TYPE="ext4" PARTUUID="..."
blkid から出力がない場合、パーティションはフォーマットされていないか、破損しているか、または間違ったデバイスを指定しています。以下で確認してください：
lsblk -f
sudo fdisk -l /dev/sdb
原因1：ファイルシステムタイプの指定が間違っている
これが最も一般的な原因です。ext4 を ntfs として、または vfat を ext4 として読み込もうとしても動作しません。修正方法は2つあります：
# カーネルに自動検出させる（90%の場合に機能する）
sudo mount /dev/sdb1 /mnt/data
# または blkid の出力から正確なタイプを指定する
sudo mount -t ext4 /dev/sdb1 /mnt/data
sudo mount -t ntfs /dev/sdb1 /mnt/data
sudo mount -t vfat /dev/sdb1 /mnt/data
sudo mount -t exfat /dev/sdb1 /mnt/data
ntfs や exfat で「missing codepage or helper program」エラーが出る場合、ユーザースペースツールがインストールされていません。別途修正が必要です：
# Ubuntu/Debian
sudo apt install ntfs-3g exfatprogs
# CentOS/RHEL
sudo yum install ntfs-3g exfatprogs
# Arch
sudo pacman -S ntfs-3g exfatprogs
その後、マウントを再試行してください。
原因2：スーパーブロックの破損
スーパーブロックにはブロックサイズ、inode 数、UUID などの重要なファイルシステムメタデータが格納されています。損傷するとカーネルはファイルシステムをまったく読み込めなくなります。まず読み取り専用チェックを実行して状況を確認しましょう：
sudo fsck -n /dev/sdb1
ここで -n フラグが重要です。何も変更せずに問題を報告します。エラーが表示された場合は、アンマウントして実際の修復を行います：
sudo umount /dev/sdb1
sudo fsck -y /dev/sdb1
-y フラグはすべての修復プロンプトを自動承認します。中程度の破損がある一般的な 500 GB の ext4 パーティションの場合、2〜5 分かかります。その後、再度マウントを試みてください。
プライマリスーパーブロックが完全に失われた場合、ext2/ext3/ext4 は固定オフセットにバックアップコピーを常に書き込んでいます。それらを探しましょう：
sudo dumpe2fs /dev/sdb1 | grep -i superblock
出力はこのようになります：
Primary superblock at 0, Group descriptors at 1-6
Backup superblock at 32768, ...
Backup superblock at 98304, ...
最初のバックアップを選択して修復に使用します：
sudo e2fsck -b 32768 /dev/sdb1
その後、通常通りマウントします。
原因3：ダーティビットが設定されている（NTFS）
強制シャットダウン、電源切断、または高速スタートアップを有効にした Windows マシン — これらはすべて NTFS パーティションにダーティフラグを残します。Linux はそれがクリアされるまで読み書き可能でマウントすることを拒否します。まずステータスを確認します：
sudo ntfsfix -n /dev/sdb1
ダーティフラグが確認された場合はクリアします：
sudo ntfsfix /dev/sdb1
これは応急処置として機能します。Windows 側の根本原因については、高速スタートアップをオフにします：コントロールパネル → 電源オプション → 電源ボタンの動作を選択する → 高速スタートアップを有効にする → チェックを外す。そうしないと、Windows がシャットダウンするたびにフラグが戻ってきます。
原因4：間違ったデバイスノードを指定している
意外と多い間違い — パーティションではなくディスク全体をマウントしてしまうことです：
# 間違い — /dev/sdb はディスク全体で、ファイルシステムはない
sudo mount /dev/sdb /mnt/data
# 正しい — /dev/sdb1 は最初のパーティション
sudo mount /dev/sdb1 /mnt/data
ディスク上のすべてのパーティションを一覧表示して確認します：
sudo parted /dev/sdb print
原因5：マウントポイントが存在しない
小さなことですが、見落としやすいです。/mnt/data がまだ存在しない場合、マウントは試みる前に失敗します：
sudo mkdir -p /mnt/data
sudo mount /dev/sdb1 /mnt/data
/etc/fstab による永続的な設定
このディスクを毎回起動時にマウントしたい場合、/etc/fstab に追加します。デバイス名の代わりに UUID を使用してください — 別のディスクを追加すると /dev/sdb1 が /dev/sdc1 に変わる可能性がありますが、UUID は変わりません：
# UUID を取得する
sudo blkid /dev/sdb1
# 出力: /dev/sdb1: UUID="a1b2c3d4-5678-..." TYPE="ext4"
この行を /etc/fstab に追加します：
UUID=a1b2c3d4-5678-... /mnt/data ext4 defaults,nofail 0 2
nofail オプションについて理解しておく価値があります：これがないと、ディスクが見つからないか失敗した場合に、タイムアウトを待つために起動が 90 秒間ハングします。これがあると、システムは正常に起動し、単純にマウントをスキップします。再起動せずにエントリをテストします：
sudo mount -a
エラーがなければ完了です。
修正を確認する
# マウントされていることを確認する
mount | grep sdb1
# または
df -h | grep /mnt/data
# ファイルを読み込めることを確認する
ls /mnt/data
# 簡単な書き込みテスト
touch /mnt/data/testfile && echo "Write OK" && rm /mnt/data/testfile
何もうまくいかない場合
blkid が何も返さない。fsck が修復できない。パーティションテーブルまたはファイルシステムが深刻に破損している — ハードウェア障害の可能性があります。その時点で、すぐにディスクへの書き込みを停止してください。
testdiskでパーティションテーブルを復元する：sudo apt install testdisk && sudo testdisk /dev/sdbphotorec（testdisk に付属）で個別のファイルを復元する- ドライブが物理的に故障していると疑う場合は、まず
ddrescueでクローンを作成し、そのクローンで作業する
# 故障しているディスクをクローンする — 他の何よりも先にこれを行う
sudo apt install gddrescue
sudo ddrescue -d -r3 /dev/sdb /dev/sdc recovery.log
-r3 フラグは ddrescue に不良セクタを最大3回再試行するよう指示します。失敗したセクタをログに記録するため、処理が中断されても再開できます。