Ubuntu ENOTBLK (15) 対策：ブロックデバイス必須エラー「Block device required」発生時の適正デバイス指定編

【注意】本記事は「ENOTBLK (15) / Block device required」発生時の一般的な整理と確認手順をまとめた技術情報です。実環境ではストレージ構成（RAID/LVM/暗号化/仮想化/コンテナ）や権限、影響範囲が案件ごとに大きく異なります。誤ったデバイス指定はデータ損失や復旧不能につながるため、判断に迷う場合は株式会社情報工学研究所のような専門事業者に相談してください。

　

第1章：また運用が増えるのか…と思った矢先の「Block device required」—現場のモヤモヤから始める

深夜の障害対応で、ログを追いながら「とりあえず復旧」を急いでいるときに限って出てくるのが、この手の“当たり前を要求してくる”エラーです。

「え、今まで動いてたのに？」「いつもの手順で mount しただけなのに？」──そんなタイミングで ENOTBLK (15): Block device required を踏むと、正直こう思いますよね。

「また新しい罠か…これ以上、運用のタスク増やしたくないんだけど。」

この感情は自然です。むしろ健全な疑いです。なぜなら ENOTBLK は“操作対象がブロックデバイスであること”を前提にした処理が、別の種類のパスやオブジェクトに向けられたときに起きるからです。つまり、根っこは「設定ミス」というより境界（デバイスの種類）の取り違えです。

---

現場でやりがちなパターンは、大きく次の3つに集約されます。

• パスの取り違え：/dev/sdX ではなくマウントポイント（/mnt/data など）を渡している、あるいはディレクトリを渡している

• デバイスの“見え方”の変化：コンテナや権限の制約で /dev が見えていない、udev で名前が変わった、by-id を使っていない

• “ファイルっぽいもの”への誤信：ループバック用の通常ファイル、デバイスを指すはずのシンボリックリンク、mapper 名の誤記など

本記事の狙いは、ここで慌てて場当たりの「ダメージコントロール」をするのではなく、原因の切り分けを最短で収束させることです。そのために、まずは「ENOTBLK は何を怒っているのか」を正確に言語化し、次に「どのコマンドが何を要求しているのか」を整理し、最後に「再発防止のチェック」を仕組みに落とします。

結論だけ先取りすると、ENOTBLK は“ブロックデバイスであるべき箇所に、ブロックデバイスではないものが来た”という一点に尽きます。以降、その一点へ向けて伏線を回収していきます。

　

第2章：ENOTBLK(15) の正体—「ブロックデバイス必須」はどこで決まる？（errno の意味を正確に読む）

ENOTBLK は errno の1つで、値は Linux では一般に 15 として扱われます。メッセージは “Block device required”。この文言が示す通り、ブロックデバイス（/dev/sda, /dev/nvme0n1, /dev/mapper/xxx など）を要求する処理が、別の種類の対象に対して実行された状態です。

ここで重要なのは、ENOTBLK が出た瞬間に「Ubuntu の不具合」と決めつけないことです。多くの場合、OSは“仕様どおり”に怒っています。つまり、エラーはあなたの状況説明を短くしてくれているだけです。

---

ブロックデバイスとは何かを、最小限で整理します。

• 通常ファイル：/var/log/xxx や /home/user/file.img など。read/write はできるが、ディスク固有の ioctl（セクタサイズ取得など）は前提にならない。

• ブロックデバイス：ディスクやパーティション等。ファイルシステムの作成、マウント、パーティション操作など“ディスクとして扱う”操作の対象。

そして、どこで「ブロックデバイス必須」が決まるかというと、多くは次のどちらかです。

• ユーザーランドツールが事前チェック（stat(2) で S_ISBLK 判定など）し、違えば ENOTBLK を返す/表示する

• カーネルへの ioctl などがブロックデバイス前提で、そこで ENOTBLK が返る

つまり、アプリ側が賢くても賢くなくても、最終的に「ブロックデバイスじゃないならダメ」という境界に当たります。

よく絡むコマンドと“要求される対象”の対応表

現場で混乱が起きやすいので、代表例を表にまとめます（実際の挙動は引数やオプションでも変わるため、あくまで典型パターンの整理です）。

操作	典型コマンド	要求される対象	取り違え例
マウント	mount /dev/sdb1 /mnt	ブロックデバイス or 有効なソース	/mnt を “ソース側” に渡す
FS作成	mkfs.ext4 /dev/sdb1	ブロックデバイス	通常ファイルや誤ったパスを渡す
パーティション操作	fdisk /dev/sdb	ブロックデバイス	ディレクトリやリンク先が別物
ループデバイス関連	losetup /dev/loop0 file.img	/dev/loop0 はブロックデバイス	loop 側ではなく file.img 側を“デバイス扱い”してしまう

---

ここまでが「正体」の話です。次章では、実際に現場で起きる“取り違え”を具体的に言語化します。ポイントは、人間の目には似て見えるパス（/dev/mapper、/dev/loop、マウントポイント、シンボリックリンク）が、カーネルから見ると別物だという点です。ここを押さえると、ENOTBLK は急に“説明可能なエラー”になります。

　

第3章：「ファイルっぽいもの」を渡した瞬間に崩れる—/dev/loop・/dev/mapper・ディレクトリ取り違えの伏線

ENOTBLK が厄介なのは、対象が“それっぽく見える”ときに起きることです。/dev 配下の名前、mapper の論理名、loop という単語、そしてマウントポイント。全部、人間の脳内では「ディスクに関係する何か」に分類されがちです。

でも、OSが見ているのは「分類」ではなくファイル種別です。ここで一度、現場の“心の会話”をそのまま出します。

「/dev/mapper/xxx って書いてあるし、ディスクでしょ？」

「file.img も ‘ディスクイメージ’ って言うし、ディスクでしょ？」

「/mnt/data もストレージの場所だし、同じようなもんでしょ？」

──この “でしょ？” が危険です。ENOTBLK は、まさにその誤解に対するブレーキです。

---

伏線1：マウントポイントを“ソース”にしてしまう

最頻出はこれです。マウントする側（ソース）と、マウントされる側（ターゲット）を混同して、ディレクトリをソースに渡してしまう。ツールやスクリプトの引数順、変数名が曖昧だと起きます。

（例）mount /mnt/data /mnt/restore ← /mnt/data はディレクトリ（ターゲット側のはず）

このとき必要なのは、「そのパスは何者か？」を即答できる確認です。

• ls -l でリンクかどうか

• stat でファイル種別

• lsblk でブロックデバイスの一覧に出るか

これだけで、取り違えの多くは“その場で鎮火”できます。

---

伏線2：ループバック（file.img）を“ブロックデバイス扱い”してしまう

file.img はあくまで通常ファイルです。ディスクイメージであっても、カーネルから見れば通常ファイル。ディスクとして扱いたいなら、ループデバイス（/dev/loopX）に関連付けて初めてブロックデバイスになる、という段階が入ります。

「手元の .img を mkfs に投げたら ENOTBLK」みたいな場合、ここが原因のことがあります（ただし mkfs は通常ファイルを許すケースもあるため、コマンドや実装で差が出ます。だからこそ“確認”が必要です）。

重要なのは、「file.img という“名前の雰囲気”」ではなく、いま対象が S_ISBLK かを見て判断することです。

---

伏線3：/dev/mapper の論理名が、別物を指している

/dev/mapper/xxx は、LVM や dm-crypt（暗号化）、multipath などの論理デバイスを指すことが多い一方、運用の歴史が長い環境だと、似た名前が並んでいたり、シンボリックリンクが増えていたりします。

「それっぽい名前を選んだら ENOTBLK」──このときは、実体を追跡するのが早いです。

• readlink -f でリンクの最終到達点を見る

• ls -l /dev/mapper でメジャー・マイナー番号の雰囲気を掴む

• lsblk -f で UUID/FS 種別まで合わせて確認する

ここでのコツは、パス名に頼らず、UUID や by-id のような“揺れにくい識別子”で参照を固定していくことです。これが次章以降の「再発防止」に直結します。

---

この章のまとめはシンプルです。ENOTBLK は、あなたが“ディスクのつもり”で渡したものを、OSが「それはディスクじゃない」と教えてくれている状態です。ここで焦って手順を積み増すと、状況が悪化しやすい。まずは対象がブロックデバイスかどうかを確認してから次へ進む──この一手で、議論の過熱や手戻りを抑え込みやすくなります。

　

第4章：再現して腹落ちさせる—mount / mkfs / fdisk / losetup が ENOTBLK を吐く最短パターン

障害対応中に「原因を考える余裕がない」状態だと、同じミスが繰り返されやすいです。そこで有効なのが、落ち着いた時間に“再現できる最短パターン”を手元で作っておくことです。再現できると、現場でエラーを見た瞬間に「これはパス取り違えだな」「これはデバイス露出の問題だな」と判断が速くなり、収束が早くなります。

ここでは、危険な実ディスクを触らずに済むように、基本は確認コマンド（stat/lsblk）中心で説明します。実際にコマンドを試す場合は、検証用のVMや使い捨て環境で行い、対象デバイスを必ず二重三重に確認してください。

---

パターンA：ソースにディレクトリを渡す（mount の取り違え）

マウントの典型は「ソース（デバイス）→ターゲット（空ディレクトリ）」です。これを逆にしたり、ディレクトリをソースにしてしまうと、状況により ENOTBLK あるいは別のエラーが出ます。

• 確認：ソース候補がブロックデバイスかどうかを stat で見る

stat /mnt/data # ここが「directory」なら、ソースにするのは不自然

• 確認：lsblk で “候補” がブロックデバイスとして見えているか

lsblk # /dev/sdX, /dev/nvme0n1, /dev/mapper/... が出る

ここで「/dev/... ではなく /mnt/... を渡している」ことに気づければ、その時点で場が整います。再発防止の観点では、スクリプトの変数名（SRC, DST）と引数順を固定し、実行前に “SRC はブロックデバイスか？” を検査するのが効果的です。

---

パターンB：fdisk に “ディレクトリ” や “通常ファイル” を渡す

fdisk は原則ブロックデバイスを前提とします。対象がブロックデバイスでない場合、ENOTBLK が出ることがあります。

fdisk /tmp # /tmp はディレクトリなので対象として不正

この手のミスは、「デバイス名が変わった」「スクリプトの変数が空になった」「引数が欠けた」などで起きます。つまり、人間が意図した値が、実際には入っていないケースです。ここは“手順”より“入力検証”の問題なので、後半で扱う事前チェックが効いてきます。

---

パターンC：losetup の “関連付け先” を取り違える

ループバックは、通常ファイル（イメージ）をブロックデバイスとして扱うための仕組みです。ここで混乱が起きるのは、

• 「file.img をデバイスだと思う」

• 「/dev/loopX が存在しない・見えない（コンテナ/権限）」

の2系統です。再現としては、まず “どちらが何者か” を stat で見るのが確実です。

stat file.img # regular file なら通常ファイル
stat /dev/loop0

block special file ならブロックデバイス

もし /dev/loop0 が存在しない場合、カーネルモジュールやデバイスノード、コンテナのデバイス許可の問題が疑われます（この話は第6章で回収します）。

---

パターンD：mkfs で “対象の取り違え” を起こす

mkfs はブロックデバイスに対してファイルシステムを作成する目的で使われます。ここで ENOTBLK に遭遇した場合は、

• 指定したパスがブロックデバイスではない

• パーティション名の誤り（/dev/sdb1 のはずが /dev/sdbI など）

• /dev/mapper の名前取り違え

が典型です。危険なのは、mkfs は本当に実行されると破壊的な操作になり得ることです。ENOTBLK は、その破壊的操作の前に「対象が違う」と教えてくれている可能性があります。ここで焦って別のパスを試行錯誤で当てに行くのは危険です。落ち着いて “どの識別子でデバイスを特定すべきか” に戻るのが安全です。

---

この章で押さえたいのは、再現が目的ではなく、再現を通して「確認ポイントが明確になる」ことです。ENOTBLK は、運用の場で“原因を隠す”のではなく、むしろ「型の取り違え」という本質を露出させます。ここを理解できると、次章の「ブロックデバイスの型の違い」に自然に接続できます。

　

第5章：根っこは “型” の違い—通常ファイルとブロックデバイスで許される操作（open/read/write vs ioctl）

ENOTBLK を“腹落ち”させる近道は、「ブロックデバイスはファイルに似ているが、同一ではない」という点を、操作レベルで理解することです。Linuxでは「何でもファイル」という言い回しが有名ですが、実務ではここが誤解の温床になります。

心の中でこう思ったこと、ありませんか？

「/dev/sdb もファイルっぽいし、cat できるなら同じでしょ？」

似ています。でも、同じではありません。ブロックデバイスは “ディスクとしての性質” を持つために、通常ファイルにはない前提（セクタ、アライメント、キャッシュ、I/Oスケジューリング等）があります。そしてツールは、その前提にアクセスするために ioctl を使うことが多い。そこで「ブロックデバイスであること」が必須条件になります。

---

“型” を見分ける最小の事実

型の見分けは、運用手順に落とし込むなら次の1行で十分です。

• stat で “block special file” かどうかを見る

これが true なら、そのパスはブロックデバイスです。false なら、通常ファイル・ディレクトリ・リンクなど、別の型です。

ツールが何をしたいかで “必須” が決まる

代表例を、もう少し“操作”に寄せて整理します。

ツールがやりたいこと	必要になりがちな情報	ブロックデバイスが必須になりやすい理由
セクタ/サイズ/ジオメトリの取得	ブロックサイズ、総セクタ数など	通常ファイルには“ディスク固有”の情報がない
パーティションテーブルの操作	ディスク先頭領域への読み書き	対象がディスクでなければ意味がない
ファイルシステムの作成	ブロック単位の配置・整合性	FSはブロックデバイス前提の設計が多い

---

ここでの要点は、ENOTBLK を「そのツールが “ディスクの性質” に触れようとした証拠」と捉えることです。だから次にやるべきは、

• 対象パスの型を確認する

• そのツールが要求する対象（ディスク/パーティション/マッパー/loop）を正しく選ぶ

• 選び方を“揺れない参照”へ寄せる

の順番です。

次章では、この“型の確認”を現場で即実行できる形に落とし込みます。特に、コンテナ/VMで「そもそもブロックデバイスが見えていない」ケースは、手順の問題ではなく構成の問題なので、ここを早く見抜くことが重要です。

　

第6章：まず疑うべき3点—指定パスの実体・権限・コンテナ/VMのデバイス露出（「見えてない」を見抜く）

ENOTBLK に遭遇したとき、現場が一番つらいのは「原因候補が多すぎて、説明が長くなる」ことです。上司や関係者に状況を共有するにも、言葉が増えるほど議論が過熱しやすい。

そこで、最初に疑うべき点を3つに固定します。ここを順に潰すだけで、だいたいのケースは収束に向かいます。

（1）指定パスの実体：それは本当にブロックデバイスか

まず「パスが何者か」を確認します。名前の雰囲気ではなく、型で判断します。

• stat：ブロックデバイスか（block special file）

• ls -l：シンボリックリンクか、リンク先はどこか

• lsblk：ブロックデバイスとして列挙されるか

ここで「ディレクトリ」「通常ファイル」「リンク先が想定外」などが判明したら、原因はほぼ確定です。手順を増やすより、入力（指定）を正しくするのが先です。

---

（2）権限：デバイスが見えていても “触れない” ことがある

ブロックデバイスを扱う操作は、権限の影響を強く受けます。典型は以下です。

• mount：一般に管理者権限や適切な capability が必要

• デバイスノード：/dev/sdb1 などはパーミッションやグループで制御される

• udev ルール：環境によってデバイスの所有者・権限が変わる

ここで重要なのは、「権限不足＝別の errno になる」と決めつけないことです。ツール実装や呼び出し順によっては、権限の前に “対象の型チェック” をして ENOTBLK が先に出ることもあり得ます。

したがって、権限確認は “後追い” ではなく、最初の3点セットの一部として扱うのが実務的です。やることはシンプルで、対象デバイスのパーミッションと、実行ユーザーの所属（sudo の有無）を淡々と確認します。

---

（3）コンテナ/VM：そもそもデバイスが “露出していない”

近年、ENOTBLK まわりで増えているのがこの系統です。ホスト側では /dev/sdb が存在するのに、コンテナ内では見えない、あるいは別物として見える。すると「いつものパス」を渡しても、コンテナ内ではディレクトリ扱いだったり、存在しなかったりします。

代表例として、コンテナ環境ではブロックデバイスを直接扱うには追加設定が必要になることがあります（例：デバイスの明示的な割り当て、必要な権限の付与など）。これは“運用手順”ではなく“システム構成”の話です。

現場の独り言で言うと、こうです。

「コマンドは合ってるはず。…でも、そもそも中からディスクが見えてないのか？」

この疑いを早く持てると、無駄な試行錯誤に歯止めがかかります。確認の軸は次の通りです。

• コンテナ/VM 内で lsblk が何を出しているか（ホストと一致するか）

• /dev 配下のデバイスノードが存在するか

• その操作に必要な権限が付与されているか（特に mount やデバイス操作）

この3点は、結局のところ「その環境で“ディスクとして触れる対象”が何か」を確定させる作業です。確定できれば、ENOTBLK は“よくある事故”として被害最小化に回せます。

---

この章のまとめです。ENOTBLK が出たら、まずはパスの実体、次に権限、そしてコンテナ/VMの露出。この順でチェックを固定すると、場当たりの対応が減り、説明も短くなります。次章では「正しいデバイス指定」を“揺れない参照”に寄せる方法を扱います。

　

第7章：正しいデバイス指定の決め方—lsblk / blkid / by-id / UUID で「揺れない参照」を作る

ENOTBLK の再発を減らす最大のコツは、「その場で正しいものを当てる」よりも、次回も同じものを指せる参照に寄せることです。

/dev/sdb1 のような名前は分かりやすい反面、接続順や環境差で変わることがあります。特にUSB接続、仮想環境、複数台構成、障害時の交換などでは、名前が揺れることが現実に起きます。そこで、確認と指定の軸を分離します。

ステップ1：lsblk で「全体像」と TYPE を見る

まず lsblk で、ディスク→パーティション→LVM/暗号化→マウントという流れを俯瞰します。ここで大事なのは “NAME” だけでなく “TYPE” と “MOUNTPOINT” です。

• disk / part / lvm / crypt / raid 等の種別を見て、どこを操作対象にすべきか当たりを付ける

• すでにマウントされている対象を誤って加工しない（破壊的操作の抑え込み）

---

ステップ2：blkid で UUID・TYPE を見て「同定」を固める

blkid は、ブロックデバイスに付随する識別子（UUIDなど）やファイルシステム種別を確認する手段として広く使われます。ここで “自分が触りたい対象” が何であるか（目的のFSか、暗号化層か、LVMか）を一致させます。

例えば「復旧のために ext4 のパーティションを読み取りでマウントしたい」のに、crypt 層や PV（LVM物理ボリューム）を直接触ろうとしていると、手順が迷走しやすいです。目的に合わせて、見るべき層を一致させるのがポイントです。

---

ステップ3：/dev/disk/by-id や UUID で「揺れない参照」に寄せる

運用スクリプトや構成ファイルで “/dev/sdX” を直書きすると、将来の揺れが事故になります。そこで一般には、環境に応じて次のような参照が使われます。

• /dev/disk/by-id/：デバイス固有の識別に寄せやすい（機器単位で追いたいとき）

• UUID/PARTUUID：ファイルシステムやパーティションの識別に寄せやすい（マウント対象を固定したいとき）

• /dev/mapper/（LVMや暗号化）：論理名で運用する場合は、名称の命名規約と管理が重要

ここでの注意点は、「どれが絶対に正しい」ではなく、運用の目的に合わせて選ぶことです。ディスク交換があり得るなら、機器固有の参照に寄せすぎると交換時に運用が止まります。逆に、同名の論理ボリュームが並ぶ環境で論理名だけに頼ると、取り違えが起きます。

---

“揺れない参照” を作ると ENOTBLK が減る理由

ENOTBLK の多くは「取り違え」です。取り違えは、次の2つが重なると起きます。

• 識別が揺れる（/dev/sdX など）

• 確認を省略する（焦り、夜間、手順のコピペ）

参照を揺れにくくし、確認を定型化すると、取り違えが起きにくくなります。つまり、ENOTBLK を“その場で消す”のではなく、出会う頻度そのものを下げる方向へ持っていけます。

---

まとめです。lsblk で全体像、blkid で同定、by-id/UUID で参照の固定。この流れをチームの手順に組み込むと、ENOTBLK は「またか…」から「はいはい、まず同定ね」という温度感に落ち着きます。次章では、/dev/sdX 直書きのリスクを抑え込み、LVM/RAID/mapper などを含む構成での指定ルールを整理します。

　

第8章：/dev/sdX 直書きの事故を減らす—パーティション/mapper/LVM/RAID での指定ルール

ここまでで「ENOTBLK の本質は型の取り違え」「再発防止には同定と参照の固定」が見えてきました。次に現場で効くのは、どの層を指定すべきかを明確にするルールです。

ストレージ構成が単純なら /dev/sdb1 を指定して終わりですが、実務では RAID、LVM、暗号化、マルチパス、仮想化などが積み重なります。積み重なるほど、誤指定のリスクは増えます。ここでの狙いは、運用の“歯止め”となる判断基準を用意することです。

層の違いを短く整理する

典型的な層を、目的とともに表に落とします。

層（例）	見え方	ここを指定する場面	誤指定の典型
物理ディスク	/dev/sdb, /dev/nvme0n1	パーティション操作、低レベル検査	本来 part を触るべきなのに disk を触る
パーティション	/dev/sdb1, /dev/nvme0n1p1	通常のマウント、FSチェック	番号違い（1と2）や別ディスクの同番号
RAID（例）	/dev/md0 等	RAIDとしての論理デバイスを扱う	メンバーディスクを直接指定して混乱
LVM/mapper	/dev/mapper/vg-lv 等	運用上の“論理ボリューム”を扱う	似た名前のLVを選ぶ／層を取り違える

---

「目的→層→同定」の順で決める

現場での事故は、多くが「層の選択」を飛ばして “それっぽいパス” を選ぶことで起きます。順番を固定します。

1. 目的：マウントしたいのか、FSを作るのか、パーティションを編集するのか

2. 層：disk/part/raid/lvm/crypt のどれを対象にすべきか

3. 同定：lsblk/blkid でUUIDやTYPEまで合わせ、対象を確定する

この順番で進めると、ENOTBLK のような“型エラー”だけでなく、もっと危険な誤操作（別デバイスへの mkfs など）に対しても防波堤になります。

---

スクリプト運用では「直書き禁止」より「事前検査必須」が効く

理想は /dev/sdX の直書きを避けることですが、現場には事情があります（急場、暫定、特定環境限定など）。その場合、ルールとしては「直書き禁止」よりも、事前検査を必須にして“穴埋め”する方が実行されやすいことがあります。

例えば、

• 指定パスがブロックデバイスか（S_ISBLK）

• 期待する TYPE/UUID と一致するか

• すでにマウントされていないか

のチェックを“必ず通す”だけで、誤指定の頻度は現実的に下げられます。これは第9章で、もう一段具体化します。

---

まとめです。複雑な構成では「どの層を触るべきか」を決めないと、ENOTBLK は繰り返し起きます。目的→層→同定の順で固定し、参照を揺れにくくし、事前検査で被害最小化する。ここまでが揃うと、次に必要になるのは「実装として再発を抑え込む」ことです。続く第9章では、チェックをコードと運用に落とし込む方法を扱います。

　

第9章：再発防止はコードで勝つ—実行前チェック（S_ISBLK判定）と、失敗時メッセージの設計

ENOTBLK を「理解した」で終わらせると、次の夜勤でまた踏みます。現場の本音はだいたいこれです。

「分かった。分かったけど、忙しいと確認を飛ばすんだよ…」

だから、確認を“意思”に頼らない設計にします。つまり、スクリプトやツール側で事前チェックを必須化して、取り違えを抑え込みます。これは、ENOTBLK 対策であると同時に、より危険な誤操作（別デバイスへの破壊的処理）に対する防波堤でもあります。

---

チェック1：そのパスは「ブロックデバイス」か

最小のチェックは「ブロックデバイスかどうか」です。シェルなら、ブロックデバイス判定は単純に書けます。

# 例（概念）：ブロックデバイスでなければ即終了 # [ -b "$DEV" ] は「ブロックデバイスなら true」 if [ ! -b "$DEV" ]; then echo "ERROR: 指定パスがブロックデバイスではありません: $DEV" 1>&2 exit 1 fi

このチェックがあるだけで、ディレクトリ取り違え・空文字・誤った引数順・typo の多くが、作業開始前に“クールダウン”できます。

---

チェック2：期待する「層」と一致しているか（TYPE/UUID/ラベル）

次に重要なのは「ブロックデバイスである」だけでは足りない点です。ブロックデバイスは複数並びます。だから、目的に合わせて “期待する層” を固定します。

• マウントしたい：通常は part や lvm（/dev/mapper/～）を想定

• パーティションを触りたい：disk を想定

• RAID 論理デバイスを触りたい：md 系や mapper を想定

このとき、事前チェックでは「lsblk の TYPE を見る」「blkid で UUID/TYPE を確認する」などを組み合わせます。ポイントは、名前ではなく属性で一致を取ることです。

# 例（概念）：期待するUUIDと一致するか確認（実装は環境に合わせる） EXPECTED_UUID="xxxx-xxxx" ACTUAL_UUID="$(blkid -s UUID -o value "$DEV" 2>/dev/null)" if [ "$ACTUAL_UUID" != "$EXPECTED_UUID" ]; then echo "ERROR: UUIDが期待値と一致しません。想定=$EXPECTED_UUID 実際=$ACTUAL_UUID DEV=$DEV" 1>&2 exit 1 fi

「UUID が取れない」場合は、その層が違う（暗号化層、PV、未フォーマット等）可能性が上がります。そこで慌てて別のパスを試すのではなく、何の層を触っているのかを見直すのが安全です。

---

チェック3：すでにマウントされていないか（破壊的操作の抑え込み）

ENOTBLK とは直接関係しませんが、実務ではここが非常に重要です。特に mkfs やパーティション操作の前に、対象が利用中でないことを確認しないと、被害最小化どころか損失・流出（データ損失）につながります。

確認は「対象がどこかにマウントされていないか」「配下にぶら下がるパーティションがマウントされていないか」を見る、という整理にすると現場で運用しやすいです。

---

失敗時メッセージは「次の一手」を含める

運用で効くのは、エラーを出すことよりも、エラーが出たときに“次に何を見ればいいか”が示されることです。ENOTBLK を踏む人は、だいたい疲れています。だからメッセージは短く、でも次の手を誘導します。

悪い例	改善例
ERROR: failed	ERROR: ブロックデバイスではありません: /mnt/data（確認: stat /mnt/data, lsblk で対象を特定してください）
ENOTBLK	ENOTBLK: 期待した層と違う可能性。DEV=/dev/mapper/xxx（確認: lsblk -f, blkid でUUID/TYPEを一致させてください）

この「次の一手」を入れるだけで、チーム内のやりとりが短くなり、社内調整・対人の摩擦も抑え込みやすくなります。

---

“チェックを強制する” という設計思想

ここまでの話は、結局こうまとめられます。

• 人間は忙しいと確認を飛ばす

• 飛ばした瞬間に取り違えが起きる

• だからチェックをコードに埋め込んで、確認を強制する

ENOTBLK は、その設計思想を導入するきっかけとして分かりやすいエラーです。次の最終章では、これまでの伏線を回収しながら「一般論の限界」と「個別案件では専門家に相談すべき理由」を、現場エンジニア目線で整理します。

　

第10章：帰結：ENOTBLK は「設定ミス」ではなく「境界ミス」—デバイス境界を設計と運用に織り込む

ここまで読んで、「結局はブロックデバイスを正しく指定すればいい」という結論に見えるかもしれません。もちろんそれは正しい。でも、現場のしんどさはそこじゃないことも多いです。

「正しい指定が毎回できるなら苦労しない。環境が複雑で、夜間で、急いでて、説明責任もあって…その中で間違えない仕組みが欲しいんだよ。」

この本音に対して、ENOTBLK の本質をこう定義すると、対策の方向が腹落ちします。

ENOTBLK は “デバイス境界（型）” を取り違えたサインであり、境界を運用と設計に織り込めていないことの症状

---

境界を織り込む、とは何をすることか

実務でやることは、派手ではありません。むしろ地味です。

• 同定：lsblk/blkid で対象を特定し、目的の層（part/lvm/raid/crypt）を一致させる

• 参照固定：by-id/UUID/命名規約で“揺れにくい参照”へ寄せる

• 事前チェック強制：S_ISBLK 判定、UUID一致、マウント状態確認をコードに埋め込む

• 失敗メッセージ設計：次の一手を示し、現場の判断を短くする

この4点が揃うと、ENOTBLK は「面倒なエラー」ではなく「境界チェックが働いた結果」に変わります。言い換えると、ENOTBLK が出たことで、誤操作が未然にブレーキされている可能性があります。

---

一般論の限界：構成が複雑だと “正しい層” が案件ごとに変わる

ただし、ここに一般論の限界があります。ストレージは、現場の事情で簡単に複雑になります。

• RAID（ソフト/ハード）、ホットスワップ、交換履歴

• LVM、スナップショット、Thin provisioning

• 暗号化（dm-crypt/LUKS）、鍵管理、復旧手順

• 仮想化/コンテナ、デバイスの露出制御、権限モデル

• ミッションクリティカルで「止められない」制約

この状態になると、「どの層を操作するのが安全か」「どこまで触って良いか」は、要件（可用性/保全性/監査/復旧優先度）で変わります。ここで“テンプレ手順”をそのまま当てると、かえってリスクが増えることがあります。

---

だからこそ、個別案件では専門家に相談した方が早い

ENOTBLK の対策自体は、確認と同定でだいぶ前に進みます。でも、実際の現場では「エラーを消す」よりも、

• データを守りながら復旧する

• 影響範囲を説明できる形にまとめる

• 再発防止を“運用に落ちる形”で設計する

ことが本当のゴールになりがちです。ここは、システム構成・運用体制・監査要件・復旧優先度が絡むため、一般論だけでは答えが1つに決まりません。

もしあなたが、具体的な案件・契約・システム構成の前提の中で「どの層を触るべきか」「どんなチェックを強制すべきか」「どこまで自動化して良いか」で悩んでいるなら、株式会社情報工学研究所のような専門事業者に相談するのが合理的です。現場の状況を前提に、設計・保守・復旧の観点をまとめて整理できるからです。

---

小さな一歩：今日からできる “境界の織り込み”

最後に、押しつけにならない範囲で「小さな一歩」を置きます。

1. 運用スクリプトに「ブロックデバイス判定（-b / stat）」を入れる

2. マウント対象は UUID/PARTUUID を基本にする（可能な範囲で）

3. 失敗時メッセージに “次の一手” を入れる

これだけでも、ENOTBLK との付き合い方はかなり変わります。現場が少し落ち着き、判断の温度が下がり、トラブルが軟着陸しやすくなります。

　

補足：現在のプログラム言語各種からブロックデバイスを扱うときの注意点（共通の落とし穴）

ここからは、Ubuntu上でブロックデバイスを“プログラムから”扱うときの注意点です。ENOTBLK はコマンドだけでなく、アプリケーションでも同様に起きます。言語が違っても共通するのは、対象の取り違えと、権限と、I/O特性です。

共通：最初に「S_ISBLK 判定」を入れる

どの言語でも、まずは stat(2) 相当で「ブロックデバイスか」を確認し、違えば即エラーにします。これが最も安い防波堤です。加えて、可能なら UUID/ラベル/メジャー・マイナー番号などで同定を強めると、取り違えがさらに減ります。

---

Shell（bash等）

• 引数の空文字が事故を誘発：変数未設定でコマンドが別のパスを取ることがあるため、必ず set -u 相当や引数検証を入れる

• 判定を強制：[ -b "$DEV" ]、UUID一致、マウント状態確認を“通らないと実行できない”構造にする

• ログ：どのDEVを触ろうとしたかを必ず残し、後から説明できるようにする

Python

• os.stat で S_ISBLK を確認できる（型確認を最初に入れる）

• ファイルI/Oの抽象化が強い分、「通常ファイルと同じ感覚で扱える」と誤解しやすい。ブロックデバイスでは権限・バッファ・エラー処理を明示する

• subprocessで外部コマンドを呼ぶ場合、引数の順序・引用・空文字に注意（意図しないパス展開が起きやすい）

Go

• os.Open で開けても「ブロックデバイスとしての操作（ioctl等）」は別。必要なら低レイヤ（syscall/外部ライブラリ）を使う

• 並行処理でデバイスを複数ゴルーチンから扱うと、順序依存の不具合が出やすい。排他と状態管理（オープン/クローズ、対象の固定）を明確にする

Rust

• 安全性が高い一方、低レイヤI/O（ioctl、O_DIRECT等）を使うと unsafe 領域が出る。境界チェック（対象の同定、権限、アライメント）を丁寧にする

• エラー型を握りつぶさない：ENOTBLK を含む errno をログに残し、再現・調査可能な形にする

C / C++

• open(2) は通るが、その後の ioctl で ENOTBLKが出る設計が多い。どの操作がブロックデバイス必須かを把握して分岐する

• バッファリング/アライメント（特に O_DIRECT 等）を使う場合、要件を満たさないと別のエラーになる。性能最適化より先に安全性（対象の固定・検証）を優先する

Java / JVM系（Kotlin等）

• 標準APIは“ファイル”を抽象化するため、ブロックデバイス固有の制御（ioctl 等）は基本的に直接できない。必要ならネイティブ連携（JNI等）になる

• 権限：実行ユーザーの権限やコンテナ制約で /dev を触れないケースが多い。アプリ設計で「どこでデバイス操作をするか」を分離する（運用・権限設計の問題）

Node.js

• 非同期I/Oで“並行に触れる”設計になりやすい。デバイス操作は順序と排他が重要なので、キュー化・ロック・単一責務化を検討する

• コンテナ運用が多い：そもそも /dev が露出していないことがある。アプリ側のエラーメッセージに「デバイス露出・権限」を疑う導線を入れる

PHP / Ruby などスクリプト言語全般

• 運用の入り口になりやすい（管理画面、ジョブ実行等）ため、引数検証・対象固定・ログが特に重要。誤指定がそのまま事故になる

• 権限と実行環境：Webサーバ実行ユーザーはデバイス操作に向かないことが多い。設計として「デバイス操作は管理者ジョブに分離」する方が安全

---

ここまでの補足も含めて、最終的に言いたいのは1点です。ENOTBLK は単なるエラーではなく、「境界（型・層・権限・露出）を設計に織り込め」というサインです。一般論だけでも一定の改善はできますが、現実の案件は制約が多く、判断が分かれます。具体的な構成や契約上の要件、復旧の優先度、監査・説明責任まで含めて悩む場面では、株式会社情報工学研究所への相談・依頼を検討することが、結果的に早く安全な解決につながります。